Criteri di ripetizione e backoff

Le ripetizioni consentono di superare i guasti temporanei, ma quando la configurazione non è corretta, causano valanga di traffico, riprese di operazioni e cadute a cascata. Una solida politica dei retrai inizia sempre con deadline/timeout, prende in considerazione l'idipotenza e utilizza backoff + jitter.

1) Principi di base

1. Prima timeout/deadline, poi retrai. Una ripetizione senza limiti di tempo non fa altro che allungare il guasto.
2. Retrai è solo per operazioni sicure/idempotate. Per i non sicuri, tramite idempotency-keys e garanzie transazionali.
3. Backoff è obbligatorio. Esponenziale o GCRA-simile con jitter per risincronizzare le onde.
4. Limitare il numero di tentativi e il budget-tempo totale. Non sposare il SLO dell'utente.
5. Rispettare i segnali dell'infrastruttura. '429/503' + 'Retry-After', stato del circuito breaker, limiti delle code.

2) Timeout e deadline (deadline propagation)

Timeout della richiesta <SLO del servizio, la deadline viene distribuita a valle della catena (HTTP titoli/gRPC text).
Composizione timeout: riepilogo (primo tentativo + backoff + successivi) della deadline personalizzata.
Timeout diversi per letture/record: scrittura più breve e più rigorosa; le letture consentono l'hedging.

3) Idampotenza e ripetizioni sicure

Letture (GET/Idempotent RPC) - Ripetere in modo sicuro a 5xx, UNAVAILABLE, timeout di rete.

• Usa Idempotency-Key (HTTP) o richiest-ID al limite; il server deve essere deduplicato.
• Scrivi elaboratori Idempotent: «upsert», «at-least-once» + compensi (saga).
• Pagamenti/interscambi esterni solo con chiavi idempotate e registro delle transazioni.

4) Algoritmi backoff

Exponential: 'base 2 ^ attempt', limitato à max _ backoff ".
Decorrelated Jitter (full/equal jitter) - Casualità nell'intervallo per la rassincronizzazione dei clienti.
GCRA/Token-Bucket-ritardi simili a rate limits.
Bordi: 'iniziale _ backoff' (50-200 ms di lettura; 200-500 mc record), 'max _ backoff' (1-5 s), 'max _ elapsed' (ad esempio 3-10 s).

Il modello consigliato è backoff esponenziale + full jitter.

5) Politiche decisionali «ripetere/non ripetere»

• Errori di rete/timeout, '429' (con rispettò Retry-After «),» morbidi «'5xx» (' '), «UNAVAILABLE/DEADLINE _ EXCEEDED».

• «4xx» (eccetto «409/429/408» in alcuni scenari), errori aziendali, «401/403», errori di convalida, flag esplicito «DoNotRetry».

• «409 Conflict» è a volte una ripetizione con ritardo dopo il consenso/lock.
• '404' per le letture eventually consistent - uno-due volte il retrai con un piccolo backoff.

6) Concurrency caps e «tempesta retraica»

Limitare i retrai simultanei per-client/per-tenant/per-endpoint.
Limite totale dei tentativi di richiesta (ad esempio 2-3).
Frenate gli endpoint caldi attraverso il controllo admissione per non gonfiare le code.

7) Interazione con Circuito Breaker e limiti

Se CB è aperto, non eseguire direttamente i retrai - andare in fallback o attendere «half-open».
Con «429» - rispettare «Retry-After»; Se non c'è - usa il backoff «morbido».
I retrai possono aumentare il carico; applica le soglie adattive (riduci "max _ attemps'in caso di incidente).

8) Protocolli e contratti

HTTP

Codici: '408/429/5xx'.
I titoli sono «Retry-After», famiglia «RateLimit -», «Idempotency-Key», «Richiest-ID».
Il client deve trasmettere «X-Sollest-Timeout »/« Deadline-At» (se è il caso).

gRPC

Utilizzare il contesto con deadline Rispettate «UNAVAILABLE», «DEADLINE _ EXCEEDED», le polizze retraiche per metodo.
Per RPC idipotenti: abilita i retrai; per le mutazioni, solo con idempotenza.

9) Code, attività di sfondo e integrazione

I processori at-least-once eseguono azioni idompotenti, deduplicazione su chiave.
Delay queue per backoff tra i tentativi (ad esempio 5s/30s/2m).
Dead-letter queue (DLQ) con limite di tentativi e elaborazione manuale.
Outbox/CDC - in modo che le repliche non violino l'integrità transazionale.

10) Hedging vs Retries

Hedging (mirroring) è utile per le letture ad alta ritica a latenza di coda.
Limitare a meno di X% richieste, ritardo start-grace (ad esempio p95-latitanza), annullamento perdenti.
Non applicare hedging alle operazioni di scrittura senza una forte idampotenza.

11) Telemetria e osservazione

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Metriche: percentuale di retrai, successo dopo i retrai, p95/p99 «end-to-end», numero di deadline superate, azionamento CB.
I loghi di verifica sono i N più alti delle chiavi/endpoint, correlati con 429/503.

12) Test e caos

I profili sono: «sega», «tempesta» (timeout di massa), errori «appiccicosi» (ogni N), code di latitanza.
Guasti dello store limitatore/cache/coda, clock-skew.
Verifica che la durata totale (attemps + backoff) sia inserita in SLO.

13) Pseudo-codice criteri

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) Modello di configurazione (esempio)

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) Foglio di assegno prima della vendita

• Le deadline si diffondono attraverso le chiamate; Durata totale del ≤ SLO.
• Algoritmo backoff con jitter; i parametri sono convalidati da un test di carico.
• Idempotenza: chiavi/registri/rimborsi per le voci.
• I criteri retrai variano per le letture e i record; respect `Retry-After`.
• La competitività dei retrai e il numero totale di tentativi è limitato.
• L'integrazione con circuito breaker e rate limits è configurata.
• Telemetria: tag, metriche, fogli di causa; dashboard p95/p99, una percentuale di successi dopo i retrai.
• Test di tempesta e code di latenza, DLQ per le attività.
• Documentazione per i clienti: codici/titoli, esempi di backoff e cancellazioni.

16) Errori tipici

Ripetizioni senza timeout/deadline sono «eterne aspettative».
Le pause fisse senza jitter sono le onde sincronizzate e l'autosabotaggio DDoS.
Ritai di record non sicuri senza idepotenza - prese e rassincronizzazione.
Ignorare «Retry-After» e i segnali CB è un'escalation dell'incidente.
Colli di bottiglia nelle code a causa della mancanza di caps e adattamento control.
La mancanza di telemetria per cause/soluzioni retraiche è un volo cieco.

17) Ricette veloci

API pubblica: 3 tentativi, «iniziale = 100ms», «max = 1s», full jitter, hedging fino al 5% del traffico.
Record critici (pagamento): 1-2 tentativi max, timeout rigoroso, obbligatorio «Idempotency-Key», senza hedging.
Integrazioni esterne: rispettare «429/Retry-After», «max _ attemps = 3», «max _ backoff = 2-5s», limiti di flusso in uscita.
Attività di sfondo: delay-backoff (5s-30s-30s-2m), DLQ, elaboratori idropotenti.

Conclusione

Una buona politica di ripetizione è l'equilibrio tra recupero rapido e rifiuto controllato. Deadline, idampotenza, backoff esponenziale con jitter, limitazione della concorrenza e rispetto dei segnali infrastrutturali trasformano i retrai da «tempesta» in uno strumento per migliorare l'affidabilità e la conservazione dello SLO.