Dağıtık Scraping’de Rotating Proxy: Tek Gateway, Çok Worker

Dağıtık scraping’de rotating proxy, birden çok worker’ın aynı gateway adresini paylaşmasıyla çalışır; adres sayısı aynı kalır, oturum, tempo ve kota kararlarını veren tek süreç ortadan kalkar. Tek makinede scraper hem kuyruğu hem oturumları hem de hız sınırını kendi belleğinde tutar. İşleri Redis ya da Celery gibi bir kuyruğa taşıyıp üç beş sunucuda worker başlattığınızda o bellek dağılır ve dört şey açıkça kurulmak zorunda kalır: oturum kimlikleri, hedef başına tempo, toplam eşzamanlı bağlantı ve kota sayacı.

Mimari üç parçadan oluşur. Ortada merkezî kuyruk vardır; çekilecek URL’ler ve yeniden denenecek işler orada durur. Kuyruğun çevresinde worker’lar vardır; her biri ayrı sunucu, sanal makine ya da konteynerdir ve kuyruktan iş alıp hedefe istek atar. Üçüncü parça gateway’dir: rotating ürünlerde proxy listesi yoktur, tek bir kimlikli adres vardır ve çıkış IP’sini o adresin arkasındaki havuz verir. Bu yüzden worker’lara proxy dağıtma diye bir iş yoktur; hepsi aynı adresi ortam değişkeninden okur. Tek adresin arkasında havuzun nasıl döndüğü gateway mantığı rehberinde anlatılır.

Aynı süreç içinde birden çok proxy adresini sırayla seçme, cooldown ve sağlık kontrolü ayrı bir konudur ve proxy havuzu yönetimi rehberindedir. Gateway kullanan dağıtık yapıda worker’ın elinde tek adres olduğu için havuzdan seçim diye bir adım yoktur; koordinasyon süreçler arasındadır ve oturum kimliği, hız bütçesi, bağlantı payı, yeniden deneme kuyruğu ve ölçüm olarak beş başlıkta toplanır.

Sticky oturum, gateway’de kullanıcı adına eklenen bir oturum parametresiyle tanımlanır; aynı parametreyle gelen istekler oturum penceresi boyunca aynı çıkış adresinden geçer. Parametrenin sözdizimi ürüne göre panelde yazar. Tek süreçte bu parametreyi üretmek kolaydır: bir sayaç tutarsınız, oturum-1, oturum-2 diye gider. Aynı kodu beş worker’da çalıştırdığınızda beşi de oturum-1’den başlar ve gateway beşini de aynı sticky oturuma, yani aynı çıkış adresine bağlar. Hedef, tek IP’den beş farklı çerez kavanozu ve beş paralel sayfalama görür; sticky kullanmanızın bütün amacı olan tutarlılık kaybolur ve tek adres beş kat yorulur.

Çözüm, oturum kimliğini worker’a özel yapmaktır. En sade biçimi worker kimliği artı yerel sayaçtır: w3-oturum-17 gibi. Worker kimliği konteyner adından, makine adından ya da deploy sırasında verilen bir ortam değişkeninden gelir; kod bunu başlangıçta okur ve her oturum adının önüne ekler. Sayaç yerine 8–12 karakterlik rastgele bir ek de kullanılabilir, ama worker önekini yine koruyun; çakışma olasılığı sıfıra inmez, sorunu bulurken hangi worker’ın hangi oturumu açtığını görmek işinize yarar.

Bir iş sticky oturum gerektiriyorsa, örneğin bir ürün listesinin ikinci ve üçüncü sayfası ilk sayfayla aynı IP’den çekilmeliyse, oturum kimliğini worker’da üretmek yerine işin kendisine yazın. Kuyruğa giren kayıt URL’nin yanında oturum kimliğini de taşır; sayfalama zinciri hangi worker’a düşerse düşsün o kimlikle istek atar. Böylece bir worker ölüp iş başka worker’a geçtiğinde hedef aynı adresten devam eden bir oturum görür. Hangi işin sticky, hangisinin istek başına rotasyon isteyeceği rotasyon aralığı rehberinde ayrılır; dağıtık yapıda bu karar işi kuyruğa yazan tarafta verilir, worker karar vermez.

