dubbo的负载均衡机制

在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。

dubbo的负载均衡机制_第1张图片

以上是dubbo提供的四种负载均衡机制:

Random LoadBalance

随机,按权重设置随机概率。

在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

dubbo的负载均衡机制_第2张图片

比如:上图中userService有三台服务提供者,权重分别为100、200、50,按照基于权重的随机负载均衡机制,请求这三个服务的概率分别为2/7,4/7和1/7,我们可以测试下:

首先我们启动三个服务提供者UserService,端口分别为20880和20881、20882:

    #dubbo协议使用的端口
    dubbo.protocol.port=20880

    #dubbo协议使用的端口
    dubbo.protocol.port=20881

    #dubbo协议使用的端口
    dubbo.protocol.port=20882

并打印日志:

   

        @Override
        public List getALlUsers(){
            logger.debug("getALlUsers in...1");
            List users = userMapper.getAllUsers();
            return users;
        }

   

        @Override
        public List getALlUsers(){
            logger.debug("getALlUsers in...2");
            List users = userMapper.getAllUsers();
            return users;
        }

   

        @Override
        public List getALlUsers(){
            logger.debug("getALlUsers in...3");
            List users = userMapper.getAllUsers();
            return users;
        }

 

然后启动服务消费者,分别调用四次接口http://localhost:7777/getAllUsers:

第一次:

dubbo的负载均衡机制_第3张图片

第二次:

dubbo的负载均衡机制_第4张图片

第三次:

dubbo的负载均衡机制_第5张图片

第四次:

dubbo的负载均衡机制_第6张图片

通过观察控制台可以发现,这三个服务的权重都是100,是相等的,

dubbo的负载均衡机制_第7张图片

 

但是在随机策略下,以上的四次访问确实是没有规律的,其中第一个服务就被访问了2次,之后第三个服务才被访问到

RoundRobin LoadBalance

轮循,按公约后的权重设置轮循比率。

存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

测试:

我们将消费者引用的远程服务负载均衡策略改为轮询,此时我们仍然保证三个服务的权重相等。

   

 @Reference(loadbalance="roundrobin")
 private UserService userService;

然后重启消费者,分别调用四次接口:

第一次:

getALlUsers in...1

第二次:

getALlUsers in...2

第三次:

getALlUsers in...3

第四次:

    getALlUsers in...1
    getALlUsers in...1

可以看到在权重相等的情况下,使用轮询策略,消费者会依次访问三个服务。

然后我们将策略依然改成random:

    @Reference(loadbalance="random")
    private UserService userService;

然后我们可以在服务提供者的服务上添加权重的注解:

dubbo的负载均衡机制_第8张图片

不过这样就写死了,我们平时最多的是动态的调整服务的权重,不采用图中配置,所以我们可以在控制台来动态配置:

dubbo的负载均衡机制_第9张图片

最终调整的结果:

再次访问多次接口,我们可以发现随机策略下,权重大的会被访问到很多次,而权重小的则调用的少:

还有两种是:

LeastActive LoadBalance

官方解释:最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差,使慢的机器收到更少。

例如,每个服务维护一个活跃数计数器。当A机器开始处理请求,该计数器加1,此时A还未处理完成。若处理完毕则计数器减1。而B机器接受到请求后很快处理完毕。那么A,B的活跃数分别是1,0。当又产生了一个新的请求,则选择B机器去执行(B活跃数最小),这样使慢的机器A收到少的请求。

 

ConsistentHash LoadBalance

一致性 Hash,相同参数的请求总是发到同一提供者。

当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。算法参见:http://en.wikipedia.org/wiki/Consistent_hashing

缺省只对第一个参数 Hash,如果要修改,请配置

缺省用 160 份虚拟节点,如果要修改,请配置
————————————————
版权声明:本文为CSDN博主「Jeff.Sheng」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/shengqianfeng/article/details/82314269

你可能感兴趣的:(分布式中间件)