六、 负载均衡

 

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

 

具体实现上，Dubbo提供的是客户端负载均衡，即由Consumer通过负载均衡算法得出需要将请求提交到哪个Provider实例。

 

可以自行扩展负载均衡策略，参见：负载均衡扩展。

 

1. 负载均衡策略

 

目前Dubbo内置了如下负载均衡算法，用户可直接配置使用：

 

 

1) Random

 

• 加权随机，按权重设置随机概率。

 

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

 

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

 

2) RoundRobin

 

• 加权轮询，按公约后的权重设置轮询比率，循环调用节点。

 

• 缺点：同样存在慢的提供者累积请求的问题。

 

加权轮询过程过程中，如果某节点权重过大，会存在某段时间内调用过于集中的问题。例如ABC三节点有如下权重：{A: 3, B: 2, C: 1}，那么按照最原始的轮询算法，调用过程将变成：A A A B B C。对此，Dubbo借鉴Nginx的平滑加权轮询算法，对此做了优化，调用过程可抽象成下表：

 

 

我们发现经过合计权重（3+2+1）轮次后，循环又回到了起点，整个过程中节点流量是平滑的，且哪怕在很短的时间周期内，概率都是按期望分布的。

 

如果用户有加权轮询的需求，可放心使用该算法。

 

3) LeastActive

 

• 加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数-响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。

 

• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。

 

4) ShortestResponse

 

• 加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。

 

• 使得响应时间越快的提供者，处理更多的请求。

 

• 缺点：可能会造成流量过于集中于高性能节点的问题。

 

这里的响应时间=某个提供者在窗口时间内的平均响应时间，窗口时间默认是30s。

 

5) ConsistentHash

 

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

 

• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

 

• 算法参见：Consistent Hashing | WIKIPEDIA

 

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

• 缺省用160份虚拟节点，如果要修改，请配置

 

2. 配置

 

1) 服务端服务级别

 

 

2) 客户端服务级别

 

 

3) 服务端方法级别

 

 

4) 客户端方法级别