Web ve geliştirme / CLEARBYTE

HTTP 429: Retry-After ve güvenli yeniden deneme planı

HTTP 429, sunucunun istekleri hız sınırına tabi tuttuğunu belirtir. Yanıtı ve Retry-After başlığını okuyun, ortak istek hızını düşürün ve yalnızca güvenle tekrarlanabilen işlemleri yineleyin. Toplam süre ve deneme sayısı sınırlı olmalıdır.

Bu rehberde

Elle çalışan bir entegrasyon toplu işlemde başarısız olabilir: birden çok çalışan aynı hesap kotasını paylaşır. 429 tüm iş yüküyle ilgili bir geri bildirimdir; herkesin aynı anda yeniden denemesi yükü artırabilir.

Önce teşhisi kaydedin, sonra kuyruğun bütçesini hesaplayın. Buradaki sayılar hayalî bir hizmet içindir; gerçek sağlayıcının kuralları esas alınmalıdır.

Yanıtı hangi bileşenin verdiğini bulun

Zamanı, uç noktayı, yöntemi, durumu, istek kimliğini ve bekleme başlıklarını kaydedin; kimlik bilgileriyle kişisel verileri dışarıda bırakın. API, ters vekil ve CDN kaynaklarını ayırın. Hata sayfasının görünümü kaynağı kanıtlamaz.

Sınır IP, kullanıcı, uygulama veya kaynak başına olabilir. Dakikalık hız, eşzamanlılık ve günlük kota farklı çözümler ister. Birkaç saniye yavaşlamak tükenmiş günlük kotayı yenilemez.

  • İş sayısı mı, yeniden denemeler mi arttı?
  • Başka hizmetler, sekmeler veya anahtarlar aynı hesabı kullanıyor mu?
  • İstek sayısı, etkin işlemler, token veya başka kaynak mı ölçülüyor?
  • Toparlanma zamanı kullanıcının son süresine uyuyor mu?

Retry-After birimini doğru yorumlayın

Değer negatif olmayan tam sayı saniye ya da HTTP tarihi olabilir. 12, milisaniye değil 12 saniyedir. Tarih için güvenilir saat gerekir; geçmiş bir tarih sıkı yeniden deneme döngüsü başlatmamalıdır.

Sunucunun asgari beklemesine uyun ve rastgele dağılım ekleyin. Süre işin son sınırını aşıyorsa durun veya yeniden planlayın. Sunucu beklemesini daha küçük yerel üst sınıra indirmeyin.

Sınırlama yanıtından sonra örnek kararlar
GözlemAnlamıİş için eylem
Retry-After: 1212 saniye beklemeSüre uygunsa en az 12 saniye bekleyin
Retry-After: bir HTTP tarihiAlınma zamanına ve saat doğruluğuna bağlıNegatif olmayan aralığı hesaplayıp son süreyi kontrol edin
Başlık yok veya geçersizKullanılabilir gecikme verilmediSağlayıcı kuralını ya da sınırlı yerel beklemeyi uygulayın
Sağlayıcı günlük kotanın bittiğini söylüyorKısa denemeler kotayı geri getirmezKota açılana kadar durun

Tek çalışanı değil ortak kuyruğu bütçeleyin

Hesabın tamamına dakikada 120 istek tanınıyorsa 600 istek, başka trafik olmadan en az beş dakika ister. Hepsini on saniyede göndermek ve sonra uyumak yine bir trafik patlamasıdır.

Dakikada 90 hedefi saniyede 1.5, yaklaşık her 667 milisaniyede bir başlangıç demektir. 600 istek gecikme ve tekrarlar hariç 400 saniye sürer. Yanıtlar 2 saniyeyse ortalama etkin işlem 1.5 × 2 = 3 olur. Semafor etkin işlemleri, ortak hız düzenleyici başlangıçları sınırlar; tekrarlar da bütçeyi tüketir.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Başlık yoksa artan ve rastgele bekleme kullanın

Geçerli bekleme yoksa pencere bir, iki, dört ve sekiz saniyeye çıkarılıp gerçek gecikme rastgele seçilebilir. Bu dağılım çalışanların aynı anda uyanmasını önler.

Örnek işlev yalnızca gecikmeyi hesaplar. Çağıran taraf toplam süreyi, deneme sınırını, iptali ve güvenli tekrarı sağlamalıdır. Tarayıcıda CORS, Retry-After başlığının ayrıca erişime açılmasını gerektirebilir.

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

İşlemin etkisini çoğaltmayın

Veri okumakla ödeme oluşturmak aynı değildir. İlk isteğin etkisi ve idempotans sözleşmesini kontrol edin. Aynı mantıksal işlem için aynı anahtarı kullanın; her seferinde yeni anahtar yinelenen kayıt oluşturabilir.

SDK zaten tekrar deniyor olabilir. Dış döngü gerçek ağ denemelerini çarpar. Tüm katmanlara ortak sınır koyun; kullanıcı işleminde sonsuz yükleme yerine daha sonra deneme seçeneği sunun.

  • Toplam süre koyup bekleyen işleri iptal edin.
  • Eşzamanlılık ve başlangıç hızını ortak kotaya göre sınırlayın.
  • Beklemeden önce yanıt kaynaklarını serbest bırakın.
  • Tükenmiş kota veya kalıcı hatada durun.
  • Denemeleri ve son sonucu kaydedin.

Küçük kontrollü bir grupla doğrulayın

Yirmi okuma ile başlayın; ilk istekleri, tekrarları, başarıları ve son hataları sayın. Aralıkları ve etkin işlemleri kontrol edin. Gerçek hizmeti zorlamadan 429 ve Retry-After yanıtlarını benzetin.

Saniyelik istek ve eşzamanlılık hesaplarını plan için kullanıp gerçek kurallarla karşılaştırın. Hata sürüyorsa beklemeyi körlemesine artırmadan diğer istemcileri ve kota türünü araştırın.

Sık sorulan sorular

429, IP adresimin engellendiği anlamına mı gelir?

Her zaman değil. Hesap, token, yol, IP veya hizmet sınırlanıyor olabilir. Yanıtı ve sağlayıcı kurallarını inceleyin.

Retry-After yoksa hemen yeniden denemeli miyim?

Hayır. Başlığın yokluğu hemen deneme talimatı değildir. Sağlayıcı kuralını veya ortak bütçeli, sınırlı ve rastgele artan beklemeyi kullanın.

Daha fazla çalışan sorunu çözer mi?

Ortak kotaya baskıyı artırabilir. Sınırlanan boyutu bulun ve kuyrukla eşzamanlılığı koordine edin. Ancak sözleşme izin veriyorsa kapasite artırın.

Kaynaklar ve tanımlar

Yöntem kontrol tarihi: