Oran limitleri ve kotalar

Hız limitleri ve kotalar, paylaşılan kaynaklara olan talebi yönetmenin temel mekaniğidir: CPU, ağ, veritabanı, kuyruklar, harici API'ler. Amaç adalet, SLO'ların öngörülebilirliği ve patlamalar, kötüye kullanım ve "gürültülü komşu'dan korunmadır.

1) Temel kavramlar

Hız sınırı - taleplerin/işlemlerin yoğunluğunu sınırlayın (req/s, msg/min, bytes/sn).
Patlama - ortalama oran üzerinde izin verilen kısa süreli patlama.
Kota - zaman penceresi başına hacim sınırı (belgeler/gün, GB/ay).
Eşzamanlılık sınırı - eşzamanlı işlemlerin kısıtlanması (eşzamanlı istekler/işler).
Kapsam - kapsam: kiracı başına, kullanıcı başına, belirteç başına, uç nokta başına, IP başına, bölge başına, özellik başına.

2) Sınırlayıcı algoritmalar

2. 1 Belirteç Kovası

Parametreler: 'Oran' (belirteçler/sn), 'patlama' (kova boyutu).
"Kredi'gibi işler: birikmiş belirteçler kısa zirvelere izin verir.
Harici API'ler ve kullanıcı istekleri için uygundur.

2. 2 Sızdıran Kova

Akışı sabit bir hızda düzgün bir şekilde "kanar".
Trafiği hassas arka uçlara yumuşatmak için iyidir.

2. 3 Sabit/Sürgülü Pencere

Sabit pencere: basit ama "pencere değiştirmeye" karşı savunmasız.
Sürgülü pencere: daha doğru, ancak hesaplama açısından daha pahalı.

2. 4 GCRA (Jenerik Hücre Hızı Algoritması)

Sanal varış zamanı açısından Token Bucket eşdeğeri.
Dağıtılmış sınırlayıcılar için doğru ve kararlı (daha az çelişkili durum).

2. 5 Eşzamanlılık Sınırları

Eşzamanlı işlemleri sınırlamak.
İplik/bağlantı havuzlarının tükenmesine ve hat başı engellemeye karşı korur.

3) Sınırların uygulanacağı yer

Sınırda (L7/API ağ geçidi): ana bariyer, hızlı arıza (429/503), ucuz çekler.
İç hizmetler: ağır işlemler için ek kapaklar (ihracat, raporlar, dönüşümler).
Dış sistemlere çıkışta: üçüncü taraflar için bireysel limitler (ceza önleme).
Kuyruklarda/işçilerde: paylaşılan havuzlara adalet.

4) Kapsamlar ve öncelikler (çok kiracılı)

Иерархия: Global> Bölge> Kiracı/Plan> Kullanıcı/Token> Uç Nokta/Özellik> IP/Cihaz.
Öncelik bilincinde: VIP/Enterprise daha fazla 'patlama've ağırlık elde eder, ancak genel SLO'ları kırmaz.
Sınır bileşimi: toplam tolerans ='min (global, bölgesel, kiracı, kullanıcı, uç nokta) '.

5) Hacim kotaları

Günlük/aylık kotalar: belgeler/gün, GB/ay, mesajlar/dak.
Yumuşak/sert eşikler: Uyarılar (%80/90) ve sert durdurma.
Roll-up: nesnelere göre muhasebe (tablolar, dosyalar, olaylar) ve faturalandırmaya "para çekme".

6) Dağıtılmış sınırlayıcılar

Gereksinimler: düşük gecikme süresi, tutarlılık, hata toleransı, yatay ölçeklendirme.

Yerel + olasılıksal senkronizasyon: yerel parça kovaları + periyodik senkronizasyon.
Merkezi mağaza: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: düzgün dağılımlı 'limit: {scope}: {id}: {window}' formunun anahtarları.
Saat eğriltme: "gerçeği" sınırlayıcı sunucuda saklayın, istemcilerde değil.
Idempotency: Idempotency-Keys yanlış ücretleri azaltır.

7) Kötüye kullanım ve koruma

Genel uç noktalar için Per-IP + cihaz parmak izi.
İş Kanıtı/anomalilerde CAPTCHA.
UX daha önemli olduğunda tam başarısızlık yerine yavaşlama (kısma) (arama komutları).
Uyarlanabilir sınırlar: Olaylar/pahalı bozulmalar için eşiklerin dinamik olarak azaltılması.

8) Müşteri davranışı ve protokolü

Kodlar: '429 Çok Fazla İstek' (oran), '403' (kota/plan aşıldı), '503' (koruyucu bozulma).

• 'Retry-After: ' - when to try again.

• 'RateLimit-Limit: ; w = '
• 'RateLimit-Kalan: '
• 'RateLimit-Reset: '
• Backoff: üstel + jitter (tam jitter, eşit jitter).
• Idempotency: 'Idempotency-Key' başlığı ve güvenli işlemlerin tekrarlanabilirliği.
• Zaman aşımları ve iptaller: Sınırlamaları "yakalamamak" için askıya alınan istekleri doğru şekilde kesintiye uğratın.

9) Gözlemlenebilirlik ve test

