高可用防禦：限流、熔斷與快取雪崩

高可用防禦的所有機制，都是在解決同一個問題。先把那個問題看清楚。

起點：下游只是「變慢」，不是「掛掉」

訂單服務 → 呼叫 → 會員服務（正常 50ms，現在變成 5 秒）

① 每個請求佔住一條 Tomcat 執行緒 5 秒（原本 50ms）
② 同樣的 QPS 下，同時在處理的請求數暴增 100 倍
③ Tomcat 執行緒池（預設 200）很快被佔滿
④ 新的請求開始排隊 → 連「首頁」這種完全無關的 API 也回不了
⑤ 上游的呼叫方逾時 → 重試 → 流量再放大 2～3 倍
⑥ 訂單服務整個沒有回應 → 它的上游也開始重複同樣的過程

為什麼「變慢」比「掛掉」更危險

• 掛掉：連線立刻被拒絕，執行緒馬上釋放，影響範圍有限
• 變慢：執行緒被佔住但不釋放，資源被慢慢吃光，而且監控上看起來一切正常（沒有錯誤率、沒有 5xx，只有延遲上升）

這跟 Java 後端底層 ch03 的連線池、ch05 的執行緒池是同一件事：共用的有限資源被慢速操作佔住。

四道防線，各擋一段

① 超時       —— 不讓單一請求佔住資源太久      （最基礎，也最常被忘記）
② 快取       —— 讓大部分請求根本不用碰到下游
③ 限流       —— 超過處理能力的流量直接擋在門外
④ 熔斷／隔離 —— 下游已經壞了就不要再打，並限制受害範圍

在談熔斷與限流之前，先確認一件事：你的每一個外部呼叫，都有設超時嗎？

沒設超時等於沒有上限

大多數 HTTP client 的預設是「無限等待」或「非常長」：

RestTemplate（無設定）        → 無限等待 ★
OkHttp 預設                   → 連線 10s、讀取 10s
Feign（無設定）                → 依底層 client，常常也是無限
JDBC（無設定）                 → 依驅動，可能無限

三種超時要分清楚

• 連線逾時（Connect Timeout）——建立 TCP 連線的上限。可以設得很短（1～3 秒），因為連不上通常是立刻就知道的。
• 讀取逾時（Read / Socket Timeout）——等待回應的上限。這是最關鍵的一個。
• 整體逾時——包含重試在內的總時間上限。很多人只設前兩個，結果配上 3 次重試，實際最壞等待時間變成三倍。

怎麼決定讀取逾時的值

不要用「感覺」，用下游的 P99 延遲：

讀取逾時 ≈ 下游 P99 × 1.5 ～ 2

例：下游 P99 是 200ms  →  設 300～400ms
    而不是「保險起見設 30 秒」

還要往上游對齊

使用者端逾時 30s
  > 閘道逾時 10s
    > 服務 A 逾時 5s
      > 服務 B 逾時 2s   ← 越下游越短

如果內層比外層長，外層放棄之後內層還在跑 —— 白白佔住資源

現象

攻擊者（或 bug）不斷查詢 id = -1 這種不存在的資料

① 查快取 → 沒有（因為資料本來就不存在）
② 查資料庫 → 也沒有
③ 因為查不到，所以「沒有東西可以寫進快取」
④ 下一個請求重複 ①②③

→ 每一個請求都直擊資料庫，快取形同虛設

防禦一：快取空值

if (db 查不到) {
    redis.set(key, "NULL_PLACEHOLDER", Duration.ofMinutes(2));  // 短 TTL
}

• 優點：實作最簡單
• 缺點：如果攻擊者每次用不同的 id，會塞滿大量無用的 key。所以 TTL 一定要短（幾分鐘），而且最好用獨立的 key 前綴方便清理。

防禦二：布隆過濾器（Bloom Filter）

啟動時把所有存在的 id 灌進布隆過濾器

查詢時：
  filter.mightContain(id) == false  →  100% 不存在，直接返回，連 Redis 都不用查
  filter.mightContain(id) == true   →  「可能」存在，才往下查

還有一個更基本的防禦

參數校驗。`id = -1` 這種明顯不合法的值，在進到快取邏輯之前就該被擋掉。很多「穿透攻擊」其實只是缺少基本的輸入驗證。

現象

某個超熱門商品的快取，TTL 到期的那一毫秒

① 5000 個並行請求同時查快取 → 全部 miss
② 5000 個請求同時衝向資料庫查同一筆資料
③ 資料庫瞬間被打爆
④ （如果撐過去）5000 個請求各自把結果寫回快取 —— 重複做了 4999 次白工

防禦一：互斥鎖（只讓一個人去查）

String value = redis.get(key);
if (value != null) return value;

// 只有搶到鎖的那一個執行緒去查 DB
if (redis.setIfAbsent(lockKey, "1", Duration.ofSeconds(10))) {
    try {
        value = db.query(id);
        redis.set(key, value, ttl);
    } finally {
        redis.delete(lockKey);
    }
} else {
    Thread.sleep(50);          // 其他人稍等一下
    return redis.get(key);     // 再讀一次，此時應該已經有了
}

防禦二：邏輯過期（不設真的 TTL）

存進快取的是一個包裝物件：
{ "data": {...}, "expireAt": 1754300000 }

查詢時：
  ① 一定拿得到（Redis 上沒有真正過期）
  ② 檢查 expireAt 是否已過
  ③ 若已過期 → 「先回傳舊資料」，同時開一個非同步任務去更新

→ 沒有任何請求需要等待，代價是短時間內會讀到稍舊的資料

防禦三：熱點 Key 乾脆不過期

對於「首頁配置」「熱門排行」這種數量少但存取量極高的資料，直接不設 TTL，改由更新資料時主動刷新快取。這樣就沒有過期的瞬間。

兩種不同的雪崩

類型一：大量 Key 在同一時刻集體過期

系統啟動時預熱，一次寫入 10 萬個 key，TTL 全部設 1 小時
→ 一小時後，10 萬個 key 在同一秒集體失效
→ 所有流量同時打向資料庫

防禦：TTL 加隨機值。

// ❌ 全部一樣
redis.set(key, value, Duration.ofHours(1));

// ✅ 加上隨機抖動，把過期時間打散
long ttl = 3600 + ThreadLocalRandom.current().nextInt(600);   // 1 小時 ± 10 分鐘
redis.set(key, value, Duration.ofSeconds(ttl));

類型二：Redis 整個不可用

這個更嚴重——所有快取瞬間消失，全部流量直擊資料庫，而資料庫的處理能力通常只有快取的幾十分之一。

• 高可用部署：Redis Sentinel 或 Cluster，避免單點
• 多級快取：本地快取（Caffeine）＋ Redis。Redis 掛了還有本地快取擋一層
• 對資料庫做限流／熔斷：這是最後的保險——寧可讓一部分請求失敗，也不要讓資料庫被打死而全部失敗

三兄弟的一句話分辨

穿透 —— 資料「本來就不存在」，快取永遠填不上
擊穿 —— 單一熱點 Key 剛好過期的那一瞬間
雪崩 —— 大量 Key 同時失效，或整個 Redis 掛掉

限流演算法不用背——它們是一條演進線，每一個都在解決前一個的缺陷。

① 固定窗口計數器（最直覺）

每分鐘最多 100 次。用一個計數器，每分鐘歸零。

② 滑動窗口（修掉臨界問題）

把一分鐘切成 6 個 10 秒的小格子，統計「最近 6 格」的總和。
時間往前走一格，就丟掉最舊的一格。

• ✅ 沒有臨界問題，統計區間永遠是「最近一分鐘」
• ❌ 格子切越細越精確，但記憶體成本越高
• ❌ 還是不能平滑流量——一分鐘的額度可能在前 5 秒就被用光

③ 漏桶（修掉「不平滑」）

