限流器擋掉超量請求，換來三件事：防 DoS 耗盡資源、降成本、防伺服器過載。難的不是擋，是選對演算法與放對位置。
🧠 Core Ideas
TIP
限流器本質是「每個 key（IP / 使用者 / 端點）一個計數器或桶」，超過閾值就回 HTTP 429。放伺服器端或 API gateway——別放客戶端，客戶端可被偽造、也未必受你控制。
- 每個規則一個桶：每使用者每端點、每 IP、或全域共用。
- 常放在中介層 / API gateway（順帶做 SSL 終止、認證、IP 白名單）。
- 需求：低延遲、省記憶體、分散式共享、限流器自己掛掉不能拖垮全站。
⚖️ Tradeoffs
Token Bucket — 最常用，允許突發
- 桶以固定速率補 token，滿了溢出；每個請求耗一個 token，沒 token 就丟。
- 兩參數：桶大小、補充速率。
- 優點：好實作、省記憶體、允許短時突發（只要還有 token）。Amazon、Stripe 都用。缺點：兩參數難調。
Leaking Bucket — 固定流出速率
- FIFO 佇列，請求以固定間隔流出處理；佇列滿就丟。
- 適合需要穩定流出的場景（Shopify 用）。缺點：突發會用舊請求塞滿佇列，害新請求被擋。
Window 類 — 準確度 vs 記憶體
- Fixed window counter：每個時間窗一個計數器，簡單；但窗邊界會爆量（兩窗交界瞬間可過兩倍）。
- Sliding window log：記每個請求時間戳，準確；但耗記憶體。
- Sliding window counter：兩者混合，近似準確又省記憶體。
🔑 Takeaways
- 限流器 = 每個 key 一個桶 + 超量回 429，放伺服器端 / gateway，不放客戶端。
- 預設用 Token Bucket（好實作、允許突發）；要穩定流出用 Leaking Bucket。
- Fixed window 簡單但有邊界爆量問題，需要準確就上 Sliding window。
No notes yet — jot your takeaways or Q&A here.