服務器集群容錯是什么

本篇內容主要講解“服務器集群容錯是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“服務器集群容錯是什么”吧!

集群容錯：集群服務調用失敗后，服務框架需要能夠在底層自動容錯，容錯策略很多，分別適用于不同場景。下面將對集群容錯的功能和設計進行詳細說明。

1、集群容錯場景

    在分布式服務框架中，業務消費者不需要了解服務提供者的具體位置，它發起的調用請求也不包含服務提供者的具體地址信息。因此，某個服務提供者是否可用對消費者無關緊要，最終的服務調用成功才是最重要的。

    經過服務路由之后，選定某個服務提供者進行遠程調用，但是服務調用可能出錯，下面對可能的故障場景進行分析。

    1.1、通信鏈路故障

        這里的鏈路指的是消費者和服務提供者之間的鏈路（通常為長連接），可能導致鏈路中斷的原因有
            1）、通信過程中，對方突然宕機導致鏈路中斷。
            2）、通信過程中，對方因為解碼失敗等原因Rest掉連接，導致鏈路中斷。
            3）、通信過程中，消費者write SocketChannel發生IOException導致鏈路中斷。
            4）、通信過程中，消費者read SocketChannel發生IOException異常導致鏈路中斷。
            5）、通信雙方因為檢測心跳超時，主動close SocketChannel導致鏈路中斷。
            6）、通信過程中，網絡出現閃斷故障。
            7）、通信過程中，交換機異常導致鏈路中斷。
            8）、通信過程中，消費者或者服務提供者因為長時間Full GC導致鏈路中斷。
        無論哪種原因導致鏈路中斷，都會導致本次服務調用失敗。

    1.2、服務端超時

        當服務端無法再指定的時間內返回應答給客戶端，就會發生超時，導致超時的原因主要有：
            1）、服務端I/O線程沒有及時從網絡中讀取客戶端請求消息，導致該問題的原因通常是I/O線程被意外阻塞或者執行長周 期操作
            2）、服務端業務處理緩慢，或者長時間阻塞，列如查詢數據庫，由于沒索引導致全表查詢，耗時較長。
            3）、服務端發生長時間Full GC,導致所有業務線程暫停運行，無法及時返回應答給客戶端。

    1.3、服務端調用失敗

        有時會發生服務端調用失敗，導致服務端調用失敗的原因主要有如下幾種：
            1）、服務端解碼失敗，會返回消息解碼失敗異常。
            2）、服務端發生動態流控，返回流控異常。
            3）、服務消息隊列積壓率超過最大閾值，返回系統擁塞異常。
            4）、訪問權限校驗失敗，返回權限相關異常。
            5）、違反SLA(Service-Level Agreement:服務等級協議)策略，返回SLA控制相關異常。
            6）、其他系統異常。
        需要指出的是服務調用異常不包括業務方面的處理異常，例如數據庫異常、用戶記錄不存在異常等。

2、容錯策略

    服務不同，容錯策略也往往不同。下面看看集群容錯和路由策略之間的關系。如圖1-1所示：
     
                                        圖1-1：集群容錯和服務路由的關系

    消費者根據配置的路由策略選擇某個目標地址之后，發起遠程服務調用，在此期間如果發生遠程服務調用異常，則需要框架進行集群容錯，重新進行選路和調用，集群容錯是系統自動執行的，上層用戶并不關心底層的服務調用過程。

    2.1、失敗自動切換（Failover）

        服務調用失敗自動切換策略指的是當發生RPC調用異常時，重新選路，查找下一個可用的服務提供者。

        服務發布的時候，可以指定服務的集群容錯策略。消費者可以覆蓋服務提供者的通用配置，實現個性化的容錯策略。

        Failover策略的設計思路如下：消費者路由操作完成之后，獲得目標地址，調用通信框架的消息發送接口發送請求，監聽服務端應答。如果返回的結果時RPC調用異常（超時、流控、解碼失敗等系統異常），根據消費者集群容錯的策略進行容錯路由，如果是Failover，則重新返回到路由Handler的入口，從路由節點繼續執行。選路完成之后，對目標地址進行對比，防止重新路由到故障服務節點，過濾掉上次的故障服務提供者之后，調用通信框架的消息發送接口發送請求消息。

        分布式服務框架提供Failover容錯策略，但是用戶在使用時需要自己保證用對地方，下面對應用場景進行總結：
            1）、讀操作，因為通常它是冪等的。
            2）、冪等性服務，保證調用1次與N次效果相同。
        需要特別指出的是，失敗重試會增加服務調用時延，因此框架必須對失敗重試的最大數做限制，通常默認為3，防止無限制重試導致服務調用時延不可控。

    2.2、失敗通知（Failback）

        很多業務場景中，消費者需要能夠獲取到服務調用失敗的具體信息，通過對失敗錯誤碼等異常信息的判斷，決定后續的執行策略，例如非冪等性服務調用。

        Failback的設計方案如下：服務框架獲取到服務提供者返回的RPC異常響應之后，根據策略進行容錯。如果是Failback模式，則不再重試其他服務提供者，而是將RPC異常通知給消費者，由消費者捕獲異常進行后續處理。

    2.3、失敗緩存（Failcache）

        Failcache策略是失敗自動恢復的一種，在實際開發中應用場景如下：
            √ 服務狀態路由，必須定點發送到指定的服務提供者。當發生鏈路中斷、流控等服務暫時不可用時，服務框架將消息暫時緩存起來，等待周期T，重新發送，回到服務提供者能夠正常處理該消息。
             √ 對時延要求不敏感的服務。系統服務調用失敗，通常是鏈路暫時不可用、服務流控、GC掛住服務提供者進程等，這種失敗不是永久性的，他的失敗是可預期的。如果消費者調用對時延不敏感，可以考慮使用自動恢復模式。既先緩存、再等待、最后重試。
             √ 通知類服務。對服務調用的實時性不高，可以容忍自動恢復帶來的時延增長。

        為了保證可靠性，Failcache策略在設計的時候需要考慮如下幾個要素：

              √ 緩存時間、緩存對象上限數等需要做出限制，防止內存溢出。
              √ 緩存淘汰算法的選擇，是否支持用戶配置。
              √ 定時重試的周期T，重試的最大次數等需要做出限制并支持用戶指定。

    2.4、快速失敗（Failfast）

        在業務高峰期，對于一些非核心的服務，希望只調用一次，失敗也不再重試，為重要的核心服務節約寶貴的運行資源。此時快速失敗是個不錯的選擇。

        快速失敗策略設計簡單，獲取到服務異常之后，直接忽略異常，記錄異常日志。

    2.5、容錯策略擴展

        無論服務框架支持多少種容錯策略，業務在實際使用過程中一定會有不適應的地方，通過開放容錯策略接口的方式，可以支持用戶自定義擴展容錯策略。

        在集群容錯設計的時候，需要考慮擴展性，主要從以下幾方面進行設計：

            1）、容錯接口的開放。
            2）、屏蔽底層細節，用戶定制簡單。
            3）、配置應當支持擴展，不要讓用戶擴展服務框架Schema。

到此，相信大家對“服務器集群容錯是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！