關鍵詞總結：熔斷設計、熔斷設計的重點
熔斷設計
分佈式系統設計中，重試時如果錯誤太多，或是在短時間內得不到修復，應該開啓熔斷操作，尤其是後端太忙的時候，使用熔斷設計可以保護後端不會過載。
熔斷器模式：1、可以防止應用程序不斷地嘗試執行可能會失敗的操作，或者浪費 CPU 時間去等待長時間的超時產生。2、使應用程序能夠診斷錯誤是否已經修正。如果已經修正，應用程序會再次嘗試調用操作。
熔斷器可以使用狀態機來實現，內部模擬以下幾種狀態。
閉合（Closed）狀態
失敗的計數器 -> 調用失敗，失敗次數+1 -> 最近失敗次數超過了允許失敗的閾值 -> 切換到斷開 (Open) 狀態 -> 開啓一個超時時鐘 -> 時鐘超過了該時間 -> 切換到半斷開（Half-Open）狀態。
超時時鐘：給了系統一次機會來修正導致調用失敗的錯誤
Closed 狀態下：錯誤計數器（基於時間或者連續失敗的次數） 在特定的時間間隔或者次數內會自動重置。防止由於某次的偶然錯誤導致熔斷器進入斷開狀態
斷開 (Open) 狀態
在該狀態下，立即對請求返回錯誤響應，而不調用後端的服務。有時也可以cache上次成功請求，直接返回緩存（不能影響業務）
半開（Half-Open）狀態
允許應用程序一定數量的請求去調用服務。能夠有效防止正在恢復中的服務被突然而來的大量請求再次拖垮。
如果請求成功，那麼可以認爲之前導致調用失敗的錯誤已經修正，熔斷器切換到閉合狀態，同時將錯誤計數器重置。
如果這一定數量的請求有調用失敗，認爲導致之前調用失敗的問題仍然存在，熔斷器切回到斷開狀態，重置計時器來給系統一定的時間來修正錯誤。
熔斷設計的重點
實現熔斷器模式的時候，需要考慮這些因素
- 錯誤的類型
根據錯誤類型，來估計被調用方大概需要花費的恢復時長，進而作出合理的決定，是進入重試環節，還是直接做熔斷操作。 - 日誌監控
記錄所有失敗請求和一些可能成功的請求。使得管理員能夠監控熔斷器執行情況 - 測試服務是否可用
在斷開狀態下，熔斷器可以採用定期地 ping 一下遠程服務的健康檢查接口，來判斷服務是否恢復，而不是使用計時器來自動切換到半開狀態。並且在服務恢復的情況下，不需要真實的用戶流量請求把狀態從半開狀態切回關閉狀態。 - 手動重置
提供可以手動將熔斷器狀態切換至閉合或斷開的功能。 - 併發問題
相同的熔斷器有可能被大量併發請求同時訪問。使用無鎖或原子性的方式來實現熔斷器，以確保其本身不會產生阻塞的問題。 - 資源分區
熔斷器只對有問題的分區進行斷開操作，確保其他分區還是可用的。 - 記錄重試錯誤的請求
有時候，錯誤和請求的數據和參數有關係，所以，記錄下出錯的請求，這需要被調用端支持冪等調用。
參考資料：
左耳聽風（極客時間）鏈接：
http://gk.link/a/10f5D
GitHub鏈接：
https://github.com/lichangke/LeetCode
CSDN首頁：
https://me.csdn.net/leacock1991
歡迎大家來一起交流學習