當我們的系統中用到Dubbo的叢集環境,因為各種原因在叢集呼叫失敗時，Dubbo提供了多種容錯方案，預設為failover重試。

       Dubbo的叢集容錯在這裡想說說他是因為我們實際的專案中出現了此類的問題,因為依賴的第三方專案出現異常,導致dubbo呼叫超時,此時使用的是預設的叢集容錯方式,而配置的reties='3',這樣前段系統連續掉用了三次服務,結果可想而知.

先說一下各節點關係：

這裡的Invoker是Provider的一個可呼叫Service的抽象，Invoker封裝了Provider地址及Service介面資訊。

Directory代表多個Invoker，可以把它看成List<Invoker>，但與List不同的是，它的值可能是動態變化的，比如註冊中心推送變更。

Cluster將Directory中的多個Invoker偽裝成一個Invoker，對上層透明，偽裝過程包含了容錯邏輯，呼叫失敗後，重試另一個。

Router負責從多個Invoker中按路由規則選出子集，比如讀寫分離，應用隔離等。

LoadBalance負責從多個Invoker中選出具體的一個用於本次呼叫，選的過程包含了負載均衡演算法，呼叫失敗後，需要重選。

   叢集容錯模式：

   Failover Cluster

失敗自動切換，當出現失敗，重試其它伺服器。(預設)

通常用於讀操作，但重試會帶來更長延遲。

可通過retries="2"來設定重試次數(不含第一次)。正是文章剛開始說的那種情況

  Failfast Cluster

快速失敗，只發起一次呼叫，失敗立即報錯。

通常用於非冪等性的寫操作，比如新增記錄。

  Failsafe Cluster

失敗安全，出現異常時，直接忽略。

通常用於寫入審計日誌等操作。

  Failback Cluster

失敗自動恢復，後臺記錄失敗請求，定時重發。

通常用於訊息通知操作。

  Forking Cluster

並行呼叫多個伺服器，只要一個成功即返回。

通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設定最大並行數。

  Broadcast Cluster

廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯。(2.1.0開始支援)

通常用於通知所有提供者更新快取或日誌等本地資源資訊。

重試次數配置如：(failover叢集模式生效)

<dubbo:serviceretries="2"/>

或：

<dubbo:referenceretries="2"/>

或：

<dubbo:reference>

   <dubbo:methodname="findFoo"retries="2"/>

</dubbo:reference>

叢集模式配置如：

<dubbo:servicecluster="failsafe"/>

或：

<dubbo:referencecluster="failsafe"/>

以上是Dubbo叢集的容錯方式,接下來是在叢集負載均衡時，Dubbo提供了多種均衡策略，預設為random隨機呼叫。

Random LoadBalance

隨機，按權重設定隨機概率。

在一個截面上碰撞的概率高，但呼叫量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance

輪循，按公約後的權重設定輪循比率。

存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

LeastActive LoadBalance

最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。

使慢的提供者收到更少請求，因為越慢的提供者的呼叫前後計數差會越大。

ConsistentHash LoadBalance

一致性Hash，相同引數的請求總是發到同一提供者。

當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

       Dubbo的叢集容錯和負載均衡同樣也是Dubbo本身的高階特性.正如我們在說自定義擴充套件的時候一樣,這兩個特徵同樣也可以進行自定義擴充套件,使用者可以根據自己實際的需求來擴充套件他們從而滿足專案的實際需求.