4.Dubbo2.5.3集群容錯和負載均衡


轉載請出自出處:http://www.cnblogs.com/hd3013779515/

1.集群容錯和負載均衡原理

各節點關系:

  • 這里的Invoker是Provider的一個可調用Service的抽象,Invoker封裝了Provider地址及Service接口信息。
  • Directory代表多個Invoker,可以把它看成List<Invoker>,但與List不同的是,它的值可能是動態變化的,比如注冊中心推送變更。
  • Cluster將Directory中的多個Invoker偽裝成一個Invoker,對上層透明,偽裝過程包含了容錯邏輯,調用失敗后,重試另一個。
  • Router負責從多個Invoker中按路由規則選出子集,比如讀寫分離,應用隔離等。
  • LoadBalance負責從多個Invoker中選出具體的一個用於本次調用,選的過程包含了負載均衡算法,調用失敗后,需要重選。

2.負載均衡

(1)配置說明


在集群負載均衡時,Dubbo提供了多種均衡策略,缺省為random隨機調用。

Random LoadBalance
  • 隨機,按權重設置隨機概率。
  • 在一個截面上碰撞的概率高,但調用量越大分布越均勻,而且按概率使用權重后也比較均勻,有利於動態調整提供者權重。
RoundRobin LoadBalance
  • 輪循,按公約后的權重設置輪循比率。
  • 存在慢的提供者累積請求問題,比如:第二台機器很慢,但沒掛,當請求調到第二台時就卡在那,久而久之,所有請求都卡在調到第二台上。
LeastActive LoadBalance
  • 最少活躍調用數,相同活躍數的隨機,活躍數指調用前后計數差。
  • 使慢的提供者收到更少請求,因為越慢的提供者的調用前后計數差會越大。
ConsistentHash LoadBalance
  • 一致性Hash,相同參數的請求總是發到同一提供者。
  • 當某一台提供者掛時,原本發往該提供者的請求,基於虛擬節點,平攤到其它提供者,不會引起劇烈變動。
  • 算法參見:http://en.wikipedia.org/wiki/Consistent_hashing
  • 缺省只對第一個參數Hash,如果要修改,請配置<dubbo:parameter key="hash.arguments" value="0,1" />
  • 缺省用160份虛擬節點,如果要修改,請配置<dubbo:parameter key="hash.nodes" value="320" />

配置如:

<dubbo:service interface="..." loadbalance="roundrobin" />

或:

<dubbo:reference interface="..." loadbalance="roundrobin" />

或:

<dubbo:service interface="...">
     <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

或:

<dubbo:reference interface="...">
      <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

 

(2)使用案例

3.Dubbo2.5.3快速啟動Hello World的基礎上增加服務提供者,與dubbo-hello-provider的區別如下。

image

image

服務消費者HelloServiceConsumerTest.java中加上循環調用服務提供者。

package cn.ljh.dubbo.service;

import java.io.IOException;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class HelloServiceConsumerTest {
    public static void main(String[] args) {  
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(  
                new String[] { "applicationConsumer.xml" });  
          
        context.start();  
        for(int i = 0 ; i < 100 ; i++){
            HelloService providerService = (HelloService) context.getBean("helloService");  
            System.out.println(providerService.sayHello("Tom"));  
        }
        
        try {  
            System.in.read();//讓此程序一直跑
        } catch (IOException e) {         
            e.printStackTrace();  
        }    
    }  
}

1)缺省Random LoadBalance的時候

開始時,HelloService的兩個提供者的權重都是100,服務消費者執行后的分配比例為54:46。

然后通過監控中心把20880這個提供者的權重加到400,這時服務消費者執行后的分配比例為83:17。

image

2)設置為RoundRobin LoadBalance的時候

image

HelloService的兩個提供者的權重都是100時,嚴格安裝輪循方式。

image

把20880這個提供者的權重加到400時,按照權重來輪循。

image

3.集群容錯

(1)配置說明

集群容錯模式:
Failover Cluster
  • 失敗自動切換,當出現失敗,重試其它服務器。(缺省)
  • 通常用於讀操作,但重試會帶來更長延遲。
  • 可通過retries="2"來設置重試次數(不含第一次)。
Failfast Cluster
  • 快速失敗,只發起一次調用,失敗立即報錯。
  • 通常用於非冪等性的寫操作,比如新增記錄。
Failsafe Cluster
  • 失敗安全,出現異常時,直接忽略。
  • 通常用於寫入審計日志等操作。
Failback Cluster
  • 失敗自動恢復,后台記錄失敗請求,定時重發。
  • 通常用於消息通知操作。
Forking Cluster
  • 並行調用多個服務器,只要一個成功即返回。
  • 通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。
  • 可通過forks="2"來設置最大並行數。
Broadcast Cluster
  • 廣播調用所有提供者,逐個調用,任意一台報錯則報錯。(2.1.0開始支持)
  • 通常用於通知所有提供者更新緩存或日志等本地資源信息。

重試次數配置如:(failover集群模式生效)

<dubbo:service retries="2" />

或:

<dubbo:reference retries="2" />

或:

<dubbo:reference>

    <dubbo:method name="findFoo" retries="2" />

</dubbo:reference>

集群模式配置如:

<dubbo:service cluster="failsafe" />

或:

<dubbo:reference cluster="failsafe" />

(2)使用案例

代碼改造

兩個服務提供者同時改造

HelloServiceImpl.java

增加sleep時間以方便在服務消費者調用時能停掉服務提供者。

image

applicationProvider.xml

image

1)缺省Failover Cluster的時候

在服務消費者執行過程中,通過監控中心禁用某個服務提供者,執行結果顯示能夠正確切換到可用服務提供者,不會報錯或者丟失調用。

2)設置為Failfast Cluster的時候

當服務消費者調用某個服務提供者時,如果停掉該服務提供者,將立即報錯並不繼續執行。

image

3)設置為Failsafe Cluster的時候

當服務消費者調用某個服務提供者時,如果停掉該服務提供者,直接忽略,繼續往下走。

image

參考

http://dubbo.io/User+Guide-zh.htm


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM