Politikaları yeniden deneme ve geri alma

Tekrarlamalar (yeniden denemeler) geçici arızalardan kurtulmaya yardımcı olur, ancak yanlış yapılandırılırsa, trafik çığlarına, işlemlerin kopyalarına ve basamaklı düşüşlere neden olurlar. Güvenilir bir geri ödeme politikası her zaman son tarihler/zaman aşımları ile başlar, idempotensi dikkate alır ve backoff + jitter kullanır.

1) Temel prensipler

1. Önce zaman aşımı/son tarih, sonra geri çekilme. Zaman sınırı olmadan tekrarlamak sadece başarısızlığı uzatır.
2. Retray - sadece güvenli/idempotent işlemler için. Güvensiz olanlar için - idempotency-anahtarları ve işlem garantileri aracılığıyla.
3. Geri çekilme zorunludur. Dalgaları eşzamansız hale getirmek için jitter ile üstel veya GCRA benzeri.
4. Deneme sayısını ve toplam bütçe süresini sınırlayın. Kullanıcının SLO'sunu terk etmeyin.
5. Altyapı sinyallerine saygı gösterin. '429/503' + 'Retry-After', devre kesici durumu, sıra sınırları.

2) Zaman aşımları ve son tarihler (son tarih yayılımı)

Talep zaman aşımı <SLO hizmeti, son tarih zinciri aşağı yayılır (HTTP başlıkları/gRPC bağlam).
Zaman aşımı kompozisyonu: toplam (ilk deneme + geri alma + sonraki) ≤ kullanıcı son tarihi.
Okumalar/kayıtlar için farklı zaman aşımları: kayıtlar daha kısa ve daha katıdır; Okur hedging izin verir.

3) Idempotency ve güvenli tekrarlar

Okur (GET/idempotent RPC): '5xx', 'UNAVAILABLE', ağ zaman aşımları ile güvenli bir şekilde tekrarlanır.

• Sınırda 'Idempotency-Key' (HTTP) veya request-ID kullanın; Sunucu tekilleştirilmelidir.
• Idempotent işleyicileri yazın: "upsert",'en az bir kez "+ tazminat (saga).
• Dış ödemeler/yerleşimler - sadece idempotent anahtarlar ve işlem günlüğü ile.

4) Geri dönüş algoritmaları

Üstel: 'Temel 2 ^ girişimi', 'max _ backoff'ile sınırlanmıştır.
Dekore edilmiş Jitter (tam/eşit jitter) - müşterileri senkronize etmek için aralıkta rastgelelik.
GCRA/Token-Bucket benzeri gecikmeler: oran limitleri ile tutarlı.
Kenarlıklar: 'initial _ backoff' (50-200 ms okur; 200-500 ms kayıtlar), 'max _ backoff' (1-5 s), 'max _ elapsed' (örneğin, 3-10 s).

Önerilen desen üstel geri alma + tam titremedir.

5) Karar Politikalarını Tekrarlayın/Tekrarlamayın

• Ağ hataları/zaman aşımları, '429' (saygıyla 'Retry-After'), 'soft' '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE _ EXCEEDED'.

• '4xx' (bazı senaryolarda '409/429/408' hariç), iş hataları, '401/403', doğrulama hataları, açık 'DoNotRetry' flag.

• '409 Çatışma' - bazen konsensüs/kilitlerden sonra bir gecikme ile tekrarlanır.
• Kalıcı olarak tutarlı okumalar için '404' - bir veya iki kez küçük bir geri çekilme ile geri ödeme.

6) Eşzamanlılık kapakları ve "retray storm"

İstemci başına/kiracı başına/uç nokta başına eşzamanlı geri yüklemeleri sınırlayın.
İstek başına toplam deneme limiti (örn. 2-3).
Kuyrukları şişirmemek için giriş kontrolü yoluyla sıcak uç noktaları yavaşlatın.

7) Devre Kesici ve limitler ile etkileşim

CB açıksa, doğrudan retrays gerçekleştirmeyin - fallback'e gidin veya 'yarı açık' örnekleri bekleyin.
At '429' - saygı 'Retry-After'; Değilse, "yumuşak" geri alma kullanın.
Retrays gerginliği artırabilir; Uyarlanabilir eşikler uygulayın (bir olay için daha düşük 'max _ girişimleri').

8) Protokoller ve sözleşmeler

HTTP

Kodlar: '408/429/5xx'.
Başlıklar: 'Retry-After', aile 'RateLimit-', 'Idempotency-Key', 'Request-Id'.
Müşteri 'X-Request-Timeout'/' Deadline-At' (eğer öyleyse) göndermelidir.

