Wiederholungs- und Backoff-Richtlinien

Wiederholungen (Retries) helfen, vorübergehende Störungen zu überleben, aber wenn sie nicht richtig eingestellt sind, verursachen sie Verkehrslawinen, Doppeloperationen und kaskadierende Stürze. Eine solide Retraypolitik beginnt immer mit Deadlines/Timeouts, berücksichtigt Idempotenz und nutzt Backoff + Jitter.

1) Grundprinzipien

1. Erst Timeout/Deadline, dann Retrait. Eine Wiederholung ohne Zeitlimit verlängert den Ausfall nur.
2. Retray - nur für sichere/idempotente Operationen. Für unsichere - durch idempotency-keys und Transaktionsgarantien.
3. Backoff ist Pflicht. Exponentiell oder GCRA-ähnlich mit einem Jitter, um die Wellen nicht zu synchronisieren.
4. Begrenzen Sie die Anzahl der Versuche und die Gesamtbudget-Zeit. Gehen Sie nicht über das SLO des Benutzers hinaus.
5. Respektieren Sie die Signale der Infrastruktur. '429/503' + 'Retry-After', Circuit Breaker Status, Warteschlangenlimits.

2) Timeouts und Deadlines (Deadline Propagation)

Abfrage-Timeout <Service SLO, Deadline wird in der Kette nach unten verteilt (HTTP-Header/gRPC-Kontext).
Zusammensetzung der Timeouts: summarisch (erster Versuch + Backoff + Follow-up) ≤ benutzerdefinierte Deadline.
Verschiedene Timeouts für Lesungen/Aufnahmen: die Aufnahmen sind kürzer und strenger; Lesen erlaubt hedging.

3) Idempotenz und sichere Wiederholungen

Lesungen (GET/idempotente RPCs): sicher wiederholen bei '5xx', 'UNAVAILABLE', Netzwerk-Timeouts.

• Verwenden Sie den 'Idempotency-Key' (HTTP) oder die Request-ID an der Grenze; Der Server muss dedupliziert werden.
• Schreiben Sie idempotente Handler: „upsert“, „at-least-once“ + Entschädigung (Saga).
• Externe Zahlungen/gegenseitige Abrechnungen - nur mit idempotenten Schlüsseln und Transaktionsprotokoll.

4) Backoff-Algorithmen

Exponentiell: 'base 2 ^ attempt', begrenzt auf 'max _ backoff'.
Decorrelated Jitter (Full/Equal Jitter): Zufälligkeit im Bereich für nicht synchronisierte Clients.
GCRA/Token-Bucket-ähnliche Verzögerungen: abgestimmt auf die Rate Limits.
Grenzen: 'initial _ backoff' (50-200 ms lesen; 200-500 ms Schreiben), 'max _ backoff' (1-5 s), 'max _ elapsed' (z.B. 3-10 s).

Empfohlenes Muster: Exponential Backoff + Full Jitter.

5) Entscheidungspolitik „wiederholen/nicht wiederholen“

• Netzwerkfehler/Timeouts, '429' (mit Respekt 'Retry-After'), 'soft' '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE _ EXCEEDED'.

• '4xx' (außer '409/429/408' in einigen Szenarien), Geschäftsfehler, '401/403', Validierungsfehler, explizite' DoNotRetry '-Flag.

• '409 Conflict' ist manchmal eine Wiederholung mit einer Verzögerung nach Konsens/Locks.
• '404' für eventually konsistente Lesungen ist ein ein- bis zweimaliger Rückzug mit kleinem Backoff.

6) Betonung Caps und „Sturm der Retrays“

Beschränken Sie gleichzeitig retrai per-client/per-tenant/per-endpoint.
Das Gesamtlimit der Anfrageversuche (z. B. 2-3).
Bremsen Sie „heiße“ Endpoints über Admission Control, um Warteschlangen nicht aufzublähen.

7) Interaktion mit Circuit Breaker und Limits

Wenn CB offen ist, führen Sie die Retrays nicht direkt durch - gehen Sie zum Fallback oder warten Sie auf 'half-open' -Proben.
Bei '429' - respektiere' Retry-After'; in seiner Abwesenheit - verwenden Sie einen „weichen“ Backoff.
Retrays können die Belastung erhöhen; Wenden Sie adaptive Schwellenwerte an (senken Sie' max _ attempts' im Falle eines Vorfalls).

8) Protokolle und Verträge

HTTP

Codes: „408/429/5xx“.
Überschriften: „Retry-After“, Familie „RateLimit-“, „Idempotency-Key“, „Request-Id“.
Der Kunde muss einen 'X-Request-Timeout '/' Deadline-At' übermitteln (wenn Sie dies haben).

