Retry ve Backoff Stratejisi: Yeniden Deneme Kuralları

Retry ve backoff stratejisi, başarısız bir isteğin hangi koşulda, kaç kez ve ne kadar bekledikten sonra yeniden gönderileceğini önceden yazılmış kurallara bağlar. Retry yeniden deneme, backoff ise iki deneme arasındaki beklemenin her seferinde büyümesidir. Bu iki kural olmadan çalışan bir toplayıcı, geçici bir ağ sorununu kalıcı veri kaybına çevirir ya da tam tersine, aynı hatayı saniyede yüzlerce kez tekrarlayarak hedefi ve proxy havuzunu boş yere yorar.

Rotating proxy kullanan bir toplayıcıda bu strateji daha da belirleyicidir, çünkü her yeniden deneme çoğu zaman yeni bir çıkış IP’sinden gider. Doğru kurulmuş bir politika, geçici hataları fark edilmeden sindirir; yanlış kurulmuş bir politika ise GB kotasını başarısız isteklere harcar ve hedef sunucuda sizi saldırgan gibi gösterir. Kurallar hedef sunucunun döndürdüğü koda, hatanın hangi katmandan geldiğine ve isteğin tekrarının güvenli olup olmadığına göre ayrılır.

Her hata yeniden deneme hakkı kazanmaz. Bağlantı zaman aşımı, bağlantı sıfırlama ve TLS el sıkışmasının yarıda kesilmesi gibi ağ katmanı hataları en güvenli adaylardır: istek hedefe büyük olasılıkla hiç ulaşmamıştır ve yeni bir IP’den tekrarlanabilir. Sunucu tarafındaki 502, 503 ve 504 kodları da geçicidir; hedef ya da ara katman o an yanıt verememiştir ve bekleyip tekrar sormak anlamlıdır.

Buna karşılık 400, 404, 410 ve 422 gibi istemci kaynaklı kodlar yeniden denenmez. Aynı isteği aynı biçimde tekrar göndermek aynı cevabı üretir; burada düzeltilmesi gereken şey istek gövdesi ya da adres bilgisidir. 407, proxy kimlik bilgisinin reddedildiğini söyler; IP değiştirmek bir şey değiştirmez, kullanıcı adı, şifre ya da IP izni düzeltilir. Bu kodun ayrıntılı teşhisini bağlantı sorunları rehberinde anlattık.

İki kod ayrı bir sınıfa girer. 429 hız sınırıdır ve yeniden deneme yapılır, ama bekleme süresi varsa Retry-After başlığından okunur; bunu 429 rehberinde adım adım işledik. 403 ise hedefin sizi tanıyıp reddettiğini gösterir; yalnız bir kez, yeni bir IP ve temiz bir oturumla denenir. İkinci 403 geldiğinde istek kuyruğa geri alınır ve o hedef için IP türü ya da tarayıcı profili gözden geçirilir. Bir de sessiz hatalar vardır: 200 kodla dönen boş sayfa, doğrulama ekranı ya da beklenen alanı içermeyen gövde. Bunlar durum koduna bakılarak yakalanamaz; yanıt gövdesi için küçük bir doğrulama kuralı yazılır ve başarısız bulunan yanıt 403 gibi işlenir.

Bekleme süresi sabit tutulmaz, her denemede katlanır. En yaygın biçim taban süreyi deneme sayısının üssüyle çarpmaktır: taban bir saniye ise birinci yeniden denemede bir, ikincide iki, üçüncüde dört saniye beklenir. Bu diziye bir üst sınır konur; otuz saniyeyi aşan bir bekleme, isteği kuyruğa geri koyup başka işe geçmekten daha pahalıdır.

Üstel artış tek başına yetmez. Aynı anda hata alan elli worker aynı formülle aynı saniyede uyanır ve hedefi yine aynı anda vurur. Bu yüzden hesaplanan sürenin tamamı değil, sıfır ile o süre arasında rastgele seçilen bir değer beklenir; buna tam jitter denir. Üçüncü denemede dört saniye yerine sıfır ile dört saniye arasında rastgele bir süre beklemek, worker’ların yeniden deneme anlarını dağıtır ve hedefin gördüğü trafik eğrisini düzleştirir.

Sayılar varsayımdır; kendi ölçümünüzle değiştirin. Taban bir saniye, üst sınır otuz saniye ve en fazla dört deneme olsun. En kötü durumda bir istek bir, iki, dört ve sekiz saniyelik beklemelerle toplam on beş saniye bekler; jitter ile bu süre ortalamada yarıya iner. Saatte 36.000 sayfa toplayan bir işte isteklerin yüzde beşi bir kez yeniden deneniyorsa saatte 1.800 ek istek ve ortalama yaklaşık on beş dakikalık toplam bekleme ortaya çıkar; eşzamanlılık bu beklemeyi gizler, kota ise gizlemez.

