Polityka retry i backoff

Powtórzenia (ponowne próby) pomagają przetrwać tymczasowe awarie, ale jeśli są nieprawidłowo skonfigurowane, powodują lawiny ruchu, duplikaty operacji i upadki kaskadowe. Niezawodna polityka retrasy zawsze zaczyna się od terminów/terminów, uwzględnia idempotencję i wykorzystuje backoff + jitter.

1) Podstawowe zasady

1. Najpierw czas/termin, a następnie wycofać. Powtarzanie bez ograniczeń czasowych tylko wydłuża awarię.
2. Retray - tylko do bezpiecznych/idempotentnych operacji. Dla niepewnych - poprzez klucze idempotencji i gwarancje transakcji.
3. Backoff jest obowiązkowy. Wykładnicze lub GCRA-jak z jitter do desynchronizacji fal.
4. Ograniczyć liczbę prób i całkowity czas budżetowy. Nie zostawiaj SLO użytkownika.
5. Szanuj sygnały infrastrukturalne. '429/503' + 'Retry-After', stan wyłącznika, granice kolejki.

2) Terminy i terminy (propagacja terminów)

Żądanie timeout <SLO service, termin propaguje w dół łańcucha (nagłówki HTTP/kontekst gRPC).
Skład Timeout: razem (pierwsza próba + backoff + kolejne) ≤ termin dla użytkownika.
Różne terminy odczytu/rekordów: rekordy są krótsze i bardziej rygorystyczne; odczyty pozwalają na zabezpieczenie.

3) Idempotencja i bezpieczne powtórzenia

Odczytuje (GET/idempotent RPC): bezpiecznie powtarzane z '5xx', 'UNAVAILABLE', timeouts sieciowy.

• Użyj 'Idempotence-Key' (HTTP) lub ID żądania na granicy; serwer musi być zdublowany.
• Napisz idempotent handlers: „upsert”, „at least-once” + compensation (saga).
• Płatności/rozliczenia zewnętrzne - tylko za pomocą kluczy idempotentnych i dziennika transakcji.

4) Algorytmy backoff

Wykładniczy: 'base 2 ^ attempt', ograniczony przez 'max _ backoff'.
Udekorowany Jitter (full/equal jitter) - losowość w zakresie do desynchronizacji klientów.
Opóźnienia GCRA/Token-Bucket-like: zgodne z limitami stawek.
Granice: „initial _ backoff” (50-200 ms brzmi; 200-500 ms records), 'max _ backoff' (1-5 s), 'max _ elapsed' (na przykład 3-10 s).

Zalecany wzór jest wykładniczy backoff + full jitter.

5) Powtarzać/nie powtarzać polityki decyzji

• Błędy/timeouts sieci, '429' (z poszanowaniem 'Retry-After'), 'soft' '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE _ EXCEEDED'.

• '4xx' (z wyjątkiem '409/429/408' w niektórych scenariuszach), błędy biznesowe, '401/403', błędy walidacyjne, wyraźne 'DoNotRetry' flag.

• „409 Konflikt” - czasami powtarzane z opóźnieniem po konsensusie/zamki.
• „404” dla trwale spójnych odczytów - jeden lub dwa razy przekaźnik z małym cofnięciem.

6) Czapki współistniejące i „burza retray”

Ograniczenie jednoczesnych przekładów na klienta/lokatora/punkt końcowy.
Całkowity limit prób na żądanie (np. 2-3).
Zwolnić gorące punkty końcowe poprzez kontrolę wstępu, aby nie nadmuchiwać kolejek.

7) Interakcja z wyłącznikiem i limitami

Jeśli CB jest otwarty, nie należy wykonywać przekaźników bezpośrednio - idź na wypadek awarii lub czekać na próbki „w połowie otwarte”.
na „429” - szacunek „Retry-After”; jeśli nie, użyj „miękkiego” backoff.
Przekładki mogą zwiększyć szczep; zastosować progi adaptacyjne (niższe 'max _ attempts' dla incydentu).

8) Protokoły i umowy

HTTP

Kody: „408/429/5xx”.
Nagłówki: 'Retry-After', rodzina ' Limit-', 'Idempotency-Key', 'Request-Id'.
Klient musi wysłać 'X-Request-Timeout '/' Deadline-At' (jeśli tak).

gRPC