Теги: 'tenant _ id', 'plan', 'user _ id', 'endpoint', 'region', 'decision' (allow/deny), 'reason' (kota/oran/eşzamanlılık).
Metrikler: iş hacmi, 429/403/503 hata oranı, p95/p99 sınırlayıcı gecikmesi, anahtar önbellek isabet oranı, plan tahsisi.
Denetim günlükleri: blokların nedenleri, üst "gürültülü" anahtarlar.
Testler: yük profilleri "saw/burst/plateau", kaos - Redis/shard hatası, saat senkronizasyonu.

10) Faturalandırma ile entegrasyon

Kullanım sayaçları sınırda toplanır, idempotency ile toplu olarak (her N dakikada bir) toplanır.
Plan özeti: aşırı harcama - aşırı ücret veya planı geçici olarak artırma.
Tutarsızlıklar: uzlaşma kullanımı vs fatura; Deltayı uyarıyor.

11) İçeride adalet (kuyruklar, işçiler)

Ağırlıklı Adil Kuyruk/DRR: Plan ağırlığına göre kiracılara yuva tahsis etme.
Kiracı başına işçi havuzları: VIP/gürültülü katı izolasyon.
Kabul kontrolü: kotalar tükenirse uygulamadan önce başarısızlık; Kuyruklar kabarmaz.
Eşzamanlılık üzerindeki büyük harfler: Eşzamanlı ağır jabları sınırlayın.

12) Tipik plan profilleri (örnek)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Mimari referans (sözel şema)

1. Kenar/API ağ geçidi: TLS - ayıklama bağlamı (kiracı/plan) - sınırları/kotaları kontrol edin - RateLimit başlıklarını yerleştirin - log/trace.
2. Politika Motoru: Öncelik kuralları (VIP), uyarlanabilir eşikler.
3. Sınırlayıcı Mağaza: Redis/KeyDB (atomik ops, LUA), anahtar parçalama, çoğaltma.
4. Hizmetler: Ağır operasyonlar için ikincil limit ve kapaklar; idempotency; WFQ/DRR ile kuyruklar.
5. Kullanım/Faturalandırma: toplama, toplama, fatura, eşiklere göre uyarılar.
6. Gözlemlenebilirlik: Etiketli metrikler/günlükler/izler, kiracı başına gösterge panoları.

14) Satış öncesi kontrol listesi

• Limit kapsamları (kiracı/kullanıcı/belirteç/uç nokta/IP) ve hiyerarşileri tanımlanmıştır.
• Seçilen algoritma (Token Bucket/GCRA) ve 'rate/burst' parametreleri.
• Ağır operasyonlar için eşzamanlılık kapakları ve kabul kontrolü uygulandı.
• 'RateLimit-'ve' Retry-After 'başlıkları dahil; Müşteriler destek backoff + jitter.
• Sınırlayıcı dağıtılmış ve hata toleranslıdır (parçalar, çoğaltma, bozulma).
• Kullanım-toplama idempotent; Faturalandırma ile paket, aşırı harcama için uyarılar.
• Gözlemlenebilirlik: metrikler/yollar/etiketli günlükler, üst "gürültülü" tuşlar, değiştiriciler.
• Testler: patlamalar, "testere", stor arızası, saat eğriliği, soğuk başlangıç.
• Müşteri belgeleri: plan limitleri, 429/Retry-After örnekler, en iyi uygulamaları yeniden paylaşın.
• Dışlama Politikası: Sınırların geçici olarak nasıl ve ne zaman yükseltileceği.

15) Tipik hatalar

Kiracı başına/uç nokta başına olmadan genel sınır - "gürültülü komşu'tüm SLO'ları bozar.
'Patlama' eksikliği: UX kısa patlamalarda acı çekiyor.
Sadece sabit bir pencere kullanarak - "pencere sınırında çift vuruş".
Idempotency yoktur ve jitter ile retrays - tekrarların fırtınası.
Sınırlamalar yalnızca sınırda, hizmetlerde/kuyruklarda kapaklar olmadan - dahili "trafik sıkışıklığı".
Yanıtlardaki sınırların reddedilmemesi (hayır 'Retry-After', 'RateLimit-') - istemciler uyum sağlamaz.
Sınırlayıcı durumun OLTP veritabanında saklanması - yüksek gecikme ve sıcak kilitler.

16) Hızlı strateji seçimi

Tepe noktaları olan genel API'ler: Belirteç Kovası + büyük 'patlama', RateLimit - üstbilgiler, CDN/kenar önbelleği.
Dahili ağır jablar: eşzamanlılık kapakları + WFQ/DRR, kabul kontrolü.
Üçüncü taraflarla entegrasyon: ayrı çıkış limitleri, arabelleğe alma/geri alma.
SaaS çok kiracılı: limit hiyerarşisi (global - kiracı - kullanıcı - uç nokta), VIP önceliklendirme, aylık kotalar.

Sonuç

İyi oran limitleri ve kotalar, platform ile müşteri arasında bir sistem sözleşmesidir: kaynakların dürüst bir şekilde paylaşılması, ani artışlara karşı direnç, öngörülebilir SLO'lar ve şeffaf faturalandırma. Algoritmaları birleştirin (Token/GCRA + eşzamanlılık sınırları), bir osprey hiyerarşisi uygulayın, net başlıklar ve metrikler verin ve gerçek trafik profilleri altındaki şemaları düzenli olarak kontrol edin - bu şekilde platform agresif yük artışında bile sabit kalacaktır.