Politiques de répétition et backoff

Les répétitions (retries) aident à survivre aux pannes temporaires, mais si elles sont mal réglées, elles provoquent des avalanches de trafic, des prises d'opérations et des chutes en cascade. Une politique de rétroaction robuste commence toujours par des retouches, prend en compte l'idempotence et utilise backoff + jitter.

1) Principes de base

1. D'abord le timaout/deadline, puis le rétro. Une répétition sans limite de temps ne fait qu'allonger la panne.
2. Retray - seulement pour les opérations sécuritaires/idempotent. Pour ceux qui ne sont pas sûrs - via idempotency-keys et les garanties transactionnelles.
3. Backoff est obligatoire. Exponentielle ou GCRA avec un gitter pour dissynchroniser les ondes.
4. Limitez le nombre de tentatives et le budget total. Ne quittez pas le SLO de l'utilisateur.
5. Respecter les signaux d'infrastructure. '429/503' + 'Retry-After', état du circuit breaker, limites des files d'attente.

2) Taimauts et dedlines (déadline propagation)

Temporisation de la requête <SLO du service, la date limite se propage en bas de la chaîne (en-têtes HTTP/gRPC context).
Composition temporelle : Total (première tentative + backoff + suivante) ≤ une deadline personnalisée.
Différents temps de lecture/enregistrements : les enregistrements sont plus courts et plus stricts ; les lectures permettent le hedging.

3) Idempotence et répétitions sûres

Lectures (GET/idempotent RPC) : répétez en toute sécurité à '5xx', 'UNAVAILABLE', les temporisations réseau.

• Utilisez 'Idempotency-Key' (HTTP) ou request-ID à la frontière ; le serveur doit dédupliquer.
• Ecrivez les manipulateurs idempotent : « upsert », « at-least-once » + compensation (saga).
• Paiements externes/réciproques - seulement avec les clés idempotent et le journal des transactions.

4) Algorithmes backoff

Exponential : 'base 2 ^ attempt', limité à 'max _ backoff'.
Décorrelated Jitter (full/equal jitter) : aléatoire dans la gamme pour dissynchroniser les clients.
GCRA/Token-Bucket-comme les retards : convenu avec les limites de taux.
Bordure : 'initial _ backoff' (50-200 ms de lecture ; 200-500 ms d'enregistrement), 'max _ backoff' (1-5 s), 'max _ elapsed' (par exemple, 3-10 s).

Modèle recommandé : exponentielle backoff + full jitter.

5) Politiques de décision « répéter/ne pas répéter »

• Erreurs réseau/temporisation, '429' (avec le respect de 'Retry-After'), '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE _ EXCEEDED'.

• '4xx '(à l'exception de' 409/429/408 'dans certains scénarios), erreurs commerciales,' 401/403 ', erreurs de validation, indicateur explicite' DoNotRetry '.

• '409 Conflict' est parfois une répétition retardée après consensus/lock.
• '404' pour les lectures de consistance eventually est une rétrospective une à deux fois avec un petit backoff.

6) Caps de concurrence et « tempête de rétrospective »

Limitez les retraits simultanés per-client/per-tenant/per-endpoint.
Limite totale des tentatives de requête (p. ex. 2-3).
Freinez les endpoints « chauds » via le contrôle d'admission pour ne pas gonfler les files d'attente.

7) Interagir avec Circuit Breaker et les limites

Si CB open, n'effectuez pas de retraits directement - allez à fallback ou attendez 'half-open' échantillons.
À '429', respectez 'Retry-After' ; en son absence, appliquez un backoff « doux ».
Les retraits peuvent augmenter la charge ; appliquez des seuils adaptatifs (abaissez 'max _ attempts' en cas d'incident).

8) Protocoles et contrats

HTTP

Codes : '408/429/5xx'.
Titres : 'Retry-After', la famille 'RateLimit-', 'Idempotency-Key', 'Request-Id'.
Le client doit transmettre "X-Request-Timeout "/" Deadline-At' (si vous l'avez accepté).

gRPC

Utilisez le contexte avec la date limite ; Respecter 'UNAVAILABLE', 'DEADLINE _ EXCEEDED', polices rétractables par méthode.
Pour les RPC idempotent - allumer les retraits ; pour les mutations - seulement avec le soutien de l'idempotence.

9) Files d'attente, tâches de fond et intégrations

