一、部署多个服务端,构成集群,如下图所示:
二、在负载均衡菜单中,动态调整,如下图:
注意:动态调整可以是方法级粒度的。
三、负载均衡策略说明
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" />
这种策略会产生一个问题,也是我们生产上出现的一个问题,有一台机器由于调用超时,导致线程全部都夯死了,但是机器还没有挂,通过一致性哈希的负载均衡的时候,结果导致相同参数的请求,也不断的发送到这台机器上,最终导致线程池队列里面积的报文越来越多,最后只有重启服务了。
注意:线程池队列大小,当线程池满时,排队等待执行的队列大小,建议不要设置,当线程程池满时应立即失败,重试其它服务提供机器,而不是排队,除非有特殊需求。
如果想看到上面的这些日志,需要在xml配置文件中加如下配置:
<!-- 配置访问日志 -->
<dubbo:protocol accesslog="true" />
五,源码说明
如果对Dubbo负载均衡这部分源码感兴趣的,可以查看源码,源码位置如下: