rate limiter's設計

1）為何評分限制

Rate limiting保護API的可用性和經濟性：停止盜版，「盜版」搶購，保護昂貴的交易（現金交易，報告生成），平滑依賴系統（DB/提供商）的負擔。良好的設計提供了公平性（公平性），潛伏性的可預測性和清晰的SLO。

關鍵目標

RPS穩定性和後端過載保護。
受控的「彈性」（爆發）。
客戶區分（per-User/per-Organization/per-Key/per-IP/per-Region）。
成本模型：不同交易的「價格」不同。

2）限制類型

RPS限制：每秒/分鐘查詢。
配額：每個月的總預算。
競爭力：同時操作（checkout, heavy job）。
速度/條帶：字節/秒（加載/卸載）。
加權限制：復雜性查詢的「成本」（例如GraphQL復雜性，batch大小）。
適應性：在異常情況下（可疑活動/錯誤401/403/5xx）收緊。

3）算法以及何時應用

3.1 Fixed window counter

簡而言之：每個間隔的計數器（例如100 r/min）。
優點：最低成本。缺點：窗戶邊界上的「邊緣條紋」。

時間：海軍上將面板，精度低，成本低。

3.2 Sliding window (log / counter)

Log：存儲最新查詢的時間戳,準確,內存路徑。
Counter：平均兩個相鄰窗口（滾動）,精度和價格權衡。

時間：公共平均流量的API，需要平穩而沒有復雜的數學。

3.3 Token bucket

參數：速度'r'（令牌/秒）和容量'b'（爆破）。每個請求「燃燒」令牌。
優點：自然爆發，簡單的實現。缺點：沒有嚴格的均勻性。

時間：如果需要「b」內的「齊射」，幾乎總是用於RPS。

3.4 Leaky bucket (drip)

以固定速度「泄漏」的隊列。
優點：水平輸出流。缺點：更多延誤。

時間：平滑到外部「脆弱」提供商。

3.5 GCRA (Generalized Cell Rate Algorithm)

• 「TAT_next=max（TAT_current，now）+1/r」，如果「now<=TAT_current+burst/r」，則接受該請求。
• 優點：嚴格，準確，幾乎沒有記憶（通過鍵存儲TAT）。缺點：難以理解。

時間：需要嚴格的控制和流暢，分布式限制。

3.6競爭信號燈

活動操作計數器；入場-如果有「門票」；出路-釋放。
時間：長運行操作,線程,WebSocket,下載。

4）限制密鑰模型

• `client_id`/`api_key`/`user_id`/`org_id`
• 'IP/ASN/geo'（粗略保護）
• 'endpoint/method'（熱線）
• 「scope/plan/tier」（貨幣化）
• 「idempotency_key」（寫操作）
• 使用層次結構：首先是嚴格的per鍵,然後是per組織,然後是全局。

5）請求權重（成本模型）

• GraphQL：跨領域的復雜性×深度。
• REST：響應/請求的大小，操作類型（read=1，write=3，報告=10）。
• Batch: `cost = min(n, cap)`.
• 我們限制令牌而不是「查詢」：「budget-=cost （q）」。

6）分布式實現

6.1個存儲

進程：超快，但不一般限制（適用於本地「軟」限制）。
Redis：事實上的標準。INCR/EXPIRE，Lua腳本（原子性），用於滑動窗口的ZSET，TTL鍵。
Envoy/NGINX/Kong/Traefik：嵌入式過濾器；方便周邊。
Service Mesh： sidecar+全局同步的本地限制。

6.2原子性和賽車

Lua in Redis：驗證和嵌入一個步驟。
GCRA：存儲一個帶有CAS/腳本的 TAT。
時鐘一致性：NTP，單調計時器。
Sharding：按鍵一致哈希；避免「熱」沙丁魚。

6.3地理分布

區域集群上的本地限制+全局頂部（coarse）。
CRDT/復制-小心（延遲、雙流量）。區域庫存限制是可取的。

7）政策和優先級

計劃：Free/Pro/Enterprise具有不同的「r」，「b」配額。
優先級：「昂貴」路線獲得較小的限制或更大的成本。
列表：allow-list for integrations, deny by ASN/proxy/TOR。
升級：如果再次超出-我們降低限制，我們引入工作證明/kapchu/挑戰。

8）Configs示例

8.1 Envoy （HTTP限制過濾器,偽）

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, pseudo）

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競爭限制（偽代碼）

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（偽代碼）

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）與retrais、taymout和circuit breaker整合

Retry-budget：將轉發份額限制在主流量的X%。
Jitter：在backoff時,始終添加jitter-減少同步爆發。
巡回賽決勝局：在高謬誤（'5xx'，timeouts）下，降低限制或將部分路線轉換為「只讀」。
刺傷：整潔；考慮到成本，以免預算支出增加一倍。

10）可觀察性和控制

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.

標簽：通過限制鍵，區域，結束點，計劃。
解決方案邏輯（采樣）：故障原因，當前計數器，密鑰的TTL。
Dashbords：按鑰匙/殘局計算的熱卡，「熱門」客戶。
Alerts：在關鍵路線上增長429>2-5%,經常出現「用盡」配額,沙丁魚失衡。

11）測試和驗證

合同策略測試（如果有的話，表）。
負載：bursts（x 10 from r），長高原，「臟」模式（慢開機，長連接）。
混沌流量：不均勻的流，時鐘漂移，Redis/mesh影響。
A/B開啟：在開啟之前,加那利滾動限制,陰影解決方案（我們計算但不鎖定）。

12） Edge案例和復雜性

Clock skew：使用單一來源（服務器）的「now（）」而不是客戶端標題。
Idempotency-Key：對於write-減少在後退時的放大。
擊球操作：限制擊球的大小和總費用。
Long-poll/WebSocket：限制頻道/訂閱次數和持續時間。
冷啟動：計數器/預裝的「溫暖」開始；否則，假爆發429。
計算上昂貴的查詢：在運行業務邏輯之前限制。
TTL：TTL密鑰邊界必須覆蓋窗口+庫存（安全馬爾金）。

13）反機器人升級

步驟：警告→ 429+「Retry-After」 → challenge（kapcha/pazl）→臨時單元。
信號：設備指紋,遊標行為/時間,TOR/代理/托管。
策略必須具有確定性，並且可以復制用於偽裝。

14）安全和合規性

Deny-by-default在關鍵路線（寫作/財務）。
審計：為監管案例和事件分析保留限額解決方案。
PII：限制密鑰不得在日誌中披露個人數據。

15）準備就緒支票清單

• 已定義限值鍵和成本模型。
• 選擇了算法（token bucket/GCRA）和存儲（Redis/網關）。
• 客戶級別政策+全球「保險絲」。
• 長期運營的競爭限制。
• Retry-budget, backoff with jitter,與circuit breaker集成。
• Dashbords/Alerts，采樣決策日誌。
• 金絲雀啟用和影子模式。
• Burst測試，漫長的高原，Redis失敗，clock skew。
• 客戶文檔：代碼429，「Retry-After」，指數備份示例。

16) TL;DR

使用帶有Redis/網關的 token bucket或GCRA，設計限值鍵和查詢成本，添加競爭性信號燈以進行長時間的操作，與復古預算和電路破解器集成，監視429和「暴風雨容量」，通過金絲雀/影子展開限值，並確保測試暴風雨以及存儲故障。