gRPC

Bir son tarih ile bağlam kullanın; 'UNAVAILABLE', 'DEADLINE _ EXCEEDED', yöntem başına yeniden ödeme politikalarına saygı gösterin.
Idempotent RPC'ler için, retrays dahil; Mutasyonlar için - sadece idempotency desteği ile.

9) Kuyruklar, arka plan görevleri ve entegrasyonlar

En az bir kez işleyenler - idempotent eylemler, anahtar veri tekilleştirme.
Girişimler arasında geri çekilme için gecikme kuyruğu (örneğin, 5s/30s/2m).
Bir dizi deneme ve manuel işleme ile ölü harf kuyruğu (DLQ).
Giden kutusu/CDC - tekrarların işlem bütünlüğünü tehlikeye atmaması için.

10) Hedging vs Retries

Hedging, kuyruk gecikmesinde son derece kritik okumalar için kullanışlıdır.
Limit: Taleplerin en fazla % X'i, start-grace gecikmesi (örneğin, p95 gecikmesi), kaybedenlerin iptali.
Güçlü idempotency olmadan yazma işlemlerine hedging uygulamayın.

11) Telemetri ve gözlemlenebilirlik

Теги: 'tenant _ id', 'endpoint', 'entry', 'decision' (retry/skip), 'reason', 'backoff _ ms', 'deadline _ ms', 'idempotency _ key'.
Metrikler: geri çekilmelerin payı, geri çekilmelerden sonra başarı, p95/p99 "uçtan uca", aşılan son teslim tarihlerinin sayısı, CB tetiklemesi.
Denetim kayıtları: Üst N "gürültülü" anahtarlar/uç noktalar, 429/503 ile korelasyon.

12) Test ve kaos

Profiller: "saw" (burst-lull), "storm" (mass timeouts), "sticky" errors (every Nth), latency tails.
Torus sınırlayıcı/önbellek/kuyruk hataları, saat eğriltme.
Toplam sürenin (girişimler + geri alma) SLO'ya uyup uymadığını denetler.

13) Politika pseudocode

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) Yapılandırma şablonu (örnek)

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ış öncesi kontrol listesi

• Son tarihler çağrılar yoluyla yayılır; SLO ≤ toplam süresi.
• jitter ile backoff algoritması; Yük testi ile doğrulanmış parametreler.
• IDempotence: kayıtlar için anahtarlar/günlükler/tazminatlar.
• Retray politikaları okuma ve kayıtlar için farklılık gösterir; 'Retry-After'a saygı göster.
• Geri ödeme rekabet gücü ve toplam girişim sayısı sınırlıdır.
• Devre kesici ve hız limitleri ile entegrasyon yapılandırılmıştır.
• Telemetri: etiketler, metrikler, neden günlükleri; Panolar p95/p99, retrays sonra başarı payı.
• "Fırtınalar've gecikme kuyrukları testleri, görevler için DLQ.
• Müşteri belgeleri: kodlar/başlıklar, geri alma ve iptal örnekleri.

16) Tipik hatalar

Zaman aşımı/son tarih olmayan tekrarlar "sonsuz beklentiler'dir.
Titremesiz sabit duraklamalar - senkron dalgalar ve DDoS kendini sabote etme.
Güvensiz kayıtların idempotency olmadan yeniden denenmesi - kopyalar ve eşzamansızlık.
'Retry-After've CB sinyallerini görmezden gelmek - artan olay.
Kapak eksikliği ve giriş kontrolü nedeniyle kuyruklardaki darboğazlar.
Retrays nedenleri/çözümleri telemetri eksikliği - "kör uçuş".

17) Hızlı tarifler

Genel API okur: 3 girişimleri, 'başlangıç = 100ms', 'max = 1s', tam jitter, trafiğin %5 kadar hedging.
Kritik kayıtlar (ödeme): 1-2 maksimum deneme, katı zaman aşımı, zorunlu 'Idempotency-Key', riskten korunma yok.
Dış entegrasyonlar: '429/Retry-After', 'max _ entry = 3', 'max _ backoff = 2-5s', giden akış limitlerine saygı gösterin.
Arka plan görevleri: delay-backoff (5'ler - 30'lar - 2m), DLQ, idempotent işleyicileri.

Sonuç

İyi bir tekrar politikası, hızlı iyileşme ve kontrollü başarısızlık arasındaki dengedir. Son tarihler, idempotans, jitter ile üstel geri dönüş, rekabeti sınırlama ve altyapı sinyallerine saygı duyma, geri çekilmeleri bir "fırtına'dan SLO güvenilirliğini ve kalıcılığını artırmak için bir araca dönüştürür.