Hedefin kabul ettiği tempo tek bir sayıdır ve worker sayısından bağımsızdır. Hız bütçesinin nasıl çıkarıldığı 429 rehberinde anlatılır; dağıtık yapının kendine özgü hatası, o bütçeyi her worker’a ayrı ayrı vermektir. Beş worker’a tek tek “saniyede iki istek” dediğinizde hedef saniyede on istek görür. Rotating proxy bu istekleri farklı adreslere dağıtır, ama bu, hedefin sınırını aşmanın yolu olarak kullanılmaz; bütçe hedefe uymak için vardır ve worker eklemek bütçeyi büyütmez.

Bütçeyi merkezîleştirmenin iki yolu vardır. İlki merkezî sayaçtır: Redis’te hedef alan adı başına bir anahtar tutulur, worker istek atmadan önce o anahtardan izin ister. Sabit pencereli sayım (INCR ile artır, EXPIRE ile pencere sonunda sıfırla) kurması en kolay olanıdır; jeton kovası (token bucket) ani yığılmayı daha iyi yumuşatır ama bir Lua betiği ya da küçük bir servis ister. İkinci yol merkezî dağıtıcıdır: kuyruğa işleri hedef başına belirlenen tempoda bırakan tek bir süreç vardır, worker’lar yalnız kuyruktan ne gelirse onu yapar ve hız konusunda hiçbir karar vermez. Sayaç yöntemi worker’ların boş durma süresini azaltır; dağıtıcı yöntemi worker sayısı değiştiğinde hiçbir ayar gerektirmez ve küçük ekipler için çoğu zaman yeterlidir.

Varsayım: hedef için dakikada 300 isteklik bir bütçe belirlediniz ve altı worker’ınız var. Merkezî bütçe dakikada 300’dür; her worker’ın 50 alması gerekmez, jetonu kim alırsa o atar. Hedef 429 döndürdüğünde bütçeyi merkezî olarak düşürün, örneğin bir süreliğine yarıya; yalnız 429’u alan worker’ın yavaşlaması diğer beşini durdurmaz ve hedef baskıyı görmeye devam eder. Bütçe tek yerde olduğu için düşürme ve geri yükseltme de tek yerden yapılır.

Eşzamanlı bağlantı sayısı dağıtık yapıda toplanır: toplam açık bağlantı, worker sayısı ile her worker’ın eşzamanlılık değerinin çarpımıdır. Tek makinede 40 eşzamanlı bağlantıyla sorunsuz çalışan bir ayar, aynı değerle sekiz worker’a kopyalandığında 320 bağlantı olur. GB bazlı rotating ürünlerde (IPv4 datacenter, IPv4 residential, mobile) sayılan şey aktarılan bayttır; hesabın eşzamanlı bağlantı sınırı ürün sayfasında yazmaz, worker sayısını artırmadan önce destekten sorun ve aldığınız sayıyı deploy dosyasına not edin.

Port bazlı IPv6 ürünlerinde bölüşüm daha görünürdür. Kataloğa göre rotating IPv6 datacenter ve residential paketleri 1, 5 ve 10 port olarak aylık 29, 80 ve 175 USD’dir ve her port kendi oturum ayarıyla çalışır. On portu dört worker’a dağıtıyorsanız her worker’a iki ya da üç port düşer ve port listesi worker’a ortam değişkeniyle verilir. Aynı portu iki worker’a vermek, o portun oturum ayarını iki sürecin paylaşması demektir; sticky kullanıyorsanız oturum çakışması bölümündeki sorun burada port düzeyinde tekrar eder. Port başına eşzamanlılık değeri de katalogda yazmaz; aynı şekilde destekten alın.

Toplam bağlantının sınırı aştığının üç belirtisi vardır: 407 hatalarının dalga hâlinde gelmesi, CONNECT aşamasında zaman aşımı ve ilk bayt süresinin bütün worker’larda birlikte uzaması. Tek bir worker’da görülen 407, kimlik bilgisi sorunudur; aynı anda hepsinde görülüyorsa toplam yüktür. Ayırmak için worker sayısını yarıya indirin: hata oranı düşüyorsa sınır proxy tarafındadır, düşmüyorsa hedef tarafındadır ve hız bütçesi bölümüne dönersiniz. Pratik kural: her worker eşzamanlılık değerini ortam değişkeninden okur, toplam tek bir yerde (deploy dosyası) tutulur ve worker eklerken toplam sabit kalır, pay küçülür.

