API yeniden deneme ve geri çekilme simülatörü
Bir API çağrısı 429 ya da 503 döndüğünde istemcinin ne kadar bekleyeceğini önceden görün. Gecikme ayarlarını girin; deterministik tohumlu jitter ile her denemenin zamanını, toplam beklemeyi ve çok koşudaki dağılımı görün. Hesap cihazınızdan çıkmaz.
Hazır ayar
Hesap tarayıcınızda yapılır; hiçbir değer sunucuya gönderilmez.
- Toplam bekleme (bu tohum)
- 25,47 sn
- Jitter'sız toplam bekleme
- 51 sn
- Ortalama toplam bekleme
- 25,06 sn
- %95'lik toplam bekleme
- 39,4 sn
- En uzun toplam bekleme
- 45,37 sn
Son üç değer, bu tohumdan başlayan 500 ardışık tohumla yapılan koşulara dayanır.
Zaman çizelgesi
Deneme tablosu
| Deneme | Tavan | Bekleme | Kümülatif |
|---|---|---|---|
| 1 | 200 ms | 120 ms | 120 ms |
| 2 | 400 ms | 179 ms | 299 ms |
| 3 | 800 ms | 682 ms | 981 ms |
| 4 | 1,6 sn | 1,07 sn | 2,05 sn |
| 5 | 3,2 sn | 559 ms | 2,61 sn |
| 6 | 6,4 sn | 3,37 sn | 5,98 sn |
| 7 | 12,8 sn | 3,5 sn | 9,48 sn |
| 8 | 25,6 sn | 15,99 sn | 25,47 sn |
Sahte kod
for attempt in 0..7: exp = min(30000, 200 * 2 ** attempt) delay = random(0, exp) sleep(delay)
Uygulamada dikkat
- 429 (Too Many Requests) ve 503 (Service Unavailable) yanıtlarında sunucu Retry-After başlığı gönderebilir (saniye ya da HTTP tarihi). Başlık varsa kendi hesabınızın altına inmeyin: bekleme = max(hesaplanan, Retry-After). Başlık yoksa geri çekilme sizin sorumluluğunuzdadır.
- Yeniden deneme yalnızca tekrarı zararsız isteklerde güvenlidir. GET, PUT ve DELETE doğası gereği idempotent sayılır; POST değildir. Ödeme ya da sipariş gibi POST çağrılarını yeniden denerseniz çift işlem riski doğar: Idempotency-Key başlığı kullanın ve sunucunun anahtarı gerçekten desteklediğinden emin olun.
- Jitter yok iken binlerce istemci aynı anda yeniden dener (thundering herd) ve düşmekte olan servisi tekrar devirir. Tam ya da eşit jitter bu yükü zamana yayar; ayrıca toplam yeniden deneme sayısını ve süresini sınırlayın, geçici olmayan hatalarda (4xx, 429 hariç) hiç denemeyin.
tavan(n) = min(üst sınır, başlangıç × çarpan^(n−1)) · tam: U(0, tavan) · eşit: tavan/2 + U(0, tavan/2) · ilişkili: min(üst sınır, U(başlangıç, önceki × 3))
Bu araç yalnızca bekleme sürelerini hesaplar; istek göndermez, ağ ya da sunucu davranışını ölçmez. Gerçek gecikmeler istek süresi, zaman aşımı ve istemci kitaplığının kendi ayarlarıyla değişir. Sonuçlar örnek amaçlıdır.
Entegrasyonlarınızda yeniden deneme, kuyruk ve hata yönetimini birlikte tasarlamak ister misiniz? Hangi çağrıların güvenle tekrarlanabileceğini ve nerede kuyruk gerektiğini ayırabiliriz.
Görüşme talep edin01
Nasıl kullanılır
A
Başlangıç gecikmesini, çarpanı, üst sınırı ve yeniden deneme sayısını girin ya da hazır ayarlardan birini seçin.
B
Jitter türünü seçin; çizelgede jitter'lı beklemeler (dolu işaret) ile jitter'sız referans (soluk işaret) yan yana görünür.
C
Toplam beklemeyi ve çok koşudaki dağılımı inceleyin; sahte kodu ya da sonucu kopyalayıp ekibinizle paylaşın. Aynı tohumla sonuç yeniden üretilir.
02
Üstel geri çekilme nasıl çalışır?
Her başarısız denemeden sonra istemci, bir önceki beklemeden daha uzun bekler: başlangıç × çarpan^(n−1). Bekleme üst sınırda durur. Böylece geçici bir arıza kısa denemelerle hızla atlatılır, uzun bir arızada ise servis yeniden denemelerle boğulmaz.
Tek başına üstel geri çekilme, aynı anda hata alan istemcileri aynı anda yeniden denetir. Jitter bu eşzamanlılığı bozar: istemcilerin bekleme süreleri rastgele dağılır, yük zamana yayılır.
03
Dört jitter türü
Tam jitter, beklemeyi 0 ile tavan arasında rastgele seçer; ortalama bekleme tavanın yarısıdır ve yük dağılımı en iyisidir. Eşit jitter tavanın yarısını sabit tutup yarısını rastgele yapar; asgari bir bekleme garantisi verir. İlişkili jitter, her beklemeyi bir öncekine bağlar ve çarpandan bağımsızdır.
Bu simülatör her üçünü aynı tohumla karşılaştırmanıza izin verir: tohumu sabit tutup türü değiştirin. Tek bir koşu yanıltıcı olabilir; bu yüzden toplam beklemenin ortalaması, %95'liği ve en büyük değeri 500 koşudan hesaplanır.
04
Hesaplama ve varsayımlar
Bekleme süreleri milisaniyeye yuvarlanır. Rastgelelik mulberry32 üreteciyle tohumdan türetilir; bu üreteç kriptografik değildir ve yalnızca simülasyon içindir. Gerçek istemciniz kendi rastgele sayı kaynağını kullanır, bu yüzden yalnızca dağılım örnektir, tek tek değerler değil.
İstek süresi, zaman aşımı ve devre kesici hesaba katılmaz: toplam bekleme yalnızca beklemelerin toplamıdır. Gerçek toplam süre, her denemenin kendi süresini de içerir.
Sık sorulanlar
- Hangi jitter türünü seçmeliyim?
- Çoğu durumda tam ya da eşit jitter yeterlidir. Çok sayıda istemcinin aynı kaynağa yüklendiği durumlarda tam jitter yükü en iyi dağıtır; bir asgari bekleme istiyorsanız eşit jitter'ı seçin. Jitter'sız yeniden deneme yalnızca tek istemcili, düşük yüklü senaryolarda kabul edilebilir.
- Retry-After başlığı varsa hesabımı yok mu sayarım?
- Hayır. Sunucu bir süre bildirdiyse bundan önce denemek faydasızdır; bekleme en az Retry-After kadar olmalıdır. Hesapladığınız geri çekilme bundan uzunsa onu kullanın. Başlık saniye sayısı ya da bir HTTP tarihi olabilir; ikisini de okuyun.
- Hangi hatalar yeniden denenmeli?
- Geçici olanlar: ağ kopması ve zaman aşımı, 429, 502, 503, 504 ve çoğu zaman 500. 400, 401, 403, 404, 422 gibi istemci hataları yeniden denenince aynı sonucu verir; denemeyin. Yeniden deneme sayısını ve toplam süreyi her zaman sınırlayın.
- POST isteğini yeniden denemek güvenli mi?
- Kendiliğinden değil. Zaman aşımı olduğunda sunucu işlemi tamamlamış olabilir; tekrar göndermek çift sipariş ya da çift ödeme yaratır. Idempotency-Key başlığı gönderin ve sunucunun aynı anahtarı aynı sonuçla yanıtladığını doğrulayın.
- Tohum ne işe yarar?
- Rastgelelik gerçek bir rastgele kaynaktan değil, tohumdan türetilir; aynı tohum aynı gecikmeleri verir. Böylece bir senaryoyu ekip arkadaşınızla paylaşabilir, test beklentisini sabitleyebilirsiniz. Gerçek istemcide tohumu sabitlemeyin.
Entegrasyonlarınızı hataya dayanıklı kuralım
CRM, ERP ve üçüncü taraf API bağlantılarında yeniden deneme, kuyruk ve idempotency tasarımını birlikte yapıyoruz. Ücretsiz keşif görüşmesinde mevcut akışınızı konuşalım.