Dubbo的负载均衡

一、部署多个服务端，构成集群，如下图所示：

二、在负载均衡菜单中，动态调整，如下图：

注意：动态调整可以是方法级粒度的。

三、负载均衡策略说明

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负载均衡这部分源码感兴趣的，可以查看源码，源码位置如下：