dubbo集群容错之loadbalance负载均衡

LoadBalance

首先查看 LoadBalance 接口

Invoker select(List> invokers, URL url, Invocation invocation) throws RpcException;

LoadBalance 定义了一个方法就是从 invokers 列表中选取一个

AbstractLoadBalance

AbstractLoadBalance 抽象类是所有负载均衡策略实现类的父类，实现了LoadBalance接口的方法，同时提供抽象方法交由子类实现，

 public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        if (invokers == null || invokers.size() == 0)
            return null;
        if (invokers.size() == 1)
            return invokers.get(0);
        return doSelect(invokers, url, invocation);
    }
 
    protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);

Random LoadBalance

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
算法分析：通过下面这段代码，获取提供者服务的权重，然后计算出总权重，通过总权重计算出offset（根据0~累加的权重值选出的一个随机数），然后再减去每个服务的的权重，如果发现小于0，则调用当前服务。

    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;   //计算所有权重是否一样
            }
        }
            //循环检测，如果offset小于0，则返回该服务                        
        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));
    }

栗子：结合代码

3个服务 A,B,C 其中A的权重为1，B的权重为2，C的权重为3，那么invokers中的服务的顺序有6种情况，分别为ABC,BAC,ACB,CAB,BCA,CBA

此时的 totalWeight=1+2+3=6，此时offset=random.nextInt(totalWeight)=random.nextInt(6)=【0,1,2,3,4,5】中某个随机数

随机碰撞到ABC的情况表
	offset	offset	offset	offset	offset	offset
invokers	0	1	2	3	4	5
ABC	A	B	B	C	C	C
BAC	B	B	A	C	C	C
ACB	A	C	C	C	B	B
CAB	C	C	C	A	B	B
BCA	B	B	C	C	C	A
CBA	C	C	C	B	B

文字描述：

当offset=0的时候，如果invokers=ABC 则调用的是A,因为0-1<0 ; 当offset=4的时候，会经过几个循环

①offset=4-1=3>0,此时offset=3,继续下一步

②offset=3-2=1>0,此时offset=1，继续下一步

③offset=1-3=-2<0,调用此时调用C

RoundRobin LoadBalance

轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
详细步骤：
1）获取轮询key 服务名+方法名

获取可供调用的invokers个数length

设置最大权重的默认值maxWeight=0

设置最小权重的默认值minWeight=Integer.MAX_VALUE

2）遍历所有Inokers，比较出得出maxWeight和minWeight

3）如果权重是不一样的

根据key获取自增序列

自增序列加一与最大权重取模默认得到currentWeigth

遍历所有invokers筛选出大于currentWeight的invokers

设置可供调用的invokers的个数length

4）自增序列加一并与length取模，从invokers获取invoker

public class RoundRobinLoadBalance extends AbstractLoadBalance {
 
    public static final String NAME = "roundrobin";
 
    private final ConcurrentMap<String, AtomicPositiveInteger> sequences = 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(); //①获取轮询key(服务名+方法名)
        int length = invokers.size(); // Number of invokers  ②获取可供调用的invokers个数
        int maxWeight = 0; // The maximum weight 最大权重值  ③设置最大权重的默认值为0
        int minWeight = Integer.MAX_VALUE; // The minimum weight 最小权重支持，默认最大
        final LinkedHashMap<Invoker<T>, IntegerWrapper> invokerToWeightMap = new LinkedHashMap<Invoker<T>, IntegerWrapper>();
		//权重值总数
        int weightSum = 0;
        for (int i = 0; i < length; i++) {//④遍历invokers，比较找出maxWeight和minWeight
			//获取权重值
            int weight = getWeight(invokers.get(i), invocation);
			//获取最大和最小权重值
            maxWeight = Math.max(maxWeight, weight); // Choose the maximum weight
            minWeight = Math.min(minWeight, weight); // Choose the minimum weight
            if (weight > 0) {
                invokerToWeightMap.put(invokers.get(i), new IntegerWrapper(weight));
                weightSum += weight;
            }
        }
            //⑤如果权重不一样
        AtomicPositiveInteger sequence = sequences.get(key);
        if (sequence == null) {
            sequences.putIfAbsent(key, new AtomicPositiveInteger());
            //⑥根据key获取自增序列
            sequence = sequences.get(key);
        }
            
        int currentSequence = sequence.getAndIncrement();
        if (maxWeight > 0 && minWeight < maxWeight) {
			//轮询当前值
            //⑦自增序列加一与最大权重取模默认得到currentWeigth
            int mod = currentSequence % weightSum;
            for (int i = 0; i < maxWeight; i++) {
				//轮询当前值的余数轮询从服务中获取
                for (Map.Entry<Invoker<T>, IntegerWrapper> each : invokerToWeightMap.entrySet()) {
                    final Invoker<T> k = each.getKey();
                    final IntegerWrapper v = each.getValue();
                    if (mod == 0 && v.getValue() > 0) {
                        return k;
                    }
                    if (v.getValue() > 0) {
                        v.decrement();
                        mod--;
                    }
                }
            }
        }
        // Round robin
		//直接轮询找服务
        return invokers.get(currentSequence % length);//自增序列加一并与length取模，从invokers获取invoker
    }
 
    private static final class IntegerWrapper {
        private int value;
 
        public IntegerWrapper(int value) {
            this.value = value;
        }
 
        public int getValue() {
            return value;
        }
 
        public void setValue(int value) {
            this.value = value;
        }
 
        public void decrement() {
            this.value--;
        }
    }
 
}

LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

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; // 最小活跃数调的下标 坐标id
                totalWeight = weight; // 权重
                firstWeight = weight; // 第一个权重
                sameWeight = true; // 重新设置为权重相同
            } else if (active == leastActive) { // 如果活跃数相同，则记录权重
                leastIndexs[leastCount++] = i; // 累计相同最小活跃数下标
                totalWeight += weight; //累计总权重
                // If every invoker has the same weight?
                if (sameWeight && i > 0
                        && weight != firstWeight) {
                    sameWeight = false;
                }
            }
        }
        // assert(leastCount > 0)
        if (leastCount == 1) {
            // If we got exactly one invoker having the least active value, return this invoker directly.
            return invokers.get(leastIndexs[0]);//如果只有一个最小则直接返回
        }
		//如果存在活跃数相关的服务，则随机一个权重值，看看权重值落到哪个服务中则返回某个服务
        if (!sameWeight && totalWeight > 0) {
            // If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on totalWeight.
        //如果权重不相同且权重大于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);
            }
        }
        // If all invokers have the same weight value or totalWeight=0, return evenly.
		//如果权重相同或权重为0则均等随机
        return invokers.get(leastIndexs[random.nextInt(leastCount)]);
    }
}

例子.每个服务有一个活跃计数器,那么我们假如有A,B两个提供者.计数均为0.当A提供者开始处理请求,该计数+1,此时A还没处理完,当处理完后则计数-1.而B请求接收到请求处理得很快.B处理完后A还没处理完,所以此时A,B的计数为1,0.那么当有新的请求来的时候,就会选择B提供者(B的活跃计数比A小)

算法分析：
假设A,B,C,节点的最小活跃数分别是1,1,2权重为1,2,3,则leastIndexs(该数组是最小活跃数组)数组内容为[A,B].A,B的权重是1和2,所以调用A的概率为 1/(1+2) = 1/3,B的概率为 2/(1+2) = 2/3。
其中活跃数的变化是在com.alibaba.dubbo.rpc.filter.ActiveLimitFilter中,如果没有配置dubbo:reference的actives属性,默认是调用前活跃数+1,调用结束-1

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" />
在业务开发中，我们常把数据持久化到数据库中。如果需要读取这些数据，除了直接从数据库中读取外，为了减轻数据库的访问压力以及提高访问速度，我们更多地引入缓存来对数据进行存取。读取数据的过程一般为：

1.这里通过描述图片加入缓存的数据读取过程

对于分布式缓存，不同机器上存储不同对象的数据。为了实现这些缓存机器的负载均衡，可以使用式子1来定位对象缓存的存储机器：

m = hash(图片名称) mod n ——式子1

三台服务器使用哈希对3 求余，那么一定是0,1,2.这样真好跟服务器编号相同，根据对应的图片名称就可找到对应图片缓存的服务器。

存在问题：当服务器数量发生变化时，会引起缓存雪崩，可能引起整体系统压力过大而崩溃；即便不发生上述情况，缓存的位置几乎都会发生改变，因此需要考虑怎么才能尽量减少受影响的缓存呢？

一致性哈希算法：

它也是通过取模的方法，但是不是对服务器的数量进行，而是对2^32取模。还是以咱们得到三台服务器为例，这次hash(服务器的IP地址) % 2^32,计算得到的结果一定是在0~2^32-1之间的某个整数，此时就用这个结果数代表服务器，那么三台服务器可以入如下图表示；

当我们需要缓存照片时，仍然使用图片名称作为key，计算hash(图片名称)%2^32，那么可以用橘色的点表示，但是到底缓存到哪台服务器上呢？A 为什么？因为从图片位置顺时针最先遇到的服务器就是A，因此将被缓存到服务器A上。

一致性哈希算法：

优点：当某台服务器出现down机，那么原来缓存在服务器B上的图片将被缓存至服务器C中，其中只有原来服务器B缓存的照片位置发生改变，其他照片未改动。

缺陷：hash环的偏斜---->我们理想化的吧三台服务器均匀的映射到hash环上，无奈理想很丰满，显示太骨感，想象的和实际情况往往反差很大。

实际上很有可能出现下面右图的情况：1,2,3,4,6图片均被混村到服务器A上了，服务器B上只有5图片，C服务器上压根没有缓存上图片，这就不开心了。如何解决这样的问题呢？一致性哈希算法提出了“虚拟节点”来解决

虚拟节点：

怎么能均匀分布到真hash环上呢，主要咱们只有三个服务器，没有那么多节点可以分布，想到了分身，记得大话西游牛魔王对打孙悟空，都是牛虱和猴子猴孙的PK，既然没有真正多余的物理服务器节点，那么只能讲现有的物理节点通过虚拟的方法复制出来，成为虚拟节点，加入到hash环中。

“虚拟节点”是“实际节点”（物理服务器）在hash环上的复制品，一个实际节点能对应过个虚拟节点。引入的虚拟节点越多，混村的分布月均衡。

配置

服务端服务级别

<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>