Tasarım hızı sınırlayıcıları

1) Neden oran sınırlaması

Hız sınırlaması, API'lerin kullanılabilirliğini ve ekonomisini korur: taşkınları durdurur, geri çekilme patlamaları, kimlik bilgisi doldurma, pahalı işlemleri korur (para işlemleri, rapor oluşturma), bağımlı sistemlere (veritabanları/sağlayıcılar) olan yükü yumuşatır. İyi tasarım adalet, gecikmenin öngörülebilirliği ve açık SLO'lar sağlar.

Temel hedefler

RPS kararlılığı ve arka uç aşırı yük koruması.
Kontrollü "elastikiyet" (patlama ödeneği).
Müşteri farklılaşması (kullanıcı başına/kuruluş başına/anahtar başına/IP başına/bölge başına).
Değer modeli: farklı işlemler için farklı "fiyatlar".

2) Limit türleri

RPS limitleri: saniye/dakika başına istekler.
Kotalar: Dönem başına toplam bütçe (gün/ay).
Rekabetçilik: Eşzamanlı operasyonlar (ödeme, ağır iş).
Rate/Stripe Bytes/sn (Load/Unload).
Ağırlıklı sınırlar: talebin karmaşıklığa göre "maliyeti" (örneğin, GraphQL karmaşıklığı, toplu iş boyutu).
Uyarlanabilir: anomaliler durumunda sıkılır (şüpheli etkinlik/hatalar 401/403/5xx).

3) Algoritmalar ve ne zaman uygulanacağı

3. 1 Sabit pencere sayacı

Basit: aralık başına sayaç (örn. 100 r/dak).
Artılar: Minimum maliyet. Eksiler: Pencerenin sınırlarında "kenar patlamaları".

Ne zaman: yönetici panelleri, düşük doğruluk, düşük maliyet.

3. 2 Sürgülü pencere (günlük/sayaç)

Log - son isteklerin zaman damgalarını saklar, doğru, bellekte pahalı.
Sayaç: iki bitişik pencerenin ortalaması (yuvarlanma), doğruluk ve fiyattan ödün verme.

Ne zaman: orta trafiğin genel API'leri, karmaşık matematik olmadan düzgünlüğe ihtiyacınız var.

3. 3 Belirteç kovası

Parametreler: rate'r '(belirteçler/sn) ve capacity'b' (patlama). Her istek jetonu "yakar".
Artıları: doğal patlama ödeneği, basit uygulama. Eksiler: Kesin bir eşitlik yok.

Ne zaman: RPS için neredeyse her zaman,'b 'içinde "vole" gerekiyorsa.

3. 4 Sızdıran kova (damla)

Sabit bir hızda "sızıntı" olan kuyruk.
Artılar: hatta çıkış akışı. Eksiler: Daha fazla gecikme.

Ne zaman: harici "kırılgan" sağlayıcılara yumuşatma.

3. 5 GCRA (Genelleştirilmiş Hücre Hızı Algoritması)

• 'TAT _ next = max (TAT_current, now) + 1/r','şimdi <= TAT_current + burst/r'ise istek kabul edilir.
• Artıları: sıkı, doğru, küçük bellek (TAT tuşuna tutun). Eksileri: anlamak daha zor.

Ne zaman: sıkı kontrol ve pürüzsüzlük, dağıtılmış sınırlar gerekir.

3. 6 Rekabetçi semaforlar

Aktif operasyon sayacı; giriş - "bilet" varsa; çıkış - bırakma.
Ne zaman: uzun süren işlemler, iş parçacıkları, WebSocket, indirmeler.

4) Limit anahtar modeli

• 'client _ id'/' api _ key'/' user _ id'/' org _ id'
• 'IP/ASN/geo' (kaba koruma)
• 'uç nokta/yöntem' (sıcak yollar)
• 'scope/plan/tier' (para kazanma)
• 'idempotency _ key' (yazma işlemleri)
• Bir hiyerarşi kullanın: önce sıkı anahtar başına, sonra kuruluş başına, sonra global.

5) Maliyet modeli

• GraphQL: alan karmaşıklığı × derinlik.
• REST: yanıt/istek boyutu, işlem türü (okuma = 1, yazma = 3, rapor = 10).
• Toplu: 'cost = min (n, cap)'.
• "İstekler'değil, belirteçleri sınırlıyoruz: 'bütçe - = maliyet (q)'.

6) Dağıtılmış uygulama

6. 1 Kasa

Süreç içi: ultra hızlı, ancak genel bir sınır değil (yerel "yumuşak" sınırlar için uygun).
Redis: fiili standart. INCR/EXPIRE, Lua komut dosyaları (atomiklik), sürgülü pencere için ZSET, TTL ile anahtarlar.
Elçi/NGINX/Kong/Traefik: dahili filtreler; Çevre için uygun.
Servis Mesh: sidecar + global senkronizasyon yerel sınırları.

6. 2 Atomisite ve yarış

Redis'te Lua: bir adımda kontrol etme ve artırma.
GCRA: CAS/script ile bir TAT depolayın.
Saat tutarlılığı: NTP, monoton zamanlayıcılar.
Sharding: anahtarla tutarlı hash; "Sıcak" parçalardan kaçının.

6. 3 Coğrafi dağıtım

