下游掛了還一直打它，只會把自己的執行緒、連線、重試風暴一起拖下水。熔斷器像電閘：偵測到連續失敗就「跳閘」，讓請求快速失敗（fail fast），給下游喘息空間，再小心試探是否復原。
🧠 Intuition
TIP
三個狀態：Closed（正常放行、計失敗）→ 失敗率超門檻 → Open（直接拒絕、不打下游）→ 冷卻時間到 → Half-Open（放幾個試探請求）→ 成功則回 Closed，失敗則退回 Open。
- 解決的核心問題：避免級聯故障（cascading failure）。一個慢的依賴會耗光呼叫端資源，把局部故障放大成全站故障。
- Open 狀態下「快速失敗」反而是保護：與其讓請求堆積等 timeout，不如立刻回退（fallback / 預設值 / 錯誤）。
- 常與 timeout、重試+退避、bulkhead（隔艙） 搭配；熔斷管「整體別再打了」，退避管「單次別打太密」。
⚖️ Tradeoffs
只靠 timeout + 重試 — 沒有熔斷
- 下游真的掛掉時，每個請求都得等滿 timeout 才失敗 → 執行緒/連線被占滿。
- 重試會加重下游負載，把它推得更深（重試風暴 retry storm）。
- 適合：偶發、短暫的抖動；不適合下游持續性故障。
熔斷器 + 退避 + fallback — 標準組合
- Open 時立即回退，資源不被卡死；Half-Open 受控試探，避免「驚群」一次打爆剛恢復的下游。
- 關鍵參數：失敗門檻、滑動視窗、Open 冷卻時間、Half-Open 試探數——要依下游恢復特性調，太敏感會誤跳、太遲鈍救不及。
- 代價：多一層狀態與設定；fallback 的「降級體驗」要產品端一起定義（給快取舊值？給空結果？）。
🔑 Takeaways
- 熔斷器靠 Closed → Open → Half-Open 三態，把「持續失敗的依賴」隔離掉，防止級聯故障。
- Open 時快速失敗是特性不是 bug——保護自己的資源比硬等 timeout 更可靠。
- 與 timeout / 退避 / bulkhead / fallback 一起用；參數要對著下游的恢復行為調，並先想好降級體驗。
2026-07-01
- Q：熔斷器和限流器（rate limiter）到底差在哪？感覺都是「擋請求」。
- A：方向相反。限流保護被呼叫端——「我每秒只收這麼多，多的拒絕」，由服務端決定。熔斷保護呼叫端自己——「下游一直失敗，我先別打了，免得拖垮自己」，由客戶端依下游健康狀態決定。一個是入口的配額閘門，一個是出口的自我保護開關；常常一起用。