Les gestionnaires at-least-once → les actions idempotentes, la déduplication par clé.
Delay queue pour backoff entre les tentatives (par exemple, 5s/30s/2m).
Dead-letter queue (DLQ) avec limite d'essai et manutention manuelle.
Outbox/CDC - pour que les répétitions ne portent pas atteinte à l'intégrité transactionnelle.

10) Hedging vs Retries

Hedging (demande miroir) est utile pour les lectures hautement critiques en latence caudale.
Limitez : pas plus de X % des demandes, délai « start-grace » (par exemple, p95-latence), annulation des perdants.
Ne pas appliquer le hedging aux opérations d'écriture sans une forte idempotence.

11) Télémétrie et observabilité

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Métriques : proportion de retraits, succès après retraits, p95/p99 « end-to-end », nombre de dedlines dépassées, déclenchement CB.
Logs d'audit : N clés/endpoints « bruyants », corrélation avec 429/503.

12) Test et chaos

Profils : « scie », « tempête », erreurs « collantes », queues de latence.
Échec de l'store limite/cache/file d'attente, clock-skew.
Vérifier que la durée totale (attempts + backoff) est placée dans le SLO.

13) Pseudo-code politique

pseudo handle(req, deadline):
attempt = 0 backoff = initial()
while attempt < MAX_ATTEMPTS and now() < deadline:
attempt += 1 with timeout(per_attempt_timeout(deadline, attempt)):
try:
resp = call(req)
if isRetryableStatus(resp): raise Retryable(resp. status)
return resp except Retryable as e:
if circuit. isOpen(dep) or! isIdempotent(req): break sleep(jitter(backoff))
backoff = min(exp(backoff), MAX_BACKOFF)
except NonRetryable:
break return fail_or_fallback(req)

14) Modèle de configuration (exemple)

yaml retries:
default:
max_attempts: 3 initial_backoff_ms: 150 max_backoff_ms: 2000 strategy: exponential_full_jitter respect_retry_after: true per_attempt_timeout_fraction: 0. 4 # 40% of remaining deadline hedging:
enabled: false read_heavy:
max_attempts: 4 initial_backoff_ms: 80 max_backoff_ms: 1200 hedging:
enabled: true start_after_p95_ms: 300 max_extra_requests_ratio: 0. 05 write_strict:
max_attempts: 2 initial_backoff_ms: 250 max_backoff_ms: 1000 idempotency_required: true

limits:
concurrent_retries_per_tenant: 100 concurrent_retries_per_endpoint: 20

15) Chèque-liste avant la vente

• Les deadlines se propagent à travers les appels ; durée totale ≤ SLO.
• Algorithme backoff avec jitter ; les paramètres sont validés par un test de charge.
• Idempotence : clés/journaux/compensation pour les enregistrements.
• Les politiques rétrospectives diffèrent pour les lectures et les enregistrements ; respect `Retry-After`.
• La concurrence des rétrogrades et le nombre total de tentatives sont limités.
• L'intégration avec circuit breaker et rate limites est personnalisée.
• Télémétrie : tags, métriques, logs de cause ; dashboards p95/p99, proportion de succès après les retraits.
• Tests « tempêtes » et queues de latence, DLQ pour les tâches.
• Documentation client : codes/titres, exemples de backoff et d'annulation.

16) Erreurs typiques

Les répétitions sans temporisation/dédelines sont des « attentes éternelles ».
Les pauses fixes sans jitter sont les ondes synchrones et l'autosuffisance DDoS.
Les retraits d'enregistrements dangereux sans idempotence sont les prises et la dissynchronisation.
Ignorer « Retry-After » et les signaux CB est une escalade de l'incident.
Goulets d'étranglement dans les files d'attente en raison de l'absence de caps et de contrôle d'admission.
L'absence de télémétrie des causes/solutions rétroactives est un « vol aveugle ».

17) Recettes rapides

Lecture publique de l'API : 3 tentatives, 'initial = 100ms', 'max = 1s', full jitter, hedging jusqu'à 5 % du trafic.
Entrées critiques (paiement) : 1-2 tentatives max, délai strict, obligatoire 'Idempotency-Key', sans hedging.
Intégrations externes : respecter '429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', limites de flux sortant.
Tâches d'arrière-plan : delay-backoff (5s → 30s → 2m), DLQ, processeurs idempotent.

Conclusion

Une bonne politique de répétition est l'équilibre entre une reprise rapide et un refus contrôlé. Les deadlines, l'idempotence, le backoff exponentiel avec le gitter, la limitation de la concurrence et le respect des signaux d'infrastructure transforment les retraits d'une « tempête » en un outil pour améliorer la fiabilité et la rétention des SLO.