Bölgesel kümeler üzerindeki yerel sınırlar + üst küresel (kaba).
CRDT/replikasyon - dikkatli (gecikmeler, çift tüketim). Marjlı bölgesel limitler tercih edilir.

7) Politikalar ve önceliklendirme

Planlar: Farklı'r ','b', kotaları olan Ücretsiz/Pro/Enterprise.
Öncelikler: "Pahalı" rotalar daha az limit veya daha fazla maliyet alır.
Listeler: entegrasyonlar için allow-list, ASN/proxy/TOP tarafından reddedilir.
Eskalasyon: tekrar aşarsanız, sınırı düşürün, iş kanıtı/captcha/zorluklar girin.

8) Yapılandırma örnekleri

8. 1 Elçi (HTTP hız sınırı filtresi, sözde)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (lua + Redis, sözde)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 Rekabet limitleri (sözde kod)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 GCRA (pseudocode)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) Geri ödemeler, zaman aşımları ve devre kesici ile entegrasyon

Retry-budget: Retray'lerin payını ana trafiğin % X'i ile sınırlayın.
Jitter: backoff yaparken, her zaman jitter ekleyin - senkron patlamaları azaltır.
Devre kesici: yüksek bir hata varsa ('5xx', zaman aşımları), sınırları düşürün veya bazı yolları "salt okunur'olarak aktarın.
Hedging: düzgün; Bütçenizi iki katına çıkarmamak için maliyeti göz önünde bulundurun.

10) Gözlemlenebilirlik ve yönetim

Метрики: 'rps _ allowed', 'rps _ blocked', '429 _ rate', 'retry _ after _ avg', 'burst _ used', 'kontenjan _ kalan','aktif _ eşzamanlılık '.
Etiketler: limit anahtarı, bölge, uç nokta, plana göre.
Karar günlükleri (örneklenmiş): başarısızlık nedeni, mevcut sayaçlar, anahtar TTL.
Panolar: Anahtarlara/uç noktalara göre ısı kartları, "sıcak" istemciler.
Uyarılar: Kritik rotalarda 429> %2-5 büyüme, kotaların sık sık "tükenmesi", kırıkların dengesizliği.

11) Test ve doğrulama

Poliçelerin sözleşme testleri (if-then tabloları).
Yükleme: patlamalar (r'den x10), uzun platolar, "kirli" desenler (yavaş POST, uzun bağlantılar).
Kaos trafiği: düzensiz akışlar, saat kayması, Redis/mesh düşüşü.
A/B-dahil etme: Dahil edilmeden önce kanarya sunum sınırları, gölge çözümleri (log, ancak engellemeyin).

12) Kenar vakaları ve incelikleri

Saat eğriltme: İstemci başlıklarından değil, tek bir kaynaktan (sunucu) 'now ()' kullanın.
Idempotency-Key: yazmak için - retralarda amplifikasyonu azaltır.
Toplu işlemler: Toplu iş boyutunu ve toplam maliyeti sınırlar.
Long-poll/WebSocket: Kanal/abonelik sayısını ve süresini sınırlayın.
Soğuk başlangıç: Sayaçların/ön yüklemenin "sıcak" başlangıcı; Aksi takdirde sahte 429 patlamaları.
Hesaplamalı olarak pahalı talepler: iş mantığının yürütülmesine sınırlama.
TTL: Anahtarların TTL sınırları pencere + güvenlik marjını kapsayacaktır.

13) Antibot yükselmeleri

Aşamalar: Uyarı - 429 + 'Retry-After' - meydan okuma (captcha/bulmaca) - geçici blok.
Sinyaller: cihaz-parmak izi, imleç/zamanlama davranışı, TOR/proxy/hosting.
Politikalar deterministik ve adli tıp için tekrarlanabilir olmalıdır.

14) Güvenlik ve uyumluluk

Kritik rotalarda varsayılan olarak reddet (yazma/finans).
Denetim: Düzenleyici durumlar ve olay incelemeleri için sınırlarla ilgili kararları tutun.
PII: Limit anahtarları, kişisel verileri günlüklerde ifşa etmemelidir.

15) Prod Hazırlık Kontrol Listesi

• Limit anahtarları ve maliyet modeli tanımlanmıştır.
• Seçilen algoritma (token bucket/GCRA) ve depolama (Redis/gateway).
• Katman müşterileri + küresel sigortalar için politikalar.
• Uzun vadeli işlemler için rekabetçi limitler.
• Retry-bütçe, jitter ile geri dönüş, devre kesici ile entegrasyon.
• Panolar/uyarılar, örneklenmiş karar günlükleri.
• Kanarya açık ve gölge modu.
• Patlamaların testleri, uzun platolar, Redis başarısızlıkları, saat eğriliği.
• Müşteri belgeleri: 429, 'Retry-After' kodları, üstel geri dönüş örnekleri.

16) TL; DR

Redis/gateway ile token kepçe veya GCRA kullanın, limit tuşları tasarlayın ve maliyetler isteyin, uzun işlemler için rekabetçi semaforlar ekleyin, yeniden deneme bütçesi ve devre kesici ile entegre edin, 429 ve "patlama kapasitesini" izleyin, kanarya/gölge ile sınırları açın ve patlamaları ve depolama arızalarını test ettiğinizden emin olun