在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。
集群策略有：Random LoadBalance，RoundRobin LoadBalance，LeastActive LoadBalance，hConsistentHash LoadBalance四种。
Random LoadBalance
这是dubbo默认的负载均衡策略，具体看官方文档介绍：
* 随机，按权重设置随机概率。
* 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重
来看看源码：
public class RandomLoadBalance extends AbstractLoadBalance {
public static final String NAME = "random";
private final Random random = new Random();
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size(); // 总个数
int totalWeight = 0; // 总权重
boolean sameWeight = true; // 权重是否都一样
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
totalWeight += weight; // 累计总权重
if (sameWeight && i > 0
&& weight != getWeight(invokers.get(i - 1), invocation)) {
sameWeight = false; // 计算所有权重是否一样
}
}
if (totalWeight > 0 && ! sameWeight) {
// 如果权重不相同且权重大于0则按总权重数随机
int offset = random.nextInt(totalWeight);
// 并确定随机值落在哪个片断上
for (int i = 0; i < length; i++) {
offset -= getWeight(invokers.get(i), invocation);
if (offset < 0) {
return invokers.get(i);
}
}
}
// 如果权重相同或权重为0则均等随机
return invokers.get(random.nextInt(length));
}
}
具体来分析一下：随机，这里是通过权重来实现的。
dubbo负载均衡之随机.png
我们假设有5台服务器，分别是A,B,C,D,E，权重分别是10,15,25,20,30，那么我们来具体分析下：
- 第一步，计算总权重与判断所有权重是否相等：
总权重是100，sameWeight= fale. - 第二步：判断总权重是否相等，不相等，则继续。
- 第三步：按照总权重来计算随机数，并确定这个随机数落在哪个权重范围内。
按权重计算的随机数： int offset = random.nextInt(totalWeight); 假设这里随机权重是35
循环A,B,C,D,E五台机器，看这个随机数落在哪个权重返回区间。
先判断机器A：35-10=25，判断25>0，继续下一台机器B：25-15=10，判断10>0,继续下一台机器C：10-25=-15，判断-15<0,如此，返回机器C作为随机算法选中的负载均衡后的invoker.
RoundRobinLoadBalance
根据官方文档介绍：
* 轮循，按公约后的权重设置轮循比率。
* 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
看看源代码：
public class RoundRobinLoadBalance extends AbstractLoadBalance {
public static final String NAME = "roundrobin";
private final ConcurrentMap<String, AtomicPositiveInteger> sequences = new ConcurrentHashMap<String, AtomicPositiveInteger>();
private final ConcurrentMap<String, AtomicPositiveInteger> weightSequences = new ConcurrentHashMap<String, AtomicPositiveInteger>();
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
int length = invokers.size(); // 总个数
int maxWeight = 0; // 最大权重
int minWeight = Integer.MAX_VALUE; // 最小权重
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
maxWeight = Math.max(maxWeight, weight); // 累计最大权重
minWeight = Math.min(minWeight, weight); // 累计最小权重
}
if (maxWeight > 0 && minWeight < maxWeight) { // 权重不一样
AtomicPositiveInteger weightSequence = weightSequences.get(key);
if (weightSequence == null) {
weightSequences.putIfAbsent(key, new AtomicPositiveInteger());
weightSequence = weightSequences.get(key);
}
int currentWeight = weightSequence.getAndIncrement() % maxWeight;
List<Invoker<T>> weightInvokers = new ArrayList<Invoker<T>>();
for (Invoker<T> invoker : invokers) { // 筛选权重大于当前权重基数的Invoker
if (getWeight(invoker, invocation) > currentWeight) {
weightInvokers.add(invoker);
}
}
int weightLength = weightInvokers.size();
if (weightLength == 1) {
return weightInvokers.get(0);
} else if (weightLength > 1) {
invokers = weightInvokers;
length = invokers.size();
}
}
AtomicPositiveInteger sequence = sequences.get(key);
if (sequence == null) {
sequences.putIfAbsent(key, new AtomicPositiveInteger());
sequence = sequences.get(key);
}
// 取模轮循
return invokers.get(sequence.getAndIncrement() % length);
}
}
具体来分析一下：
dubbo负载均衡值轮询策略.png
我们假设有4台服务器，分别是A,B,C,D,权重分别是10,20,30,10，那么我们来具体分析下：
第一步：最大权重为30，最小权重为10.
第二步：当前权重为0，筛选出大于当前权重的服务器：现在有服务器A,B,C,D满足
第三步：筛选后有4个服务器，需要继续复制新的invoker和length。
第四步：新的invokers中，继续取模作为下标，此时：sequence.getAndIncrement()为0 ，和length取模之后为0，则应该是服务器A选中了。
如果我们再有一个请求
第一步：最大权重为30，最小权重为10.
第二步：当前权重为1，筛选出大于当前权重的服务器：现在新的服务器列表是A,B,C,D
第三步：筛选后有4个服务器，需要继续复制新的invoker和length。
第四步：新的invokers中，继续取模作为下标，此时：sequence.getAndIncrement()为1 ，和length取模之后为1，则应该是服务器B选中了。
LeastActiveLoadBalance
根据官方文档介绍：
* 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
* 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
首先我们要理解一下，这个活跃数是什么？这个活跃数官方说的是调用前后计数差，这个是每个服务里面有一个类似活跃数计数器的东西，如果该服务器被调用一次，则这个活跃计数器+1，等到调用完毕这个活跃计数器-1.比如服务器A,B，现在A调用一次，活跃计数器为1，B调用一次，但是现在已经调用完毕了，活跃计数器就是0.接下来我们看看源码：
public class LeastActiveLoadBalance extends AbstractLoadBalance {
public static final String NAME = "leastactive";
private final Random random = new Random();
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size(); // 总个数
int leastActive = -1; // 最小的活跃数
int leastCount = 0; // 相同最小活跃数的个数
int[] leastIndexs = new int[length]; // 相同最小活跃数的下标
int totalWeight = 0; // 总权重
int firstWeight = 0; // 第一个权重，用于于计算是否相同
boolean sameWeight = true; // 是否所有权重相同
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive(); // 活跃数
int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.WEIGHT_KEY, Constants.DEFAULT_WEIGHT); // 权重
if (leastActive == -1 || active < leastActive) { // 发现更小的活跃数，重新开始
leastActive = active; // 记录最小活跃数
leastCount = 1; // 重新统计相同最小活跃数的个数
leastIndexs[0] = i; // 重新记录最小活跃数下标
totalWeight = weight; // 重新累计总权重
firstWeight = weight; // 记录第一个权重
sameWeight = true; // 还原权重相同标识
} else if (active == leastActive) { // 累计相同最小的活跃数
leastIndexs[leastCount ++] = i; // 累计相同最小活跃数下标
totalWeight += weight; // 累计总权重
// 判断所有权重是否一样
if (sameWeight && i > 0
&& weight != firstWeight) {
sameWeight = false;
}
}
}
// assert(leastCount > 0)
if (leastCount == 1) {
// 如果只有一个最小则直接返回
return invokers.get(leastIndexs[0]);
}
if (! sameWeight && totalWeight > 0) {
// 如果权重不相同且权重大于0则按总权重数随机
int offsetWeight = random.nextInt(totalWeight);
// 并确定随机值落在哪个片断上
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexs[i];
offsetWeight -= getWeight(invokers.get(leastIndex), invocation);
if (offsetWeight <= 0)
return invokers.get(leastIndex);
}
}
// 如果权重相同或权重为0则均等随机
return invokers.get(leastIndexs[random.nextInt(leastCount)]);
}
}
具体来分析一下：
dubbo负载均衡值最小活跃数.png
我们假设有4台服务器，分别是A,B,C,D,权重分别是10,20,30,10，活跃数分别为1,2,1,5那么我们来具体分析下：
第一步：获取相同最小活跃数组的下标为0,2。因为这里只有A,C两台机器的活跃数最小为1。
第二步：A,C两台服务器的权重并不相等，因此需要按照总权重随机。
第三步：按照总权重随机，总权重为70，如果按照总权重随机值是10，那么遍历新的相同最小活跃数数组，对于服务器A，10-10=0，现在0<=0则，被选中的是服务器A。
这里思路就是：遍历invokers获得最小相同活跃数的数组，然后根据这个数组里面的服务器的权重来随机选择。
ConsistentHash LoadBalance
一致性hash负载均衡策略，看看官方文档的介绍：
* 一致性 Hash，相同参数的请求总是发到同一提供者。
* 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
* 算法参见：[http://en.wikipedia.org/wiki/Consistent_hashing](http://en.wikipedia.org/wiki/Consistent_hashing)
* 缺省只对第一个参数 Hash，如果要修改，请配置 `<dubbo:parameter key="hash.arguments" value="0,1" />`
* 缺省用 160 份虚拟节点，如果要修改，请配置 `<dubbo:parameter key="hash.nodes" value="320" />`
先简单介绍下原理：
我们假设有4台服务器，分别是A,B,C,D,权重分别是10,20,30,10，根据某种算法（hash算法）使得这4太机器能够像数字0,3,6,9均匀分布在这个圆环上，如下图所示：
图片.png
如果我们需要请求服务，将服务第一个参数（dubbo默认只对第一个参数 ）进行hash算法，得到一个hash值，比如5,然后我们沿着顺时针走，请求经过hash之后遇到的第一个结点就是被选择的结点，这里顺时针遇到6，所以应该选择返回C服务器。如下图所示：
图片.png
但是我们知道hash算法不可避免的会遇到碰撞，如果我们的服务器A,B,C,D通过hash算法之后的对应结点为：0,1,2,3。这样映射之后的结点分布不均匀，所以需要引入虚拟结点。这里有4个真实结点（A,B,C,D）这里我们映射了结点（A,A1，A2）,（B,B1，B2）,（C,C1，C2）,（D,D1，D2）,然后我们把这些点散落在圆环上。如图所示：
图片.png
键入这里服务器Adown掉了，也就是A,A1，A2在圆环上消失了，此时A,A1，A2的压力分别转给了B1，D1，D而且分布也是相对均匀的。
图片.png
配置
服务端服务级别
<dubbo:service interface="..." loadbalance="roundrobin" />
客户端服务级别
<dubbo:reference interface="..." loadbalance="roundrobin" />
服务端方法级别
<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
客户端方法级别
<dubbo:reference interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>
网友评论