gRPC

Kontext mit Deadline verwenden; respektieren Sie' UNAVAILABLE', 'DEADLINE _ EXCEEDED', die Richtlinien der Retrays pro Methode.
Für idempotente RPCs - aktivieren Sie Retrays; für Mutationen - nur mit Unterstützung der Idempotenz.

9) Warteschlangen, Hintergrundaufgaben und Integrationen

At-least-once-Handler → idempotente Aktionen, Deduplizierung nach Schlüssel.
Delay queue für Backoff zwischen Versuchen (z.B. 5s/30s/2m).
Dead-letter queue (DLQ) mit Versuchsbegrenzung und manueller Bearbeitung.
Outbox/CDC - damit Wiederholungen die Transaktionsintegrität nicht beeinträchtigen.

10) Hedging vs Retries

Hedging (Spiegelbefragung) ist nützlich für hochkritische Lesungen mit Schwanzlatenz.
Limit: nicht mehr als X% der Anfragen, Start-Grace-Latenz (z.B. p95-Latenz), Stornierung von Verlierern.
Wenden Sie Hedging nicht auf Schreiboperationen ohne starke Idempotenz an.

11) Telemetrie und Beobachtbarkeit

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Metriken: Anteil der Retrays, Erfolg nach Retrays, p95/p99 „End-to-End“, Anzahl der überschrittenen Deadlines, CB-Trigger.
Prüfprotokolle: obere N „laute“ Schlüssel/Endpunkte, Korrelation mit 429/503.

12) Testen und Chaos

Profile: „Säge“ (Burst-Flaute), „Sturm“ (massive Timeouts), „klebrige“ Fehler (jeder N-te), Latenzschwänze.
Stor-Fehler Limiter/Cache/Queue, Clock-Skew.
Überprüft, ob die Gesamtdauer (attempts + backoff) in den SLO passt.

13) Pseudocode der Politik

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) Konfigurationsvorlage (Beispiel)

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) Checkliste vor dem Verkauf

• Deadlines verbreiten sich durch Herausforderungen; Gesamtdauer der SLO- ≤.
• Backoff-Algorithmus mit Jitter; die Parameter werden durch einen Belastungstest validiert.
• Idempotenz: Schlüssel/Protokolle/Kompensationen für Aufzeichnungen.
• Retrayrichtlinien unterscheiden sich für Lesungen und Aufzeichnungen; respect `Retry-After`.
• Die Wettbewerbsfähigkeit der Retrays und die Gesamtzahl der Versuche sind begrenzt.
• Integration mit Circuit Breaker und Rate Limits konfiguriert.
• Telemetrie: Tags, Metriken, Ursachenprotokolle; Dashboards p95/p99, Anteil der Erfolge nach Retrays.
• Tests „Stürme“ und Latenzschwänze, DLQ für Aufgaben.
• Kundendokumentation: Codes/Titel, Beispiele für Backoff und Stornierungen.

16) Typische Fehler

Wiederholungen ohne Timeouts/Deadlines sind „ewige Erwartungen“.
Feste Pausen ohne Jitter - Synchronwellen und DDoS-Selbstsabotage.
Die Retrays unsicherer Aufnahmen ohne Idempotenz sind doppelt und nicht synchron.
Ignorieren von „Retry-After“ und CB-Signalen - Eskalation des Vorfalls.
Engpässe in Warteschlangen durch fehlende Caps und Zulassungs-Kontrollen.
Fehlende Telemetrie von Ursachen/Lösungen von Retrays - „Blindflug“.

17) Schnelle Rezepte

Öffentliche API-Lesungen: 3 Versuche, 'initial = 100ms', 'max = 1s', full jitter, hedging bis zu 5% des Datenverkehrs.
Kritische Einträge (Zahlung): 1-2 Versuche max, strikter Timeout, obligatorischer 'Idempotency-Key', kein Hedging.
Externe Integrationen: Respektieren Sie' 429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', Ausgangsflusslimits.
Hintergrundaufgaben: delay-backoff (5s → 30s → 2m), DLQ, idempotente Handler.

Schlussfolgerung

Eine gute Politik der Wiederholungen ist die Balance zwischen schneller Erholung und kontrollierter Ablehnung. Deadlines, Idempotence, exponentieller Backoff mit Jitter, Wettbewerbsbeschränkungen und Respekt für Infrastruktursignale machen Retrays von einem „Sturm“ zu einem Instrument zur Verbesserung der Zuverlässigkeit und Beibehaltung von SLOs.