Scrapy kullanıyorsanız dağıtık kuyruk için en bilinen araç scrapy-redis’tir; Scrapy’nin zamanlayıcısını ve tekrar filtresini Redis’e taşır. Resmî belgedeki ayar adları şunlardır: SCHEDULER olarak scrapy_redis.scheduler.Scheduler, DUPEFILTER_CLASS olarak scrapy_redis.dupefilter.RFPDupeFilter, bağlantı için REDIS_URL (REDIS_HOST ve REDIS_PORT’un önüne geçer), kuyruğu çalışma bitince silmemek için SCHEDULER_PERSIST. Kuyruk sınıfı varsayılan olarak PriorityQueue’dur; FifoQueue ve LifoQueue seçilebilir. Başlangıç adresleri RedisSpider sınıfıyla Redis’ten okunur; varsayılan anahtar spider adı artı start_urls’tür ve adres redis-cli ile lpush komutuyla eklenir. Belgenin kendi ifadesiyle “tek bir Redis kuyruğunu paylaşan birden çok spider örneği” başlatılır; bu rehberde anlatılan worker tam olarak o örneklerdir. Belge ayrıca Python 3.7, Scrapy 2.0 ve Redis 5.0 ve üstünü ister (12 Kasım 2026’da okundu).

scrapy-redis belgesinde proxy ya da proxy rotasyonu hakkında tek satır yoktur; kuyruk katmanı proxy’den habersizdir. Proxy ayarı Scrapy’nin kendi katmanında, Request.meta içindeki proxy anahtarı ya da bir downloader middleware ile yapılır; Scrapy ve Playwright rehberi bu kurulumu anlatır. Dağıtık yapıda eklenen tek şey, oturum kimliğinin ve deneme sayacının meta ile taşınmasıdır: iş kuyruğa geri döndüğünde başka bir worker alsa bile aynı oturum kimliğiyle ve doğru sayaçla devam eder.

Tekilleştirme kuyruğun en işe yarayan parçasıdır: RFPDupeFilter istek parmak izini Redis’te tuttuğu için aynı URL iki worker’a düşmez. Aynı mekanizma yeniden denemede ayağınıza dolanabilir; başarısız isteği kuyruğa geri koyarken dont_filter=True vermezseniz filtre onu daha önce görüldü diye eler ve iş sessizce kaybolur. Yeniden denenecek isteğin parmak izinin değişmediğini unutmayın; ya filtreyi o istek için kapatın ya da deneme sayısını URL yerine meta’da taşıyın.

Hangi hatanın yeniden deneneceği retry ve backoff rehberindeki tabloyla aynıdır; dağıtık yapıda değişen, denemenin nerede yapıldığıdır. 407 ve tünel hatası proxy tarafındadır: kısa bekleme ve aynı worker’da tekrar yeter, çünkü hedef bu isteği hiç görmemiştir. 429 ve 403 hedef tarafındadır: merkezî bütçe düşürülür, istek yeni bir oturum kimliğiyle kuyruğa geri verilir ve hangi worker alırsa o dener; böylece aynı worker’ın aynı hedefe döngüyle yüklenmesi biter. 404 denenmez. Devre kesici de merkezî olmalıdır: Redis’te hedef başına ardışık hata sayısı tutulur, eşik aşılınca bütün worker’lar o hedefin işlerini belirli bir süre kuyrukta bırakır. Tek worker’daki devre kesici diğerlerini durdurmaz ve hedef baskıyı görmeye devam eder.

Gateway paneli GB tüketimini hesap toplamı olarak gösterir; hangi worker’ın ne kadar yaktığını ayırmaz. Bu ayrımı istemci tarafında yaparsınız: her worker, aldığı yanıtın gövde ve başlık baytlarını hedef ve worker etiketiyle Redis’te bir hash alanına (HINCRBY) ya da kullandığınız metrik sistemine yazar. Sayılan bayt panelin saydığıyla birebir aynı olmaz, ama worker’lar arasındaki oran doğru çıkar; sorunun hangi worker’da olduğunu bulmak için oran yeter.

