過載保護 (Overload Protection)

為什麼過載是核心問題：雪崩

流量不是平滑的曲線，它有尖峰、突發、惡意攻擊、節慶促銷、KOL 突然分享你的連結。當流量超過系統能承受的上限，若無任何保護機制，結果通常是雪崩：

請求堆積在佇列 → 延遲上升 → 執行緒池耗盡 → 記憶體膨脹 → GC 瘋狂
   → DB 連線池塞滿 → 下游服務被拖慢 → 整個系統停止回應

關鍵災難點：不只是超出容量的那部分請求失敗，而是「所有」請求都失敗了。10% 的超量流量可以打掛 100% 的服務。

六層防線的心智模型

過載保護工具可拆成六個層次，每層解決的問題不同：

外部流量
   ↓
[預防] Rate Limiting ── 擋惡意 / 超量的單一客戶端
   ↓
[預防] Concurrency Limiting ── 保護後端資源不被耗盡
   ↓
[吸收] Queue-based Load Leveling ── 吸收突發、平滑流量
   ↓  ← [擴容] Auto-scaling 持續在這層加機器
後端服務處理
   ↓
[隔離] Bulkhead ── 隔離不同依賴，防止局部過載蔓延
   ↓
[自保] Load Shedding + Request Prioritization ── 最後防線：選擇性丟棄
   ↑
[協同] Backpressure ── 整條鏈路協同減速訊號

Rate Limiting（速率限制）

最基本的入口防線：限制每個客戶端在單位時間內能發出的請求數。解決兩個問題：① 防止單一客戶端（或攻擊者）耗盡整個系統資源；② 確保不同客戶端之間的公平使用。

四種演算法對照

Fixed Window 的邊界突發：客戶端可在第 59 秒發 100 個、第 61 秒再發 100 個 → 跨視窗的 2 秒內實際放行 200 個。

Token Bucket（最常用）            Leaky Bucket（強制平滑）
  令牌以固定速率滴入                  請求任意速率進
       ↓                                  ↓
  ┌─────────┐ 上限 100             ┌─────────┐
  │ ●●●●●●● │ ← 累積可應對突發     │ ▓▓▓▓▓▓▓ │
  └─────────┘                      └────┬────┘
   每請求耗 1 令牌，空了就拒              ↓ 固定速率流出（不允許突發）

分散式 Rate Limiting

單機計數很簡單，但多台伺服器各自計數就失效——客戶端把請求分散打到不同機器就能繞過限制。

解法：集中式計數器（通常用 Redis）
  Server 1 ┐
  Server 2 ┼──→ Redis（INCR + EXPIRE / Lua script 原子操作）
  Server 3 ┘        ↑ 保證計數無 race condition

• 延遲代價：每個請求多一次 Redis 查詢，通常 < 1ms，可接受。
• 極低延遲需求：可用「本地計數器 + 定期同步」，犧牲一點精確性換速度。
• 滑動視窗常用 Redis Sorted Set：ZREMRANGEBYSCORE 移除窗外舊記錄 → ZCARD 數窗內請求 → ZADD 加入這次時間戳 → EXPIRE，全部包進 pipeline。

被限流時的正確回應

回傳 429 Too Many Requests，並用 header 告知客戶端何時可重試：

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000060

這讓客戶端能配合退避（backoff），而不是盲目重試加重伺服器壓力。詳見 01-Networking/07-Fault-Handling。

Concurrency Limiting（並發限制）

實作上常用 Semaphore：取得失敗（已達上限）立刻拋 OverloadError，而不是排隊等待。兩者通常一起用：rate limiting 擋突發流量，concurrency limiting 保護內部資源不被耗盡。

Queue-based Load Leveling（佇列削峰）

Rate / Concurrency limiting 都是拒絕多餘請求。但有時你不想拒絕，只是需要時間處理。

用戶請求 → API → 訊息佇列（Kafka / SQS）→ 工作服務（以自己能承受的速率慢慢處理）
                      ↑ 吸收瞬間尖峰        ↑ 後端看到的是平滑流量

對非同步任務特別有效：影片轉碼、Email 發送、報表生成、訂單確認——這些不需要在用戶等待的幾秒內完成。

詳見 09-Messaging-Coord/02-Queue、10-Design-Patterns/03-Long-Running-Tasks。

Auto-scaling（自動擴縮容）

前面手段都是在現有容量內管理流量；Auto-scaling 從根本上增加容量，需求增加時橫向擴展、減少時縮回省成本。

觸發指標對照

Reactive vs Predictive

Reactive（反應式）：流量來了 → CPU 升高 → 才觸發擴容
   ⚠ 啟動新實例 + 健康檢查 + 加入 LB 池 需要 1~3 分鐘
     這段空窗期過載仍在 → 需要 load shedding 撐住

Predictive（預測式）：根據歷史模式提前擴
   電商知道每天 9 點流量上來 → 8:50 就開始擴（AWS/GCP 提供 ML 預測）

