限額和配額

利率極限和配額是管理共享資源需求的基本機制：CPU，網絡，DB，隊列，外部API。目標是公平（公平性），SLO的可預測性以及防止激增，濫用和「無聲鄰居」。

1）基本概念

利率限制-限制請求/操作強度（req/s, msg/min,字節/秒）。
Burst是允許的短期激增，超過平均水平。
Quota是每個時間窗口（文檔/每天，GB/月）的數量限制。
Concurrency cap-限制並發操作（並發查詢/job）。
Scope是一個應用領域：per-tenant，per-user，per-token，per-endpoint，per-IP，per-region，per-feature。

2）限制算法

2.1 Token Bucket（帶令牌的水桶）

參數：「rate」（令牌/秒）、「burst」（桶大小）。
作為「信用」工作：累積的令牌允許短峰。
適用於外部API和自定義查詢。

2.2 Leaky Bucket（漏水桶）

以恒定的速度「平穩」流。
有利於平滑交通到敏感的後端。

2.3 Fixed/Sliding Window

固定窗口：簡單但容易受到「窗口切換」的影響。
滑動窗口：更準確,但計算成本更高。

2.4 GCRA (Generic Cell Rate Algorithm)

就虛擬到達時間而言，相當於Token Bucket。
對於分布式限制器（較少沖突的狀態），準確且穩定。

2.5 Concurrency Limits

限制同時執行的操作。
防止流/連接池和「線頭塊」耗盡。

3）在哪裏應用限制

在邊界（L7/API網關）：主要障礙,快速故障（429/503）,低成本檢查。
在服務內部：重型操作（導出，報告，轉化）的額外上限。
進入外部系統：第三方的個人限制（反卑鄙的）。
在隊列/槍手：公平到共享池。

4） Scoops和優先級（multi-tenant）

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.

Priority-aware：VIP/Enterprise獲得更大的「爆破」和重量，但不打破一般的SLO。
極限組成：最終公差='min（全球，區域，影子，定制，末尾）'。

5）數量配額

每日生活津貼/月份配額：每日文件、GB/月報告、/分鐘報告。
軟/剛性閾值：警告（80/90％）和「硬性停止」。
滾動：按對象（表、文件、事件）和「刪除」計費。

6）分布式限量版

要求：低延遲、一致性、抗故障、水平擴展。

Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).

本地+probabilistic sync：本地shard水桶+周期同步。
Sharding：具有均勻分布的'limit： {scope}視圖鍵：{id} {window}。
Clock skew：在限制服務器而不是客戶端中存儲「真相」。
相似性：「操作」鍵（Idempotency-Key）減少了虛假註銷。

7）防暴和防守

用於公共殘局的Per-IP+設備指紋。
異常情況下的工作證明/CAPTCHA。
當UX更重要時，Slowdown（throttling）代替完全故障（搜索提示）。
Adaptive limits：在事件/昂貴的退化中動態降低閾值。

8）客戶行為和協議

編碼：「429 Too Many Requests」（rate），「403」（超過配額/計劃），「503」（保護性降解）。

• 「Retry-After： 」-何時再次嘗試。

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff：指數+jitter （full jitter, equal jitter）。
• 相似性：標題「Idempotency-Key」和安全操作的可重復性。
• 超時和取消：正確地打斷暫停的請求，以免被「捕獲」限制。

9）可觀察性和測試

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).

指標：帶寬、429/403/503故障率、p95/p99延遲限制、密鑰緩存的命中率、按計劃分配。
審核日誌：塊的原因,頂部「嘈雜」的密鑰。
測試：「pila/burst/plateo」負載配置文件，混亂-Redis/shard故障，時鐘同步。

10）與計費集成

Usage計數器在邊界處組裝，由batchas（每N分鐘）以等容性聚集。
計劃摘要：超支→超支或計劃臨時升級。
差異：usage與invoice的對賬；在三角洲。

11） Fairness內部（隊列,workers）

重量公平測驗/DRR：按計劃重量在租戶之間分配插槽。
工作池：硬絕緣VIP/噪音。
管理控制：如果配額用盡，則在執行前拒絕；隊列不會膨脹。
Caps on concurrency：限制同時重型喬巴。

12）示例計劃簡介（示例）

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）建築基準（言語方案）

1.Edge/API網關：TLS →檢索上下文（tenant/plan） →檢查限制/配額→標題RateLimit-→ log/trace。
2.策略引擎：優先級規則（VIP）,自適應閾值。
3.Limiter Store： Redis/KeyDB （atomic ops, LUA）,鍵卡,復制。
4.服務：重型手術的二級限制和上限；等效性；WFQ/DRR隊列。
5.Usage/Billing：收集、匯總、發票、閾值差。

6.Observability： 標記度量/logi/traces, dashbords per-tenant.

14）售前支票清單

• 定義了極限標記（tenant/user/token/endpoint/IP）及其層次結構。
• 選擇了算法（Token Bucket/GCRA）和「rate/burst」參數。
• 實現了用於重型操作的concurrency caps和admission control。
• 包括標題「RateLimit-」和「Retry-After」；客戶端支持backoff+jitter。
• 限制是分布式且具有抗故障性（shards,復制,降級）。
• Usage收集是偶數的；與計費掛鉤，超支。
• 可觀察性：標記度量/預告片/標記，前「嘈雜」鍵，alerter's。
• 測試：bursts，「pila」，stor故障，clock skew，冷啟動。
• 客戶文檔：計劃限制，示例429/Retry-After，最佳實踐中繼。
• 例外政策：如何暫時提高限制以及何時。

15）典型錯誤

沒有per-tenant/per-endpoint的全球限制-「噪音鄰居」打破了所有SLO。
缺乏「爆破」：UX短暫爆發。
僅使用固定窗口→「在窗口邊界處雙擊」。
在重播風暴→，沒有靜止和靜止。
限制僅在邊界上，服務/隊列中沒有caps →內部的「塞子」。
在響應中未排出限制（沒有「Retry-After」，「RateLimit-」）→客戶無法適應。
將限制狀態存儲在OLTP DB中→高潛伏期和「熱」鎖定。

16）快速選擇策略

具有峰值的公共API：Token Bucket+大型「爆破」，RateLimit是標題，CDN/edge kesh。
內部重型jobs：concurrency caps+WFQ/DRR，管理控制。
與第三方的集成：單獨的輸出，緩存/回收限制。
SaaS多重性：限制層次結構（global→tenant→user→endpoint），VIP優先級，每月配額。

二.結論

良好的評分限制和配額是平臺與客戶之間的系統合同：公平的資源份額，抗激增性，可預測的SLO和透明的計費。結合算法（Token/GCRA+concurrency caps）、實施魚鷹層次結構、提供清晰的標題和指標,並定期檢查真實流量配置文件下的電路-即使負載激增,該平臺仍將保持穩定。