[ADP-43] API 限流

指導原則

應(SHOULD)至少對外部 API 受眾端點 audience>=PUBLIC_EXTERNAL 添加限流。
INFO
關於 API 受眾請參照 ADP-752。
應(SHOULD)對限流的端點添加 x-rate-limit
限流應(SHOULD)基於用戶、API 密鑰或 IP 地址來實施。

如果超過限流，應(SHOULD)返回與 HTTP Problem json 對齊的以下錯誤消息：

http

POST /search HTTP/1.1

HTTP/1.1 429 Too Many Requests
Retry-After: 60

{
  "type": "/problems/rate-limit",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "You have exceeded the rate limit of 1000 requests per minute.",
  "instance": "/search",
  "retryAfter": "PT1M"
}

應該(SHOULD)在 API 文件中說明限流規則。

實施建議

考慮使用令牌桶(token bucket)或漏桶(leap bucket)算法來實現限流。
考慮為不同端點或 HTTP 方法設置不同的限流。
可以為不同的客戶計劃提供分層限流。
定期監控限流使用情況，並根據需要調整限制。
實施警報系統，以便在用戶持續接近或超過限流時發出通知。

限流算法說明

令牌桶算法 (Token Bucket)：這種算法允許突發流量，通過在桶中存儲令牌來控制流量。每當請求到達時，系統檢查桶中是否有令牌。如果有，則請求被處理，並從桶中移除一個令牌；如果沒有，則請求被拒絕或延遲。
漏桶算法 (Leaky Bucket)：這種算法以固定速率處理請求，無論請求的到達速率如何。請求被放入桶中，桶以固定速率“漏出”請求。如果桶滿了，新的請求將被拒絕。
滑動窗口算法 (Sliding Window)：這種算法根據時間窗口來限制請求數量。它可以根據最近的請求數量來動態調整限流，允許在特定時間內的請求數量變化。
計數器算法 (Counter)：這種算法簡單地計算在特定時間內的請求數量，當請求數量超過預設的限制時，將拒絕後續請求。
每秒請求數 (QPS, Queries Per Second)：這是一個衡量系統處理請求能力的指標。通過設置 QPS 限制，可以控制系統在每秒內能夠處理的最大請求數，從而防止過載。
熔斷 (Circuit Breaker)：這是一種防止系統過載的策略，當系統檢測到錯誤率超過預設閾值時，會暫時停止對某些請求的處理，從而保護系統不被進一步損壞。熔斷器在一段時間後會自動恢復，允許系統重新處理請求。

這些算法和策略各有優缺點，應根據具體需求選擇合適的限流和保護措施。

[ADP-43] API 限流 ​

指導原則 ​

實施建議 ​

限流算法說明 ​

相關 ADP ​

[ADP-43] API 限流

指導原則

實施建議

限流算法說明

相關 ADP