İzlenecek beş sayı: worker başına bayt, hedef başına bayt, başarılı sayfa başına bayt, worker başına 429 ve 407 oranı, kuyrukta bekleme süresi. Bir worker diğerlerinin iki katı GB tüketiyorsa ya tarayıcı gerektiren işler ona düşüyordur ya da yeniden deneme döngüsündedir; başarılı sayfa başına bayt ikisini ayırır. Worker başına 407 oranı tek bir worker’da yüksekse o worker eski kimlik bilgisiyle ya da yanlış adresle çalışıyordur; deploy sırasında ortam değişkeni güncellenmemiş olabilir. Kuyrukta bekleme süresi uzuyorsa worker sayısı yetmiyordur ya da merkezî bütçe işleri tutuyordur; ikisini ayırmak için bütçe sayacının ret oranına bakın.

Worker eklemek kotanın bitiş hızını artırır, toplamı değiştirmez. Kataloğa göre rotating IPv4 datacenter paketleri 10 GB için 6 USD, 50 GB için 30 USD ve 100 GB için 60 USD; rotating IPv4 residential 10 GB için 12 USD, 50 GB için 60 USD. Paket seçimi ve büyüme payı kota rehberinde anlatılır; dağıtık yapıya özgü olan, bütçe alarmını toplam tüketim üstünde kurmaktır; worker başına kurulan alarm toplamın ne zaman biteceğini göstermez. Başlamadan önce iki worker’lı bir pilot yapın: her iki üründe de 2 GB’lik giriş paketi vardır (datacenter 1 USD, residential 2,5 USD). Bir gün boyunca beş sayıyı toplayın, worker başına GB ve hedef başına bayt rakamlarını alın, sonra worker sayısıyla çarparak büyük paketi seçin.

Birden çok sunucu aynı rotating proxy hesabını kullanabilir mi? Evet; gateway tek bir kimlikli adrestir ve bu adres bütün worker’lara ortam değişkeniyle dağıtılır. Dikkat edilecek nokta, oturum kimliklerinin worker’a özel olması ve toplam eşzamanlı bağlantının destekten öğrendiğiniz sınırın altında kalmasıdır.

Worker sayısını artırmak hız sınırına takılmayı artırır mı? Bütçe worker başına veriliyorsa evet, çünkü hedefin gördüğü toplam tempo worker sayısıyla çarpılır. Bütçe Redis’te merkezî tutuluyorsa hayır; worker eklemek yalnız bütçenin daha hızlı tükenmesine ve kuyrukta bekleme süresinin kısalmasına yol açar, hedefin gördüğü tempo aynı kalır.

Sticky oturum dağıtık yapıda nasıl korunur? Oturum kimliğini worker’da üretmek yerine kuyruktaki işe yazarak. Sayfalama zincirinin her halkası aynı oturum kimliğini taşır ve hangi worker alırsa alsın gateway aynı çıkış adresini verir. Oturum penceresinin süresi ürüne göre panelde yazar; iş kuyrukta o süreden uzun beklerse oturum düşer ve zincir yeni bir kimlikle baştan başlar.

scrapy-redis proxy rotasyonunu kendisi yapar mı? Hayır. scrapy-redis yalnız kuyruğu, başlangıç adreslerini ve tekrar filtresini Redis’e taşır; belgesinde proxy geçmez. Proxy ayarı Scrapy’nin middleware ya da Request.meta katmanında kalır ve rotating gateway kullanıyorsanız rotasyonu gateway yapar.

Kotanın hangi worker’da bittiği nasıl anlaşılır? Panel toplamı gösterir, worker ayrımı göstermez. Her worker aldığı baytı kendi etiketiyle Redis’e ya da metrik sistemine yazarsa worker başına GB ve başarılı sayfa başına bayt görünür; en çok tüketen worker’ın tarayıcı işi mi aldığı yoksa yeniden deneme döngüsünde mi olduğu bu iki sayıyla ayrılır.