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

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
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值