架構必經之路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.還有哪些可以優化的?有哪些不足?以及您是否遇到熔斷的坑?
歡迎留言一起探討熔斷機制~
作 者:
出 處:http://www.cnblogs.com/jackson0714/
關於作者:專注於微軟平臺的專案開發。如有問題或建議,請多多賜教!
版權宣告:本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連結。
特此宣告:所有評論和私信都會在第一時間回覆。也歡迎園子的大大們指正錯誤,共同進步。或者直接私信我
聲援博主:如果您覺得文章對您有幫助,可以點選文章右下角【推薦】一下。您的鼓勵是作者堅持原創和持續寫作的最大動力!