Dağıtılmış bir oran sınırlama mimarisi, coğrafi olarak dağılmış düğümler arasında güçlü tutarlılığı düşük gecikme ile dengelemeyi gerektirir. Çözüm, aşağıdaki bileşenlere sahip hiyerarşik token bucket algoritmasını kullanır:
• Kenar yerel uygulama için Redis kümeleri ile atomik token tüketimi için Lua scriptleri
• Küresel kota uzlaşması için Apache Kafka başlıkları aracılığıyla Çapraz bölge senkronizasyonu
• Kullanıcı ilişkilendirmesi için Tutarlı Hashing ile koordinasyon yükünü minimize etme
Bu mimari, talep izleme için zorlanan setler (ZADD/ZREMRANGEBYSCORE) kullanarak Redis içinde kaydırmalı pencere kayıt semantiği uygular. Dedikodu Protokolü, oran sınırlama yapılandırma değişikliklerini ağ içinde yayarak, politika dağıtımında tek bir hata noktası ortadan kaldırır.
500K isteği saniyede işleyen küresel bir fintech platformu, Kara Cuma trafik zirveleri sırasında felaket başarısızlıkları yaşadı. Mevcut merkezi Redis oran sınırlayıcı, 150ms+ gecikme üretti ve bir tek hata noktası haline geldi, ödeme hizmetlerinde zincirleme zaman aşımına neden oldu.
İlk düşünülen çözüm, her NGINX kenar düğümünde tamamen yerel oran sınırlamasıydı. Bu yaklaşım, alt milisaniye gecikmesi sundu ve ağ bağımlılıklarını ortadan kaldırdı. Ancak, kullanıcıların kotalarını, kenar konumlarının sayısına eşit bir faktörle aşmalarına izin verdi, bu da iş uyum gereksinimlerini ihlal etti ve dağıtılmış altyapı boyunca potansiyel istismarları mümkün kıldı.
İkinci yaklaşım, dağıtılmış kilitleme için merkezi bir Redis Kümesi ile Redlock değerlendirilmiştir. Bu mükemmel tutarlılık sağlasa da, uluslararası kullanıcılar için kabul edilemez gecikme yarattı ve kritik bir ağ parçalanması zafiyeti tanıttı. Bölge içi bağlantı sorunları sırasında sistem, nazik bir düşüş yerine tamamen bozulmalar yaşadı.
Üçüncü çözüm, CRDT'ler (Çatışma Önleyici Çoğaltılabilir Veri Türleri) kullanarak sonunda tutarlı bir kaydırmalı pencere sayacı uyguladı. Bu, koordinasyon olmadan oran sınırlama yakınsaması için matematiksel garantiler sağladı. Ancak, finansal uyumun, katı harcama kontrolleri gerektirmesi nedeniyle, bölünme olayları sırasında geçici kota ihlallerine izin verdiği için kabul edilemezdi.
Seçilen mimari, kenar düğümlerinde TTL tabanlı kovalarla Redis kullanarak sert yerel uygulamalar ve küresel kota uygulaması için Kafka akışları ile asenkron uzlaşmayı bir araya getirerek iki katmanlı oran sınırlama uyguladı. Tutarlı Hashing, kullanıcıları belirli bölgesel kümelere yönlendirdi ve taleplerin yüzde 95'inin bölge içi koordinasyona ihtiyaç duymamasını sağladı. Bu, yerel uygulama için hemen gerekli olanla, nihai küresel tutarlılık arasında bir denge sağladı.
Uygulama, P99 gecikmesini 150ms'den 8ms'ye düşürdü ve 10 kat trafik zirvelerini bozulma olmadan yönetti. Sistem, bölgesel kesintiler sırasında yerel uygulamanın, hafif gevşek küresel kısıtlarla devam etmesine izin vererek, hizmetin kullanılabilirliğini sürdürüp nazikçe bozuldu.
Merkezi koordinasyon olmadan token bucket algoritmaları kullanıldığında dağıtılmış oran sınırlayıcılar arasındaki saat kaymalarını nasıl yönetirsiniz?
Saat senkronizasyonu, dağıtılmış oran sınırlama sistemlerinin gizli katili olarak karşımıza çıkıyor. Kenar düğümleri NTP kayması yaşadığında, token bucket hesaplamaları hatalı hale gelir ve bu da istekte bulunan patlamalarla birlikte yapılandırılmış limitlerin aşılmasına veya meşru trafiğin yapay bir şekilde kısıtlanmasına yol açabilir. Çözüm, kayma toleranslı tamponlar ile birleştirilmiş Lamport zaman damgaları veya Hibrit Mantıksal Zamanlama aracılığıyla mantıksal saatler uygulamayı gerektirir. Her token yenileme işlemi, zaman damgası farkının yapılandırılmış eşik değerleri aşması durumunda yenileme taleplerini reddetmeye yönelik tek yönlü zaman damgası doğrulaması içermelidir (genellikle 100-500ms). Bu, istismar edilebilirliği önlerken, küçük saat kayması olayları sırasında kullanılabilirliği sürdürür.
Yüksek eşzamanlılık ortamında oran sınırlama sayacı süresi dolduğunda tazikli sürü senaryolarını önlemek için hangi stratejiler uygulanmaktadır?
Tazikli sürü, binlerce isteğin birden sona eren bir oran sınırlama anahtarı keşfettiği ve eş zamanlı yenileme girişiminde bulunduğu durumda ortaya çıkar, bu da arka plandaki Redis örneğini aşırı yüklemektedir. Atomik artışlar için standart Lua scriptleri temel yarış durumunu çözer, ancak anahtar süresi dolduğunda stampede'i önlemede başarısızdır. Olasılıksal erken sona erme (aynı zamanda Jitter olarak da bilinir) uygulayın; burada her isteğin, gerçek sona ermeden biraz önce token bucket'ı yeniden oluşturma olasılığı vardır (genellikle %1). Alternatif olarak, oran sınırlarını basit sayaçlar yerine zaman serisi verileri olarak işleyen Redis Cell modülünü veya Redis akışlarını XADD işlemleri ile kullanın. Bu, tazikli sürüyü kod karmaşıklığı olmadan pürüzsüz, aşamalı bir yenileme desenine dönüştürür.
Bir kiracı, istek hacminde baskın olduğunda adaleti nasıl sağlarsınız, potansiyel olarak diğerlerini paylaşılmış bir oran sınırlama altyapısında aç bırakırken?
Adalet, basit kiracı bazlı sabit limitler yerine Ağırlıklı Adil Kuyruklama (WFQ) veya Hiyerarşik Token Bucket (HTB) algoritmalarının uygulanmasını gerektirir. Çok kiracılı bir Kubernetes ortamında, Envoy Proxy kullanmayı ve yerel oran sınırlama filtrelerinin yanı sıra uygulamalı eşzamanlılık kontrolü ile değerlendirmenizi öneririz. Kritik kavrayış, uygulama noktasını karar noktasından ayırmakla ilgilidir: Envoy hemen ağırlıklara göre önbellekten reddetmeyi ele alırken, merkezi bir kontrol düzlemi etcd çalıştırarak geçmiş tüketim kalıplarına göre ağırlıkları düzenli olarak yeniden hesaplar. Bu, gürültülü komşu problemlerini önlerken, ani ama meşru kiracıların düşük trafik dönemlerinde kaynaklara erişmesi konusunda yardımcı olur.