Deneme sayısı üst sınırı çoğu toplayıcıda üç ile dört arasında kalır. Dördüncü denemede de başarısız olan bir istek büyük olasılıkla geçici bir sorun yaşamıyordur; hedef o adresi engellemiştir, sayfa kaldırılmıştır ya da istek biçimi yanlıştır. Böyle bir isteği beşinci kez göndermek yerine ayrı bir başarısızlık kuyruğuna yazmak ve toplama turu bitince toplu halde incelemek daha ucuzdur.

Deneme sayısına ek olarak istek başına bir toplam süre sınırı koyun. Bir sayfa için ayrılan süre bekleme ve denemelerle birlikte örneğin altmış saniyeyi aşıyorsa deneme sayısı dolmasa bile istek bırakılır. Bu sınır, ağır yanıt veren bir hedefin tüm worker’ları meşgul edip toplama turunu saatlerce uzatmasını önler.

Üçüncü sınır toplayıcı genelinde işler: yeniden deneme bütçesi. Son beş dakikada gönderilen isteklerin ancak belirli bir payı, örneğin yüzde onu, yeniden deneme olabilir. Bütçe dolduğunda yeni yeniden denemeler yapılmaz, istekler doğrudan başarısızlık kuyruğuna gider. Bu kural geniş çaplı bir kesintide, örneğin hedefin tümden kapandığı bir saatte, toplayıcının başarısız isteği on katına çıkarmasını engeller.

İstek başına rotasyonda her yeniden deneme kendiliğinden yeni bir IP’den çıkar; RotatingProxy kataloğundaki IPv4 datacenter ürünü bu modda çalışır. Bu, IP kaynaklı hatalar için en basit çözümdür, ama bir yan etkisi vardır: hata hedefin kendisinden geliyorsa IP değişimi hiçbir şey kazandırmaz ve yalnız bekleme süresi işe yarar. Bu yüzden ağ katmanı hatalarında bekleme kısa tutulup IP değişimine güvenilir; 5xx kodlarında ise IP değişimi önemsizdir, bekleme uzun tutulur.

Sticky oturumla çalışırken karar ikiye ayrılır. Okuma zaman aşımı, 502 ve 503 gibi hedef kaynaklı hatalarda aynı oturumda kalınır; oturum kimliği değişmez, yalnız beklenir. Bağlantı reddi, 403 ve doğrulama sayfası gibi IP ya da kimlik kaynaklı hatalarda oturum kapatılır ve yeni oturum kimliğiyle yeni bir IP alınır. IPv4 residential ve mobile ürünlerdeki sticky ve rotating oturum seçenekleri tam olarak bu ayrımı mümkün kılar: aynı oturumda tekrar mı, yeni oturumda tekrar mı sorusunun cevabı hata sınıfına göre verilir.

Hatanın proxy katmanından mı, hedeften mi geldiğini ayırt etmek bu kararın ön koşuludur. Proxy sunucusuna bağlanamama, 407 ve proxy’nin kendi 502 yanıtı istemci ile proxy arasındaki sorunlardır; hedef hiç görülmemiştir. Hedefin 503’ü ise proxy’nin ötesinden gelir. Loglarda bu ikisini ayrı alanlarda tutmak, haftalık incelemede hangi tarafın hata ürettiğini tek bakışta gösterir.

Bir isteğin yeniden denenmesi ancak tekrarın yan etkisi yoksa güvenlidir. Sayfa okuma, arama sonucu çekme ve ürün fiyatı sorgulama gibi GET istekleri bu sınıfa girer; aynı isteği on kez göndermek hedefte on kez aynı sayfayı üretir, başka bir şey değişmez. Form gönderme, giriş yapma, sepete ekleme ve yorum bırakma gibi POST istekleri ise tekrarlandığında ikinci bir kayıt oluşturabilir.

Okuma zaman aşımı POST isteklerinde en belirsiz durumdur: istek hedefe ulaşmış ve işlenmiş, yalnız yanıt size dönmemiş olabilir. Burada körlemesine yeniden deneme yerine önce durumun kontrol edilmesi gerekir; sepet gerçekten dolu mu, giriş gerçekten açıldı mı. Hedef bir idempotency anahtarı ya da istek kimliği kabul ediyorsa aynı anahtarla yeniden deneme güvenlidir, çünkü sunucu ikinci isteği ilkinin tekrarı olarak tanır.

