常見容錯設計方案

05-22

常見容錯設計方案

來自專欄支付平台

支付系統必須要保證系統健壯性，系統設計需要考慮容錯，不要因為網路故障或系統異常導致金額錯誤甚至整個系統不可用，常見的容錯方案有如下幾點：

設置超時時間

所有的介面調用必須設置超時時間，不設置超時時間請求有可能陷入長期等待，甚至有可能導致整個服務不可用。

重試

所有的介面在異常時，我們可以進行多次重試處理，多次重試都失敗後再報警，當然前提是介面都是冪等的。

限流

限流即流量限制，或者高大上一點，叫做流量整形，限流的目的是在遇到流量高峰期或者流量突增（流量尖刺）時，把流量速率限制在系統所能接受的合理範圍之內，不至於讓系統被高流量擊垮。限流可以保證系統在調用量猛增時的基本可用性，目前有幾種常見的限流方式：

1）通過限制單位時間段內調用量來限流

2）通過限制系統的並發調用程度來限流

3）使用漏桶（Leaky Bucket）演算法來進行限流

4）使用令牌桶（Token Bucket）演算法來進行限流

過載保護

在大型的軟體系統中，如果調用的遠程服務或者資源由於某種原因無法使用時，如果沒有這種過載保護，就會導致請求的資源阻塞在伺服器上等待從而耗盡系統或者伺服器資源。很多時候剛開始可能只是系統出現了局部的、小規模的故障，然而由於種種原因，故障影響的範圍越來越大，最終導致了全局性的後果。熔斷器模式可以防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器模式也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。

艙壁隔離

該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響。hystrix就是採用多線程實現的艙壁隔離，一個線程有問題不影響其他線程，docker是進程級別的隔離，進程資源不會相互影響。

優雅降級

對於核心業務系統，如果系統出現問題，比如並發量突然上來系統扛不住了，我們可以採用一種影響稍微小一些的方案，比如當支付系統並發量大時，我們可以先關閉支付查詢相關入口，保證支付下單主流程不受影響。