版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/u012482647/article/details/78148447

隨著分布式、微服務項目的快速發展，各個服務之間的通訊，難免出現依賴關系，若某一個單元出現故障，就很容易因依賴關系而發生故障的蔓延，為了解決這樣的問題，容錯作為其中一項很重要的技術也廣為人知。

導語

容錯機制廣義的理解，就是包含了很多處理錯誤的機制，如：熔斷機制、降級機制、補償機制、隔斷機制等等。我們針對經常使用的機制進行討論，說明這么多容錯機制設計的思路，熟悉了這些之后，也許你對設計分布式項目會有所裨益。

隔離機制

• 隔離設計思路
  如上圖所示（圖來源于網絡），隔離來自單詞隔板（Bulkheads），隔板作用就是如果某一邊船艙漏水，不會導致整條船裝滿水而導致整條船下沉于水中。
  分布式項目中，我們通過技術實現隔板的作用，做到故障隔離，一般來說，一種是通過合適的業務線拆分項目，進行業務服務種類隔離，另一種是通過用戶群體來區分用戶訪問哪臺服務器，可以是城市劃分（北京的訪問北京服務器）或其他形式。

• 隔離設計重點

• 定義好需要隔離業務的大小和粒度
• 隔離模式需要配置一些高可用、重試、異步、消息中間件等設計的方式配套使用
• 設計過程考慮運維的復雜度，要能駕馭的話，考慮自動化運維等
• 監控系統（重要、重要、重要）

補償機制

• 補償機制的前提
  針對補償機制的出現,本質上是解決ACID和BASE理論而設計的一個機制,關于ACID和BASE理論網上有很多知識,可以說是汗牛充棟.

有了對 ACID 和 BASE 的分析,你就可以發現,BASE理論容許系統處于短暫的不可用和不一致的狀態，那么在設計的時候怎么去保證最終的可用和一致狀態呢？這就需要引入補償機制。

比如: 如果你如打印東西,電子文件拷入u盤,帶到打印店,打印店老板開始打印,但是由于你拷錯了文件,導致我們文件打印就是不可用的,那這也不會阻止我們要打印的文件,因為我們可以借用打印店老板電腦登陸郵箱下載下來,退一步來講,如果郵箱沒有,那我就取消本次打印,回家整理好,之后再來.這也就說明了業務流程必須執行回滾操作.

如果一個事務失敗了或是超時了，我們需要不斷地重試，努力地達到我們想要的結果，然而如果不能達到這個結果, 我們要把整個業務線狀態恢復之前的狀態, 如果有部分業務變化, 我們要把變化的數據更新回原來的狀態.

一個好的補償機制要做以下幾個方面:
1. 要清楚的知道這個機制執行后要達到什么狀態
2. 當補償機制的代碼運作起來,我們可以進行并行或串行
3. 對完成的事務進行修改,可以考慮加一個修改事務

看到這里相信你知道補償機制主要做什么了,補償機制主要做以下兩件事:
1. 努力把一個業務執行完成
2. 如果執行不完成,將會啟動一個補償機制,回滾業務流程

• 補償設計重點
• 因為補償機制是為了努力執行一個業務流程,需要這個流程中所設計的方法或接口支持冪等性,并且在上游有重試機制
• 如果業務流程有問題,一定要幫我們回滾和補償
• 必須明白,業務補償和業務邏輯是強業務關聯的,很難通用
• 針對不同業務考慮不同細節(很多細節上,是根據業務考慮,望大家一定要考慮好再開工)

熔斷機制

• 熔斷器設計思路
  設想一個場景,用戶的請求調用服務A，服務A調用服務B。我們可以把B稱作A的下游服務。服務B前面有負載均衡器。

后端服務可能因為各種原因出問題。例如：數據庫慢查詢，網絡波動，或者內存爭用。在這個情況下，如果服務A超時或者報錯，用戶很可能會重試。在如此混亂的情況下我們可以做什么來保護下游服務呢？

熔斷機制目的是為了解決資源和失敗率提供更多的控制,這個機制最重要的部分是熔斷器能夠快速對下游服務作出一些響應。線程池不會因為慢請求而阻塞，沒有超時，而且也可能會給終端用戶更有意義的返回數據。熔斷器也給了下游服務足夠的時間恢復正常。完全避免報錯是很困難的，但是減少錯誤的影響完全可行。

在熔斷機制中有3種主要的狀態：

關閉(closed)：讓請求通過的默認狀態。如果請求成功/失敗但低于閾值，則狀態保持不變。可能出現的錯誤是超過最大并發數和超時錯誤。

打開(open)：當熔斷器打開的時候，所有的請求都會被標記為失敗；這是故障快速失敗機制，而不需要等待超時時間完成。

半開(half-open)：定期的嘗試發起請求來確認系統是否恢復。如果恢復了，熔斷器將轉為關閉狀態或者保持打開。

• 熔斷器設計重點
• 錯誤的類型 (針對不同的錯誤,開啟不同的容錯機制,有時候需要多個機制配合使用)
• 測試服務是否可用(利用心跳來檢測遠程服務的健康接口)
• 并發問題(針對同一時刻斷路器請求調用的負擔,一般來說會有一個共享數據結構,會導致有鎖情況,我們需要改成無所的數據接口,這樣會更好)
• 手動重制(失敗操作的恢復很難確定,如果斷路器保護的服務長時間不能用,管理員能夠強制改成斷開狀態)
• 資源分區(針對下游數據層,我們可能做多庫多表,我們要對根據那些數據區域進行熔斷,而不是整條業務線)
• 監控系統(日志監控系統,重要的性質不用多強調)

重試機制

• 重試機制的思路
  對上面的熔斷器模型，如果B服務減小它的實例數量，將發生什么？許多A發起的請求可能遇到5XX報錯。這將觸發熔斷器的失敗報警。這就是為什么我們需要重試以避免間歇性網絡抽風。
  所以，我們需要一個重試的機制。但是，我們需要明白的是，“重試”的語義是我們認為這個故障是暫時的，而不是永久的，所以我們會去重試.

• 重試機制設計重點

• 要缺點錯誤類型,再做是否需要重試
• 重試的抖動數要根據業務缺點,不同的業務有不同的考量
• 如果超過指定次數和時間,重試機制就失去了意義

小結

好了,關于容錯機制的多種機制就簡單介紹到這里了,還有很多機制需要大家去通過業務場景進行使用,比如:降級機制、限流機制等等,針對容錯技術上,可以選容錯框架(比如:hystrix,雖然已經不再維護,但足夠業務場景使用)或者是其他的容錯框架.你應該明白了容錯機制的重要性和必要性,之后再探討其他技術切入點.

總結

以上是生活随笔為你收集整理的一文读懂容错机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。