Təkrarlama və backoff siyasəti

Təkrarlamalar (retries) müvəqqəti uğursuzluqlardan qurtulmağa kömək edir, lakin düzgün qurulmadıqda trafik uçqunları, əməliyyatların dublları və kaskadlı enişlərə səbəb olur. Etibarlı retraj siyasəti həmişə son tarixlərdən/vaxtlardan başlayır, idempotantlığı nəzərə alır və backoff + jitterdən istifadə edir.

1) Əsas prinsiplər

1. Əvvəlcə taymaut/son tarix, sonra retraj. Vaxt limiti olmadan təkrarlamaq yalnız imtinanı uzatır.
2. Retray - yalnız təhlükəsiz/idempotent əməliyyatlar üçün. Təhlükəsiz olanlar üçün - idempotency-keys və əməliyyat zəmanətləri vasitəsilə.
3. Backoff tələb olunur. Dalğaları sinxronlaşdırmaq üçün GCRA və ya GCRA bənzəri.
4. Cəhdlərin sayını və ümumi büdcə-vaxtı məhdudlaşdırın. SLO istifadəçisini tərk etməyin.
5. Infrastruktur siqnallarına hörmət edin. '429/503' + 'Retry-After', circuit breaker vəziyyəti, növbə limitləri.

2) Vaxtlar və müddətlər (deadline propagation)

Sorğu vaxtı <SLO servisi, son tarix zəncir boyunca yayılır (HTTP başlıqlar/gRPC context).
Taymaut kompozisiyası: cəmi (ilk cəhd + backoff + sonrakı) ≤ xüsusi son tarix.
Oxumaq/yazmaq üçün müxtəlif vaxtlar: yazılar daha qısa və daha sərtdir; oxu hedging imkan verir.

3) İdempotentlik və təhlükəsiz təkrarlamalar

Oxu (GET/Idempotent RPC): '5xx', 'UNAVAILABLE', şəbəkə vaxtında təhlükəsiz şəkildə təkrarlayın.

• Sərhəddə 'Idempotency-Key' (HTTP) və ya request-ID istifadə edin; server deuplikasiya etməlidir.
• İdempotent prosessorları yazın: «upsert», «at-least-once» + kompensasiya (saga).
• Xarici ödənişlər/qarşılıqlı hesablaşmalar - yalnız idempotent açarları və əməliyyat jurnalı ilə.

4) Backoff alqoritmləri

Exponential: 'base 2 ^ attempt', məhdud 'max _ backoff'.
Decorrelated Jitter (full/equal jitter): müştərilərin sinxronizasiyası üçün bir sıra təsadüfi.
GCRA/Token-Bucket kimi gecikmələr: rate limits ilə razılaşdırılmışdır.
Sərhədləri: 'initial _ backoff' (50-200 ms oxu; 200-500 ms), 'max _ backoff' (1-5 s), 'max _ elapsed' (məsələn, 3-10 s).

Tövsiyə olunan şablon: eksponensial backoff + full jitter.

5) «təkrarlamaq/təkrarlamamaq» qərar siyasəti

• Şəbəkə səhvləri/vaxt, '429' (hörmətlə 'Retry-After'), 'yumşaq' 5xx '(' 502/503/504 '), gRPC' UNAVAILABLE/DEADLINE _ EXCEEDED '.

• '4xx' (bəzi ssenarilərdə '409/429/408' istisna olmaqla), biznes səhvləri, '401/403', təsdiqləmə səhvləri, açıq-aşkar 'DoNotRetry' bayrağı.

• '409 Conflict' - bəzən konsensusdan/bloklardan sonra gecikmə ilə təkrar.
• eventually consistent oxu üçün '404' kiçik backoff ilə bir-iki dəfə retrajdır.

6) Concurrency caps və «fırtına retrai»

Eyni zamanda per-client/per-tenant/per-endpoint retrajlarını məhdudlaşdırın.
Sorğu cəhdlərinin ümumi limiti (məsələn, 2-3).
Növbələri şişirtməmək üçün admission control vasitəsilə «isti» end nöqtələrini yavaşlatın.

7) Circuit Breaker və limitləri ilə qarşılıqlı əlaqə

CB açıqdırsa, retrayları birbaşa yerinə yetirməyin - fallback-ə gedin və ya 'half-open' testini gözləyin.
Ilə '429' - hörmət 'Retry-After'; yoxluğunda - «yumşaq» backoff tətbiq edin.
Retrajlar yükü artıra bilər; adaptiv hədləri tətbiq edin (hadisə zamanı 'max _ attempts' aşağı).

8) Protokollar və müqavilələr

HTTP