Wykorzystaj kontekst z terminem; przestrzeganie „NIEDOSTĘPNE”, „TERMIN _ PRZEKROCZONY”, przekwalifikowanie polityk według metody.
Dla idempotentnych RPC, obejmują przekładki; dla mutacji - tylko przy wsparciu idempotencji.

9) Kolejki, zadania podstawowe i integracja

Przynajmniej raz obsługujący → idempotentne działania, deduplikacja kluczy.
Kolejka opóźnień dla backoff między próbami (na przykład 5s/30s/2m).
Kolejka martwych liter (DLQ) z limitem prób i ręcznego przetwarzania.
Outbox/CDC - dzięki czemu repliki nie zagrażają integralności transakcji.

10) Zabezpieczenie vs Retries

Zabezpieczenie jest przydatne dla bardzo krytycznych odczytów w ukryciu ogona.
Limit: nie więcej niż X% żądań, opóźnienie rozruchu (na przykład opóźnienie p95), anulowanie przegranych.
Nie stosować zabezpieczenia do zapisu operacji bez silnej idempotencji.

11) Telemetria i obserwowalność

Тера: 'tenant _ id',' endpoint ',' attempt ',' decision '(retry/skip),' reason ',' backoff _ ms ',' deadline _ ms ',' idempotency _ key '.
Metryka: udział rekolekcji, sukces po rekolekcjach, p95/p99 „end-to-end”, liczba przekroczonych terminów, uruchamianie CB.
Dzienniki audytu: górne klucze N „hałaśliwe ”/punkty końcowe, korelacja z 429/503.

12) Testowanie i chaos

Profile: „piła” (burst-lull), „burza” (masowe timeouts), „lepkie” błędy (każdy Nth), ogony opóźnienia.
Torus limiter/cache/kolejka awaria, zegar-skew.
Sprawdza, czy całkowity czas trwania (próby + backoff) pasuje do SLO.

13) Pseudokod polityki

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) Szablon konfiguracji (przykład)

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) Lista kontrolna przedsprzedaży

• Terminy propagowane za pomocą wezwań; całkowity czas trwania SLO ≤.
• Algorytm backoff z jitterem; parametry zatwierdzone badaniem obciążenia.
• IDempotence: keys/logs/compensations for records.
• Polityka retrasy różni się w odniesieniu do odczytów i zapisów; szacunek dla „Retry-After”.
• Ograniczona jest konkurencyjność przekwalifikowania i całkowita liczba prób.
• Integracja z wyłącznikiem i ograniczenia prędkości jest skonfigurowana.
• Telemetria: tagi, mierniki, logi uzasadnienia; deski rozdzielcze p95/p99, udział sukcesu po przekładkach.
• Testy „burz” i ogonów opóźnień, DLQ dla zadań.
• Dokumentacja klienta: kody/tytuły, backoff i przykłady anulowania.

16) Typowe błędy

Powtórki bez terminów/terminów to „wieczne oczekiwania”.
Stałe przerwy bez jittera - fale synchroniczne i samosabotaż DDoS.
Przekłady niebezpiecznych zapisów bez idempotencji - duplikaty i desynchronizacja.
Ignorowanie sygnałów „Retry-After” i CB - eskalacja incydentu.
Wąskie gardła w kolejkach z powodu braku czapek i kontroli wjazdu.
Brak telemetrii powodów/rozwiązań retras - „ślepy lot”.

17) Szybkie przepisy kulinarne

Publiczne API brzmi: 3 próby, 'initial = 100ms', 'max = 1s', full jitter, zabezpieczające do 5% ruchu.
Rekordy krytyczne (płatność): 1-2 maksymalne próby, ścisły czas, obowiązkowe 'Idempotency-Key', bez zabezpieczenia.
Integracje zewnętrzne: szacunek '429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', granice przepływu wychodzącego.
Zadania podstawowe: delay-backoff (5s → 30s → 2m), DLQ, idempotent handlers.

Wnioski

Dobra polityka powtarzania to równowaga między szybkim odzyskiwaniem a kontrolowaną awarią. Terminy, idempotencja, wykładnicze backoff z jitter, ograniczenie konkurencji i poszanowanie sygnałów infrastrukturalnych przekształcić przekaźniki z „burza” w narzędzie do poprawy niezawodności SLO i zatrzymywania.