Pratik kural şudur: yeniden deneme politikası istek türüne göre iki ayrı tabloya bölünür. GET için ağ hataları, 5xx ve 429 yeniden denenir. POST için yalnız bağlantı kurulamadan kesilen istekler yeniden denenir; bağlantı kurulduktan sonraki her hata kuyruğa yazılır ve insan ya da ayrı bir doğrulama adımı karar verir.

Yeniden deneme tek istek ölçeğinde çalışır; devre kesici ise hedef ölçeğinde. Bir hedef alan adı için art arda belirli sayıda istek, örneğin yirmi istek, başarısız olduysa o hedefe giden tüm istekler bir süre durdurulur. Bu süre içinde kuyruktaki istekler beklemede kalır, worker’lar başka hedeflerle ilgilenir. Kapalı bir hedefe binlerce yeniden deneme gitmez.

Devre açıldıktan belirli bir süre sonra, örneğin bir dakika geçince, tek bir deneme isteği gönderilir. Başarılı olursa devre kapanır ve trafik kademeli olarak eski hızına döner; başarısız olursa bekleme süresi katlanır. Aynı mantık proxy havuzu için de kurulur: belirli bir oturum kimliği ya da ülke havuzu üst üste bağlantı hatası veriyorsa o havuz geçici olarak listeden çıkarılır ve istekler başka bir havuza yönlenir.

Devre kesicinin eşiği hedefe göre değişir. Dakikada yüz istek attığınız bir hedefte yirmi ardışık hata birkaç saniye içinde oluşur ve devreyi erken açar; saatte on istek attığınız bir hedefte aynı eşik iki saat sürer ve hiçbir şeyi korumaz. Eşiği mutlak sayı yerine son bir dakikadaki başarısızlık oranı olarak tanımlamak her iki hızda da doğru çalışır.

Bu politika GB bazlı rotating proxy kullanan tipik bir sayfa toplayıcısı için başlangıç noktasıdır; sayıları kendi hedefinizin davranışına göre değiştirin. Bağlantı zaman aşımı ve bağlantı sıfırlama: yeni IP, taban bir saniye ile üstel bekleme, en fazla dört deneme. 502, 503 ve 504: IP değişimi önemsiz, taban iki saniye ile üstel bekleme, en fazla üç deneme. 429: Retry-After varsa o kadar, yoksa taban bir saniye, en fazla üç deneme. 403 ve doğrulama sayfası: yeni IP ve yeni oturum, tek deneme. 407, 400, 404, 410: deneme yok, doğrudan başarısızlık kuyruğu.

Üstüne iki genel sınır: istek başına toplam altmış saniye ve toplayıcı genelinde yüzde on yeniden deneme bütçesi. Hedef başına devre kesici: son bir dakikada başarısızlık oranı yüzde elliyi aşarsa bir dakika dur, sonra tek istekle yokla. Bu politika Python tarafında requests ve httpx için birkaç satırlık bir sarmalayıcıyla, Scrapy’de ise RETRY_HTTP_CODES, RETRY_TIMES ve özel bir retry middleware ile uygulanır; her iki kurulumu ilgili rehberlerde ayrıntılı anlattık.

Politikanın çalıştığını üç sayı gösterir. İlki yeniden deneme oranıdır: toplam istek içinde ikinci ya da sonraki deneme olan isteklerin payı. Bu oran hedef başına izlenir ve kalıcı olarak yüzde birkaçın üstündeyse hedefin toleransı ya da havuz türü yeniden gözden geçirilir. İkincisi başarı eğrisidir: isteklerin yüzde kaçı ilk denemede, kaçı ikincide, kaçı üçüncüde başarıya ulaşıyor. Başarının büyük bölümü ikinci denemeye kayıyorsa ilk denemedeki bekleme ya da eşzamanlılık yanlış ayarlanmıştır.

Üçüncü sayı kotadır. GB bazlı paketlerde her yeniden deneme, başarısız olsa bile, proxy üzerinden geçen trafiğiyle kotadan düşer. Yüzde beşlik bir yeniden deneme oranı, aynı işin kotasını kabaca yüzde beş artırır; bir yanıt gövdesi büyükse, örneğin sayfanın tamamı okunduktan sonra doğrulama kuralı başarısız sayıyorsa, maliyet daha da yüksektir. Loglarda her isteğe deneme numarası, hata sınıfı, beklenen süre ve kullanılan oturum kimliği yazıldığında bu üç sayı tek bir sorguyla çıkar. Kota planlamasının geri kalanını GB bazlı paket seçimi rehberinde ele aldık.