架構之旅1 - 扣減庫存

架構之旅2 - 熔斷機制

專案中要做一個熔斷機制，預防對第三方的介面呼叫壓力太大。下面我介紹下專案中用到的熔斷機制。

一、熔斷機制  

1.熔斷檢測機制

（1）請求call到backend後，首先判斷熔斷開關是否開啟

（2）如果熔斷開關已開啟，則表明當前請求不能被處理

（3）如果熔斷開關未開啟，則判斷時間視窗（判斷統計錯誤率）是否已滿

（4）如果時間視窗（判斷統計錯誤率）未滿，則請求桶（redis) 中的請求數加1

（5）如果返回的response 有異常，則失敗桶（redis) 的失敗數加1，如果返回的response沒有異常，則成功桶（redis) 的成功數加1

（6）如果時間視窗（判斷統計錯誤率）已滿，則開始判斷是否需要熔斷

 2.熔斷演算法

充要條件：

（1）請求總數 > 設定值X

（2）失敗率 > 設定值Y

請求總數可以從請求桶redis 中獲取到

失敗率 = 失敗數 ÷ 請求數 × 100%

當請求總數大於一定值，且失敗率大於一定值時，則表示請求失敗數太多了，需要熔斷API請求

3.統計失敗率的時間視窗

 （1）每次請求，都會判斷時間視窗是否已滿（如5分鐘），如果時間視窗已滿，則重新開始計時，且清理請求數/成功數/失敗數

 （2）第一次開始的起始時間預設為當前時間。

4.熔斷持續時間

（1）如果出現問題，可以將所有請求鏈路熔斷掉，熔斷恢復時間可以假定為1分鐘，可以根據不同的環境進行調整

（2）熔斷恢復時間沒有根據環境來進行動態調整，比如網路差的時候，持續了很長時間網路都很差，這個時候，可以動態遞增熔斷時間

5.手動熔斷

因為熔斷是通過統計單位時間內的失敗率來判斷是否需要熔斷的，而有時候我們需要快速切斷請求鏈路，比如充值請求量太大的時候，導致很多訂單都被退款，這個時候我們可以先熔斷獲取套餐介面，這樣使用者就拿不到套餐，就不能充值了。

6.總熔斷檢測開關

有時候我們不需要熔斷檢測，這個時候我們就需要一個總開關，開啟總開關，則進行熔斷檢測，關閉總開關，則不進行熔斷檢測。

7.檢視當前熔斷的狀態

我們做了熔斷檢測，但是需要check下是否work了，可以check下以下引數

8.還有哪些可以優化的？有哪些不足？以及您是否遇到熔斷的坑？

作　　者： Jackson0714
出　　處：http://www.cnblogs.com/jackson0714/
關於作者：專注於微軟平臺的專案開發。如有問題或建議，請多多賜教！
版權宣告：本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。
特此宣告：所有評論和私信都會在第一時間回覆。也歡迎園子的大大們指正錯誤，共同進步。或者直接私信我
聲援博主：如果您覺得文章對您有幫助，可以點選文章右下角【推薦】一下。您的鼓勵是作者堅持原創和持續寫作的最大動力！