請求先進桶排隊，然後以「絕對恆定」的速率流出。
桶滿了就拒絕。

• ✅ 輸出速率完全恆定，下游收到的壓力非常穩定
• ❌ 無法應付突發流量——就算系統明明有餘力，也只能按固定速率放行

④ 令牌桶（修掉「無法吸收突發」）

以固定速率往桶裡「放令牌」，桶有容量上限。
請求要先拿到令牌才能通過。

關鍵：閒置時令牌會累積起來
→ 突然來一波流量時，可以一口氣消耗掉存量令牌
→ 既有長期的平均速率限制，又能吸收短時突發

單機限流 vs 分散式限流

限流保護的是自己（別讓太多流量進來）；熔斷保護的是自己和下游（別再打一個已經壞掉的服務）。

為什麼「已經壞了就不要再打」很重要

• 對自己：每個注定失敗的呼叫，都要先佔住執行緒等到逾時。快速失敗才能把資源留給還能成功的請求。
• 對下游：一個正在掙扎的服務，如果還持續收到流量，永遠沒有機會恢復。

三個狀態

┌──────────┐  失敗率超過閾值   ┌────────┐
│  CLOSED  │ ───────────────→ │  OPEN  │
│ （正常）  │                  │（跳閘） │
└──────────┘                  └────┬───┘
      ↑                             │ 等待一段時間
      │ 測試成功                     ↓
      │                     ┌──────────────┐
      └──────────────────── │  HALF_OPEN   │
            測試失敗 → OPEN  │（放少量測試）  │
                            └──────────────┘

• CLOSED——正常放行，同時統計失敗率
• OPEN——直接失敗，連打都不打（Fail Fast），走降級邏輯
• HALF_OPEN——等待時間到了之後，放幾個請求去探路。成功就回到 CLOSED，失敗就退回 OPEN 再等

Resilience4j 的關鍵參數

resilience4j.circuitbreaker:
  instances:
    memberService:
      slidingWindowType: COUNT_BASED      # 或 TIME_BASED
      slidingWindowSize: 100              # 統計最近 100 次呼叫
      minimumNumberOfCalls: 20            # ★ 至少 20 次才開始判斷
      failureRateThreshold: 50            # 失敗率 > 50% 就跳閘
      slowCallDurationThreshold: 2s       # ★ 超過 2 秒算「慢呼叫」
      slowCallRateThreshold: 50           # 慢呼叫率 > 50% 也跳閘
      waitDurationInOpenState: 30s        # OPEN 狀態等 30 秒
      permittedNumberOfCallsInHalfOpenState: 5

回到第一張卡的關鍵問題：故障之所以會擴散，是因為所有功能共用同一個執行緒池。

艙壁模式（Bulkhead）

名字來自船艙——船體被隔成多個防水艙，一個艙進水不會讓整艘船沉沒。

沒有隔離：
  [ 所有請求 ] → 共用 200 條執行緒
  會員服務變慢 → 200 條全被佔住 → 訂單、商品、首頁全部一起死

有隔離：
  會員服務  → 專屬 20 條
  商品服務  → 專屬 20 條
  訂單服務  → 專屬 20 條
  會員服務變慢 → 只有那 20 條被佔住 → 其他功能完全不受影響

兩種隔離方式

• 執行緒池隔離——每個依賴一個獨立執行緒池。隔離最徹底（連逾時都能強制中斷），但有執行緒切換的成本，而且執行緒總數會變多。
• 信號量隔離（Semaphore）——只用計數器限制「同時進行的數量」，不換執行緒。成本極低，但無法強制中斷已經在跑的呼叫——所以它更依賴超時設定。

降級：失敗時回傳什麼

@CircuitBreaker(name = "memberService", fallbackMethod = "getMemberFallback")
public Member getMember(Long id) {
    return memberClient.getById(id);
}

// 熔斷開啟或呼叫失敗時走這裡
private Member getMemberFallback(Long id, Throwable t) {
    log.warn("會員服務降級, id={}", id, t);
    return Member.guest();          // 回傳一個安全的預設值
}