最佳實務：Predictive 處理已知模式 + Reactive 處理預期外突發

延伸：02-Distributed-Systems/03-Scalability、11-Infrastructure/03-Container（K8s HPA）。

Load Shedding（負載卸除）

當 auto-scaling 來不及、佇列也有深度上限、rate limiting 只擋外部攻擊——這些都跟不上時，最後防線是主動丟棄部分請求，保護核心功能不崩潰。

選項 A：處理 30% 的請求，其他 70% 快速失敗（明確錯誤）  ← Load Shedding 選這個
選項 B：試圖處理 100%，結果系統崩潰，100% 全失敗

讓部分請求快速失敗，遠比讓所有請求一起慢死要好。

在哪裡做 Load Shedding

服務內部典型門檻：CPU > 85% 或 Memory > 90% → 回傳 503 Service Unavailable。

該丟棄什麼請求（不是隨機丟）

Request Prioritization（請求優先級）

Load shedding 決定「要不要丟」，request prioritization 決定「丟誰」。

過載時不是所有請求平等：

實作：請求進入服務時，依用戶身份 / 請求類型打上優先級標記，過載時低優先級先被丟（如用 priority queue，超容量時丟棄堆中優先級最低者）。

Bulkhead（艙壁隔離）

名字來自輪船設計：把船艙分成多個隔艙，一個艙進水不會讓整艘船沉沒。在系統設計裡，把不同工作負載 / 租戶 / 服務依賴隔離到獨立資源池，確保一部分過載不會耗盡整個系統。

三種常見實現

① 執行緒池隔離
   ┌── Thread Pool A（DB 操作，40 條）──┐
   ┌── Thread Pool B（支付 API，10 條）─┐
   支付 API 變慢 → 只耗盡 Pool B 的 10 條 → DB 的 Pool A 完全不受影響
   （沒有 bulkhead：支付的慢會吃光「共用」執行緒池，讓 DB 操作也跟著超時）
   → Netflix Hystrix 即以執行緒池隔離 + 熔斷器為核心

連線池隔離與讀寫分離詳見 05-Database-Advanced/03-Replication、10-Design-Patterns/01-Scaling-Reads。

Backpressure（背壓）

前面所有機制都是承壓的那一側自己做決定。Backpressure 不同：它讓下游主動告知上游「我撐不住了，慢一點」，讓壓力訊號沿鏈路向上傳播。

無 backpressure：上游不斷打向下游 → 佇列無限增長 → 崩潰
有 backpressure：下游發訊號 → 上游主動放慢 → 整條鏈路協同

面試話術

常見情境的標準答法：

• 電商秒殺（流量 100 倍）：商品詳情頁用 CDN + 靜態快取 讓 99% 讀取不打後端；下單進 Redis 隊列 + Lua 原子扣庫存，超賣直接回失敗；後端固定速率取單完全不受前端流量影響；配 rate limiting 防同一用戶重複提交。
• 多租戶 SaaS：每租戶獨立 rate limit 配額；大企業客戶獨立實例（bulkhead），中小客戶共用但各有 concurrency limit。
• 視訊轉碼：上傳後任務進 SQS，依佇列深度觸發 auto-scaling（>100 加一台、<10 持續 10 分鐘縮一台），高峰自動擴、閒置縮回省成本。

常見 Deep Dive

自我測驗重點

Related Notes

• 01-Networking/07-Fault-Handling — 429/退避、超時、熔斷與過載保護同屬韌性工具箱；idempotency 配合重試
• 01-Networking/06-Load-Balancing — 入口 load shedding 與健康檢查通常在 LB / API Gateway 這層做
• 11-Infrastructure/01-API-Gateway — Rate limiting、入口 load shedding 的標準落點
• 09-Messaging-Coord/02-Queue — Queue-based load leveling 削峰、佇列深度是 auto-scaling 訊號
• 09-Messaging-Coord/03-Kafka — 大規模削峰與背壓常用的訊息骨幹
• 10-Design-Patterns/02-Scaling-Writes — 寫入削峰、load shedding 對寫入路徑的取捨
• 10-Design-Patterns/03-Long-Running-Tasks — 非同步任務進佇列、用 worker 慢慢消費的範式
• 02-Distributed-Systems/03-Scalability — Auto-scaling 是橫向擴展的具體手段
• 01-Networking/02-TCP-vs-UDP — TCP receive window 是最底層的內建 backpressure
• 05-Database-Advanced/03-Replication — 讀寫分離連線池 = 資料庫層的 bulkhead
• 12-Ops-and-Reliability/01-Dealing-With-Contention — 過載常源於資源競爭；限流 / 隔離降低爭用
• 12-Ops-and-Reliability/04-Observability — P99 延遲 / 佇列深度監控是觸發 auto-scaling 與 shedding 的依據