微服务架构Dubbo之负载均衡策略

原创
2020/03/27 18:01
阅读数 358

1. Dubbo负载均衡策略

1.1 Dubbo的默认策略:随机访问

在这里插入图片描述

1.2 随机策略 --- RandomLoadBalance

  • 随机,按权重设置随机概率,在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。
    @Reference(timeout=3000,check=false,loadbalance = "random")
    private UserService userService;//第三方的接口
所有策略皆是测试7次,测试comsumer调用provider/provider2的次数

测试源码来源于 -->> Dubbo之原理讲解及利用zookeeper作为注册中心进行高可用测试

在这里插入图片描述

在这里插入图片描述

1.3 轮询策略 --- RoundRobinLoadBalance

  • 轮询,按公约后的权重设置轮询比率,存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂(牺牲),当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。
@Reference(timeout=3000,check=false,loadbalance = "roundrobin")
private UserService userService;//第三方的接口

在这里插入图片描述

在这里插入图片描述

1.4 Iphash策略 --- ConsistentHashLoadBalance

  • 一致性Hash,相同参数的请求总是发到同一提供者,当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。想对一致性hsah有更深的了解请点击---Redis的分片机制包含一致性hash
   /**
     * check:是否校验提供者
     * loadbalance="负载均衡的配置"
     */
    @Reference(timeout=3000,check=false,loadbalance ="consistenthash")
    private UserService userService;//第三方的接口

在这里插入图片描述

1.5 最小活跃数 --- LeastActiveLoadBalance

挑选连接数较小的访问。
  • 最小活跃调用数,相同活跃数的随机,活跃数指调用前后计数差,使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。
    @Reference(timeout=3000,check=false,loadbalance ="leastactive")
    private UserService userService;//第三方的接口

在这里插入图片描述

在这里插入图片描述

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部