降級要回傳什麼才對

• ✅ 快取的舊資料——最好的降級，使用者幾乎無感
• ✅ 安全的預設值——例如推薦清單回傳熱門商品、會員等級回傳「一般會員」
• ✅ 明確的「暫時無法使用」——比讓使用者一直轉圈好
• ❌ 回傳 null 然後讓上游 NPE——把一種故障換成另一種
• ❌ 降級邏輯本身又呼叫另一個外部服務——降級路徑必須是最可靠的那條

重試看起來是最無害的防禦——失敗了再試一次而已。實際上它是最容易造成災難的一個。

重試風暴（Retry Storm）

下游服務因為負載過高開始變慢
  → 上游逾時，重試 3 次
  → 下游收到的流量變成 3 倍  ★
  → 更慢、更多逾時
  → 更多重試 → 流量繼續放大
  → 下游徹底崩潰

★ 而這一切發生在「下游本來只是有點吃力」的時候

三個必要條件

① 只重試「可能會成功」的錯誤

• ✅ 連線逾時、503、網路瞬斷 —— 重試有意義
• ❌ 400 參數錯誤、401 未授權、業務規則失敗 —— 重試一萬次也不會成功，純粹浪費

② 指數退避 + 隨機抖動

// ❌ 固定間隔：所有失敗的請求會「同時」重試
retry after 1s, 1s, 1s

// ⚠️ 指數退避：好一些，但同一批請求仍然同步
retry after 1s, 2s, 4s

// ✅ 指數退避 + jitter：把重試時間打散
retry after 1s±0.5s, 2s±1s, 4s±2s

jitter（隨機抖動）是最容易被省略、卻最關鍵的一步。沒有它的話，一萬個同時失敗的請求會在 1 秒後「同時」再打一次——這跟原本的尖峰沒有差別。

③ 操作必須冪等

重試與熔斷要一起設定

熔斷器開啟時不應該再重試——那等於繞過了熔斷。Resilience4j 的裝飾順序（由外到內）是：

Retry → CircuitBreaker → RateLimiter → TimeLimiter → Bulkhead → 實際呼叫

重試在最外層 ＝ 每次重試都會先問過熔斷器
熔斷器 OPEN 時，重試會立刻拿到 CallNotPermittedException 而不是真的去打下游

這一頁講了六種機制。但每一種都有成本——全部套上去的系統，可能比完全不設防更難維護。

成本一：複雜度與除錯難度

一個請求失敗時，你必須先釐清：是被限流擋掉、被熔斷器拒絕、被艙壁排隊逾時、走了降級邏輯，還是真的失敗了？每多一層防禦，就多一種「請求沒有正常完成」的可能。

成本二：錯誤的參數比沒有設定更糟

• 限流閾值設得太低 → 正常流量被誤殺，而且看起來像是服務故障
• minimumNumberOfCalls 太小 → 剛啟動就跳閘，服務永遠起不來
• 降級邏輯有 bug → 平常不會執行，出事時才第一次跑，然後跟著一起爆

成本三：掩蓋真正的問題

熔斷器讓系統「不會掛掉」，但也讓「下游一直很慢」這件事變得不痛不癢。防禦機制應該搭配告警——熔斷器跳閘、限流被觸發、降級被執行，這些都該送出通知，而不是靜靜地讓系統帶病運行。

建議的導入順序

1. 先設超時——所有外部呼叫，一個都不能漏。投報率最高的一步。
2. 再加監控——沒有數據就沒辦法設定後面任何一個閾值
3. 對真的會被打爆的入口加限流——不是每個 API 都需要
4. 對真的不穩定的依賴加熔斷——不是每個呼叫都需要
5. 只在有實際隔離需求時才用艙壁——它的成本最高

一句話收尾

這一頁所有的機制，都在回答同一個問題：當依賴的東西不可靠時，我要怎麼「有限度地失敗」，而不是「無限度地一起死」。