Kodlar: '408/429/5xx'.
Başlıqlar: 'Retry-After', 'RateLimit-', 'Idempotency-Key', 'Request-Id'.
Müştəri 'X-Request-Timeout '/' Deadline-At' ötürməlidir.

gRPC

Kontekstdən istifadə edin; 'UNAVAILABLE', 'DEADLINE _ EXCEEDED' hörmət edin, metodu retraj siyasəti.
İdempotent RPC üçün - retrajları açın; mutasiyalar üçün - yalnız idempotentliyin dəstəyi ilə.

9) Növbələr, fon tapşırıqları və inteqrasiya

At-least-once prosessorları → idempotent hərəkətləri, açar deduplikasiyası.
backoff üçün Delay queue (məsələn, 5s/30s/2m).
Dead-letter queue (DLQ) cəhd limiti və əl emalı ilə.
Outbox/CDC - təkrar əməliyyat bütövlüyünü pozmamaq üçün.

10) Hedging vs Retries

Hedging (güzgü sorğusu) quyruq gecikməsində yüksək tənqidi oxunuşlar üçün faydalıdır.
Məhdudlaşdırın: X% -dən çox olmayan sorğular, «start-grace» gecikməsi (məsələn, p95-lent), itirənlərin ləğvi.
Güclü idempotentlik olmadan qeyd əməliyyatlarına hedging tətbiq etməyin.

11) Telemetri və müşahidə

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Metriklər: retrajların nisbəti, retrajlardan sonra müvəffəqiyyət, p95/p99 «end-to-end», həddindən artıq, CB-nin işə salınması.
Audit qeydləri: yuxarı N «səs-küylü» açarlar/end-pointlər, 429/503 ilə korrelyasiya.

12) Test və xaos

Profillər: «mişar» (burst-sakitlik), «fırtına» (kütləvi taymautlar), «yapışqan» səhvlər (hər N-ci), latentlik quyruqları.
Limiter/cache/növbə storunun uğursuzluqları, clock-skew.
Ümumi müddəti (attempts + backoff) SLO-ya uyğun olduğunu yoxlayın.

13) Psevdokod siyasət

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) Konfiqurasiya şablon (nümunə)

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) Satış öncəsi yoxlama siyahısı

• Son tarixlər çağırışlar vasitəsilə yayılır; SLO ≤ ümumi müddəti.
• Jitter ilə backoff alqoritmi; Parametrlər yük testi ilə təsdiqlənir.
• İdempotentlik: qeydlər üçün açarlar/jurnallar/kompensasiyalar.
• Retray siyasətçiləri oxumaq və yazmaq üçün fərqlənir; respect `Retry-After`.
• Retras rəqabət və cəhdlərin ümumi sayı məhduddur.
• circuit breaker və rate limits ilə inteqrasiya xüsusi.
• Telemetri: etiketlər, metriklər, səbəblər; p95/p99 daşbordları, retradan sonra uğurların payı.
• «Fırtına» və quyruq gecikmə testləri, tapşırıqlar üçün DLQ.
• Müştərilər üçün sənədləşdirmə: kodlar/başlıqlar, backoff və ləğv nümunələri.

16) Tipik səhvlər

Taymaut/son tarix olmadan təkrar - «əbədi gözləntilər».
Jittersiz sabit fasilələr - sinxron dalğalar və DDoS-öz-özünə işləmə.
İdempotentlik olmadan təhlükəli qeydlərin retraisi - dubli və rasinxronizasiya.
«Retry-After» və CB siqnallarına məhəl qoymamaq - hadisənin eskalasiyası.
caps və admission control olmaması səbəbindən növbələrdə dar yerlər.
Səbəblər/retraj həllərinin telemetriyasının olmaması - «kor uçuş».

17) Sürətli reseptlər

Açıq oxu API: 3 cəhd, 'initial = 100ms', 'max = 1s', tam jitter, 5% trafikə qədər hedging.
Kritik qeydlər (ödəniş): 1-2 maksimum cəhd, ciddi zaman, məcburi 'Idempotency-Key', hedging olmadan.
Xarici inteqrasiya: hörmət '429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', çıxış axını limitləri.
Fon vəzifələri: delay-backoff (5s → 30s → 2m), DLQ, idempotent prosessorları.

Nəticə

Yaxşı təkrarlama siyasəti sürətli bərpa və nəzarət edilən uğursuzluq arasındakı balansdır. Deadline, idempotentlik, jitter ilə eksponensial backoff, rəqabətin məhdudlaşdırılması və infrastruktur siqnallarına hörmət retrayları "fırtına 'dan etibarlılığı artırmaq və SLO saxlamaq üçün bir vasitəyə çevirir.