美文网首页
dubbo 源码解析 8

dubbo 源码解析 8

作者: 想54256 | 来源:发表于2020-06-09 09:30 被阅读0次

    title: dubbo 源码解析 8
    date: 2020/06/04 10:56


    本节内容

    负载均衡(dubbo 也是客户端负载均衡)

    LoadBalance 中文意思为负载均衡,它的职责是将网络请求,或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大,而另一些服务器比较空闲的情况。

    通过负载均衡,可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时,还可以避免资源浪费,一举两得。负载均衡可分为软件负载均衡和硬件负载均衡。

    在我们日常开发中,一般很难接触到硬件负载均衡。但软件负载均衡还是可以接触到的,比如 Nginx。在 Dubbo 中,也有负载均衡的概念和相应的实现。

    Dubbo 需要对服务消费者的调用请求进行分配,避免少数服务提供者负载过大。服务提供者负载过大,会导致部分请求超时。因此将负载均衡到每个服务提供者上,是非常必要的。

    Dubbo 提供了4种负载均衡实现,分别是

    1. 基于权重随机算法的 RandomLoadBalance
    2. 基于最少活跃调用数算法的 LeastActiveLoadBalance
    3. 基于 hash 一致性的 ConsistentHashLoadBalance
    4. 基于加权轮询算法的 RoundRobinLoadBalance。

    这几个负载均衡算法代码不是很长,但是想看懂也不是很容易,需要大家对这几个算法的原理有一定了解才行。如果不是很了解,也没不用太担心。我们会在分析每个算法的源码之前,对算法原理进行简单的讲解,帮助大家建立初步的印象。

    负载均衡算法

    image

    AbstractLoadBalance

    他是所有负载均衡算法的抽象父类。

    image

    首先会检测 invokers 集合的合法性,然后再检测 invokers 集合元素数量。如果只包含一个 Invoker,直接返回该 Inovker 即可。如果包含多个 Invoker,此时需要通过负载均衡算法选择一个 Invoker,具体的负载均衡算法由子类实现。

    AbstractLoadBalance 除了实现了 LoadBalance 接口方法,还封装了一些公共逻辑,比如服务提供者权重计算逻辑。

    image

    上面是权重的计算过程,该过程主要用于保证当服务运行时长小于服务预热时间时,对服务进行降权,避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段,与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间,使其效率慢慢提升至最佳状态。

    RandomLoadBalance(默认负载策略)

    RandomLoadBalance 是加权随机算法的具体实现,它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C],他们对应的权重为 weights = [5, 3, 2],权重总和为10。现在把这些权重值平铺在一维坐标值上,[0, 5) 区间属于服务器 A,[5, 8) 区间属于服务器 B,[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数,然后计算这个随机数会落到哪个区间上。比如数字3会落到服务器 A 对应的区间上,此时返回服务器 A 即可。权重越大的机器,在坐标轴上对应的区间范围就越大,因此随机数生成器生成的数字就会有更大的概率落到此区间内。只要随机数生成器产生的随机数分布性很好,在经过多次选择后,每个服务器被选中的次数比例接近其权重比例。比如,经过一万次选择后,服务器 A 被选中的次数大约为5000次,服务器 B 被选中的次数约为3000次,服务器 C 被选中的次数约为2000次。

    image image

    RandomLoadBalance 的算法思想比较简单,在经过多次请求后,能够将调用请求按照权重值进行“均匀”分配。当然 RandomLoadBalance 也存在一定的缺点,当调用次数比较少时,Random 产生的随机数可能会比较集中,此时多数请求会落到同一台服务器上。这个缺点并不是很严重,多数情况下可以忽略。

    LeastActiveLoadBalance(最小活跃数负载均衡)

    活跃调用数越小,表明该服务提供者效率越高,单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。

    在具体实现中,每个服务提供者对应一个活跃数 active。初始情况下,所有服务提供者活跃数均为0。每收到一个请求,活跃数加1,完成请求后则将活跃数减1。在服务运行一段时间后,性能好的服务提供者处理请求的速度更快,因此活跃数下降的也越快,此时这样的服务提供者能够优先获取到新的服务请求、这就是最小活跃数负载均衡算法的基本思想。

    除了最小活跃数,LeastActiveLoadBalance 在实现上还引入了权重值。所以准确的来说,LeastActiveLoadBalance 是基于加权最小活跃数算法实现的。举个例子说明一下,在一个服务提供者集群中,有两个性能优异的服务提供者。某一时刻它们的活跃数相同,此时 Dubbo 会根据它们的权重去分配请求,权重越大,获取到新请求的概率就越大。如果两个服务提供者权重相同,此时随机选择一个即可。

    这段代码是 dubbo 2.6.4 版本的,虽然有一些 bug(去官网看),但对于我们理解这个算法影响不大,下面这段代码的注释已经也得很明显了,大家可以按照最小活跃数为 [2,2,2,1,1] 为例来看下面的这些代码。

    public class LeastActiveLoadBalance extends AbstractLoadBalance {
    
        public static final String NAME = "leastactive";
    
        private final Random random = new Random();
    
        @Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            int length = invokers.size();
            // 最小的活跃数
            int leastActive = -1;
            // 具有相同“最小活跃数”的服务者提供者(以下用 Invoker 代称)数量
            int leastCount = 0; 
            // leastIndexs 用于记录具有相同“最小活跃数”的 Invoker 在 invokers 列表中的下标信息
            int[] leastIndexs = new int[length];
            int totalWeight = 0;
            // 第一个最小活跃数的 Invoker 权重值,用于与其他具有相同最小活跃数的 Invoker 的权重进行对比,
            // 以检测是否“所有具有相同最小活跃数的 Invoker 的权重”均相等
            int firstWeight = 0;
            boolean sameWeight = true;
    
            // 遍历 invokers 列表
            for (int i = 0; i < length; i++) {
                Invoker<T> invoker = invokers.get(i);
                // 获取 Invoker 对应的活跃数
                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) {
                    // 使用当前活跃数 active 更新最小活跃数 leastActive
                    leastActive = active;
                    // 更新 leastCount 为 1
                    leastCount = 1;
                    // 记录当前下标值到 leastIndexs 中
                    leastIndexs[0] = i;
                    totalWeight = weight;
                    firstWeight = weight;
                    sameWeight = true;
    
                // 当前 Invoker 的活跃数 active 与最小活跃数 leastActive 相同 
                } else if (active == leastActive) {
                    // 在 leastIndexs 中记录下当前 Invoker 在 invokers 集合中的下标
                    leastIndexs[leastCount++] = i;
                    // 累加权重
                    totalWeight += weight;
                    // 检测当前 Invoker 的权重与 firstWeight 是否相等,
                    // 不相等则将 sameWeight 置为 false
                    if (sameWeight && i > 0
                        && weight != firstWeight) {
                        sameWeight = false;
                    }
                }
            }
            
            // 当只有一个 Invoker 具有最小活跃数,此时直接返回该 Invoker 即可
            if (leastCount == 1) {
                return invokers.get(leastIndexs[0]);
            }
    
            // 有多个 Invoker 具有相同的最小活跃数,但它们之间的权重不同
            if (!sameWeight && totalWeight > 0) {
                // 随机生成一个 [0, totalWeight) 之间的数字
                int offsetWeight = random.nextInt(totalWeight);
                // 循环让随机数减去具有最小活跃数的 Invoker 的权重值,
                // 当 offset 小于等于0时,返回相应的 Invoker
                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时,随机返回一个 Invoker
            return invokers.get(leastIndexs[random.nextInt(leastCount)]);
        }
    }
    

    ConsistentHashLoadBalance(一致性 hash 算法)

    如果不了解什么是一致性 hash 算法,建议看下这个视频,除了口齿不清,没啥大毛病

    一致性 hash 算法由麻省理工学院的 Karger 及其合作者于1997年提出的,算法提出之初是用于大规模缓存系统的负载均衡**。

    它的工作过程是这样的,首先根据 ip 或者其他的信息为缓存节点生成一个 hash,并将这个 hash 投射到 [0, 2^32 - 1] 的圆环上。当有查询或写入请求时,则为缓存项的 key 生成一个 hash 值。然后查找第一个大于或等于该 hash 值的缓存节点,并到这个节点中查询或写入缓存项。如果当前节点挂了,则在下一次查询或写入缓存时,为缓存项查找另一个大于其 hash 值的缓存节点即可。大致效果如下图所示,每个缓存节点在圆环上占据一个位置。如果缓存项的 key 的 hash 值小于缓存节点 hash 值,则到该缓存节点中存储或读取缓存项。比如下面绿色点对应的缓存项将会被存储到 cache-2 节点中。由于 cache-3 挂了,原本应该存到该节点中的缓存项最终会存储到 cache-4 节点中。

    image

    下面来看看一致性 hash 在 Dubbo 中的应用。我们把上图的缓存节点替换成 Dubbo 的服务提供者,于是得到了下图:

    image

    这里相同颜色的节点均属于同一个服务提供者,比如 Invoker1-1,Invoker1-2,……, Invoker1-160。这样做的目的是通过引入虚拟节点,让 Invoker 在圆环上分散开来,避免数据倾斜问题。所谓数据倾斜是指,由于节点不够分散,导致大量请求落到了同一个节点上,而其他节点只会接收到了少量请求的情况。比如:

    这种情况大量的请求全部到了 invoker1 服务提供者那里

    如上,由于 Invoker-1 和 Invoker-2 在圆环上分布不均,导致系统中75%的请求都会落到 Invoker-1 上,只有 25% 的请求会落到 Invoker-2 上。解决这个问题办法是引入虚拟节点,通过虚拟节点均衡各个节点的请求量。

    image image image

    RoundRobinLoadBalance(加权轮询)

    什么是加权轮询?这里从最简单的轮询开始讲起,所谓轮询是指将请求轮流分配给每台服务器。举个例子,我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A,第二个请求分配给服务器 B,第三个请求分配给服务器 C,第四个请求再次分配给服务器 A。这个过程就叫做轮询。轮询是一种无状态负载均衡算法,实现简单,适用于每台服务器性能相近的场景下。

    但现实情况下,我们并不能保证每台服务器性能均相近。如果我们将等量的请求分配给性能较差的服务器,这显然是不合理的。因此,这个时候我们需要对轮询过程进行加权,以调控每台服务器的负载。经过加权后,每台服务器能够得到的请求数比例,接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中,服务器 A 将收到其中的5次请求,服务器 B 会收到其中的2次请求,服务器 C 则收到其中的1次请求。

    代码我表示看不懂,我太菜了。

    相关文章

      网友评论

          本文标题:dubbo 源码解析 8

          本文链接:https://www.haomeiwen.com/subject/zrvgzhtx.html