Dubbo 源码分析 - 集群容错之 LoadBalance

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1.简介

LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载的服务器分流的同时，还可以避免资源浪费，一举两得。负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中，一般很难接触到硬件负载均衡。但软件负载均衡还是能够接触到一些的，比如 Nginx。在 Dubbo 中，也有负载均衡的概念和相应的实现。Dubbo 需要对服务消费者的调用请求进行分配，避免少数服务提供者负载过大。服务提供者负载过大，会导致部分服务调用超时。因此将负载均衡到每个服务提供者上，是非常必要的。Dubbo 提供了4种负载均衡实现，分别是基于权重随机算法的 RandomLoadBalance、基于最少活跃调用数算法的 LeastActiveLoadBalance、基于 hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。这几个负载均衡算法代码不是很长，但是想看懂也不是很容易，需要大家对这几个算法的原理有一定了解才行。如果不是很了解，也没不用太担心。我会在分析每个算法的源码之前，对算法原理进行简单的讲解，帮助大家建立初步的印象。

我在写 Dubbo 源码分析系列文章之初，当时 Dubbo 最新的版本为 2.6.4。近期，Dubbo 2.6.5 发布了，其中就有对负载均衡部分代码修改。因此我在分析完 2.6.4 版本后的源码后，会另外分析 2.6.5 更新的部分。本篇文章内容非常之丰富，需要大家耐心阅读。好了，其他的就不多说了，进入正题吧。

2.源码分析

在 Dubbo 中，所有负载均衡实现类均继承自 AbstractLoadBalance，该类实现了 LoadBalance 接口方法，并封装了一些公共的逻辑。所以在分析负载均衡实现之前，先来看一下 AbstractLoadBalance 的逻辑。首先来看一下负载均衡的入口方法 select，如下：

select 方法的逻辑比较简单，首先会检测 invokers 集合的合法性，然后再检测 invokers 集合元素数量。如果只包含一个 Invoker，直接返回该 Inovker 即可。如果包含多个 Invoker，此时需要通过负载均衡算法选择一个 Invoker。具体的负载均衡算法由子类实现，接下来章节会对这些子类进行详细分析。

AbstractLoadBalance 除了实现了 LoadBalance 接口方法，还封装了一些公共逻辑 —— 服务提供者权重计算逻辑。具体实现如下：

上面是权重的计算过程，该过程主要用于保证当服务运行时长小于服务预热时间时，对服务进行降权，避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段，与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间，使其效率慢慢提升至最佳状态。关于预热方面的更多知识，大家感兴趣可以自己搜索一下。

关于 AbstractLoadBalance 就先分析到这，接下来分析各个实现类的代码。首先，我们从 Dubbo 缺省的实现类 RandomLoadBalance 看起。

2.1 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次。

以上就是 RandomLoadBalance 背后的算法思想，比较简单，不多说了，下面开始分析源码。

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

关于 RandomLoadBalance 就先到这了，接下来分析 LeastActiveLoadBalance。

2.2 LeastActiveLoadBalance

LeastActiveLoadBalance 翻译过来是最小活跃数负载均衡，所谓的最小活跃数可理解为最少连接数。即服务提供者目前正在处理的请求数（一个请求对应一条连接）最少，表明该服务提供者效率高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。在具体实现中，每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快。此时这样的服务提供者能够优先获取到新的服务请求，这就是最小活跃数负载均衡算法的基本思想。除了最小活跃数，LeastActiveLoadBalance 在实现上还引入了权重值。所以准确的来说，LeastActiveLoadBalance 是基于加权最小活跃数算法实现的。举个例子说明一下，在一个服务提供者集群中，有两个性能优异的服务提供者。某一时刻它们的活跃数相同，此时 Dubbo 会根据它们的权重去分配请求，权重越大，获取到新请求的可能性就越大。如果两个服务提供者权重相同，此时随机选择一个即可。关于 LeastActiveLoadBalance 的背景知识就先介绍到这里，下面开始分析源码。

如上，为了帮助大家理解代码，我在上面的代码中写了大量的注释。下面简单总结一下以上代码所做的事情，如下：

1. 遍历 invokers 列表，寻找活跃数最小的 Invoker
2. 如果有多个 Invoker 具有相同的最小活跃数，此时记录下这些 Invoker 在 invokers 集合中的下标，以及累加它们的权重，比较它们之间的权重值是否相等
3. 如果只有一个 Invoker 具有最小的活跃数，此时直接返回该 Invoker 即可
4. 如果有多个 Invoker 具有最小活跃数，且它们的权重不相等，此时处理方式和 RandomLoadBalance 一致
5. 如果有多个 Invoker 具有最小活跃数，但它们的权重相等，此时随机返回一个即可

以上就是 LeastActiveLoadBalance 大致的实现逻辑，大家在阅读的源码的过程中要注意区分活跃数与权重这两个概念，不要混为一谈。

以上分析是基于 Dubbo 2.6.4 版本进行了，由于近期 Dubbo 2.6.5 发布了，对负载均衡部分的代码进行了一些更新。这其中就包含了本节分析的 LeastActiveLoadBalance，所以下面简单说明一下 Dubbo 2.6.5 对 LeastActiveLoadBalance 进行了怎样的修改。回到上面的源码中，我在上面的代码中标注了两个黄色的五角星⭐️。两处标记对应的代码分别如下：

问题出在服务预热阶段，第一行代码直接从 url 中去权重值，未被降权过。第二行代码获取到的是经过降权后的权重。第一行代码获取到的权重值最终会被累加到权重总和 totalWeight 中，这个时候会导致一个问题。offsetWeight 是一个在 [0, totalWeight) 范围内的随机数，而它所减去的是经过降权的权重。很有可能在经过 leastCount 次运算后，offsetWeight 仍然是大于0的，导致无法选中 Invoker。这个问题对应的 issue 为 #904，在 pull request #2172 中被修复。具体的修复逻辑是将标注一处的代码修改为：

另外，2.6.4 版本中的 LeastActiveLoadBalance 还要一个缺陷，即当一组 Invoker 具有相同的最小活跃数，且其中一个 Invoker 的权重值为1，此时这个 Invoker 无法被选中。缺陷代码如下：

问题就出在了offsetWeight <= 0上，举例说明，假设有一组 Invoker 的权重为 5、2、1，offsetWeight 最大值为 7。假设 offsetWeight = 7，你会发现，当 for 循环进行第二次遍历后 offsetWeight = 7 - 5 - 2 = 0，提前返回了。此时，权重为1的 Invoker 就没有机会被选中。这个修改起来也不难，可以将 offsetWeight < 0，不过 Dubbo 的是将offsetWeight + 1，也就是：

两种改动都行，不过我认为觉得第一种方式更好一点，可与 RandomLoadBalance 逻辑保持一致。这里+1有点突兀，大家读到这里要特地思考一下为什么要+1。

以上就是 Dubob 2.6.5 对 LeastActiveLoadBalance 的更新，不是很难理解，就不多说了。接下来分析基于一致性 hash 思想的 ConsistentHashLoadBalance。

2.3 ConsistentHashLoadBalance

一致性 hash 算法由麻省理工学院的 Karger 及其合作者于1997年提供出的，算法提出之初是用于大规模缓存系统的负载均衡。它的工作过程是这样的，首先根据 ip 获取其他的信息为缓存节点生成一个 hash，并将这个 hash 投射到 [0, 232 - 1] 的圆环上。当有查询或写入请求时，则为缓存项的 key 生成一个 hash 值。然后查找第一个大于或等于该 hash 值的缓存节点，并到这个节点中查询或写入缓存项。如果当前节点挂了，则在下一次查询或写入缓存时，为缓存项查找另一个大于其 hash 值的缓存节点即可。大致效果如下，每个缓存节点在圆环上占据一个位置。如果缓存项的 key 的 hash 值小于缓存节点 hash 值，则到该缓存节点中存储或读取缓存项。比如下面绿色点对应的缓存项存储到 cache-2 节点中。由于 cache-3 挂了，原本应该存到该节点中的缓存想最终会存储到 cache-4 节点中。

关于一致性 hash 算法，我这里只做扫盲。具体的细节不讨论，大家请自行补充相关的背景知识。下面来看看一致性 hash 在 Dubbo 中的应用。我们把上图的缓存节点替换成 Dubbo 的服务提供者，于是得到了下图：

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

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

到这里背景知识就普及完了，接下来开始分析源码。我们先从 ConsistentHashLoadBalance 的 doSelect 方法开始看起，如下：

如上，doSelect 方法主要做了一些前置工作，比如检测 invokers 列表是不是变动过，以及创建 ConsistentHashSelector。这些工作做完后，接下来开始调用 select 方法执行负载均衡逻辑。在分析 select 方法之前，我们先来看一下一致性 hash 选择器 ConsistentHashSelector 的初始化过程，如下：

ConsistentHashSelector 的构造方法执行了一系列的初始化逻辑，比如从配置中获取虚拟节点数以及参与 hash 计算的参数下标，默认情况下只使用第一个参数进行 hash。需要特别说明的是，ConsistentHashLoadBalance 的负载均衡逻辑只受参数值影响，具有相同参数值的请求将会被分配给同一个服务提供者。ConsistentHashLoadBalance 不 care 权重，因此使用时需要注意一下。

在获取虚拟节点数和参数下标配置后，接下来要做的事情是计算虚拟节点 hash 值，并将虚拟节点存储到 TreeMap 中。到此，ConsistentHashSelector 初始化工作就完成了。接下来，我们再来看看 select 方法的逻辑。

如上，选择的过程比较简单了。首先是对参数进行 md5 以及 hash 运算，得到一个 hash 值。然后再拿这个值到 TreeMap 中查找目标 Invoker 即可。

到此关于 ConsistentHashLoadBalance 就分析完了。在阅读 ConsistentHashLoadBalance 之前，大家一定要先补充背景知识。否者即使这里只有一百多行代码，也很难看懂。好了，本节先分析到这。

2.4 RoundRobinLoadBalance

本节，我们来看一下 Dubbo 中的加权轮询负载均衡的实现 RoundRobinLoadBalance。在详细分析源码前，我们还是先来了解一下什么是加权轮询。这里从最简单的轮询开始讲起，所谓轮询就是将请求轮流分配给一组服务器。举个例子，我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A，第二个请求分配给服务器 B，第三个请求分配给服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做轮询。轮询是一种无状态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。显然，现实情况下，我们并不能保证每台服务器性能均相近。如果我们将等量的请求分配给性能较差的服务器，这显然是不合理的。因此，这个时候我们需要加权轮询算法，对轮询过程进行干预，使得性能好的服务器可以得到更多的请求，性能差的得到的少一些。每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将获取到其中的5次请求，服务器 B 获取到其中的2次请求，服务器 C 则获取到其中的1次请求。

以上就是加权轮询的算法思想，搞懂了这个思想，接下来我们就可以分析源码了。我们先来看一下 2.6.4 版本的 RoundRobinLoadBalance。

如上，RoundRobinLoadBalance 的每行代码都不是很难理解，但是将它们组合到一起之后，好像就看不懂了。这里对上面代码的主要逻辑进行总结，如下：

1. 找到最大权重值，并计算出权重和
2. 使用调用编号对权重总和进行取余操作，得到 mod
3. 检测 mod 的值是否等于0，且 Invoker 权重是否大于0，如果两个条件均满足，则返回该 Invoker
4. 如果上面条件不满足，且 Invoker 权重大于0，此时对 mod 和权重进行递减
5. 再次循环，重复步骤3、4

以上过程对应的原理不太好解释，所以下面直接举例说明把。假设我们有三台服务器 servers = [A, B, C]，对应的权重为 weights = [2, 5, 1]。接下来对上面的逻辑进行简单的模拟。

mod = 0：满足条件，此时直接返回服务器 A

mod = 1：需要进行一次递减操作才能满足条件，此时返回服务器 B

mod = 2：需要进行两次递减操作才能满足条件，此时返回服务器 C

mod = 3：需要进行三次递减操作才能满足条件，经过递减后，服务器权重为 [1, 4, 0]，此时返回服务器 A

mod = 4：需要进行四次递减操作才能满足条件，经过递减后，服务器权重为 [0, 4, 0]，此时返回服务器 B

mod = 5：需要进行五次递减操作才能满足条件，经过递减后，服务器权重为 [0, 3, 0]，此时返回服务器 B

mod = 6：需要进行六次递减操作才能满足条件，经过递减后，服务器权重为 [0, 2, 0]，此时返回服务器 B

mod = 7：需要进行七次递减操作才能满足条件，经过递减后，服务器权重为 [0, 1, 0]，此时返回服务器 B

经过8次调用后，我们得到的负载均衡结果为 [A, B, C, A, B, B, B, B]，次数比 A:B:C = 2:5:1，等于权重比。当 sequence = 8 时，mod = 0，此时重头再来。从上面的模拟过程可以看出，当 mod >= 3 后，服务器 C 就不会被选中了，因为它的权重被减为0了。当 mod >= 4 后，服务器 A 的权重被减为0，此后 A 就不会再被选中。

以上是 2.6.4 版本的 RoundRobinLoadBalance 分析过程，大家如果看不懂，自己可以定义一些权重组合进行模拟。也可以写点测试用例，进行调试分析，总之不要死看。

2.6.4 版本的 RoundRobinLoadBalance 存在着比较严重的性能问题，该问题最初是在 issue #2578 中被反馈出来。问题出在了 Invoker 的返回时机上，RoundRobinLoadBalance 需要在mod == 0 && v.getValue() > 0 条件成立的情况下才会被返回相应的 Invoker。假如 mod 很大，比如 10000，50000，甚至更大时，doSelect 方法需要进行很多次计算才能将 mod 减为0。由此可知，doSelect 的效率与 mod 有关，时间复杂度为 O(mod)。mod 又受最大权重 maxWeight 的影响，因此当某个服务提供者配置了非常大的权重，此时 RoundRobinLoadBalance 会产生比较严重的性能问题。这个问题被反馈后，社区很快做了回应。并对 RoundRobinLoadBalance 的代码进行了重构，将时间复杂度优化至了常量级别。这个优化可以说很好了，下面我们来学习一下优化后的代码。

上面代码的逻辑是这样的，每进行一轮循环，重新计算 currentWeight。如果当前 Invoker 权重大于 currentWeight，则返回该 Invoker。还是举例说明吧，假设服务器 [A, B, C] 对应权重 [5, 2, 1]。

第一轮循环，currentWeight = 1，可返回 A 和 B

第二轮循环，currentWeight = 2，返回 A

第三轮循环，currentWeight = 3，返回 A

第四轮循环，currentWeight = 4，返回 A

第五轮循环，currentWeight = 0，返回 A, B, C

如上，这里的一轮循环是指 index 再次变为0所经历过的循环，这里可以把 index = 0 看做是一轮循环的开始。每一轮循环的次数与 Invoker 的数量有关，Invoker 数量通常不会太多，所以我们可以认为上面代码的时间复杂度为常数级。

重构后的 RoundRobinLoadBalance 看起来已经很不错了，但是在代码更新不久后，很有又被重构了。这次重构原因是新的 RoundRobinLoadBalance 在某些情况下选出的服务器序列不够均匀。比如，服务器 [A, B, C] 对应权重 [5, 1, 1]。现在进行7次负载均衡，选择出来的序列为 [A, A, A, A, A, B, C]。前5个请求全部都落在了服务器 A上，分布不够均匀。这将会使服务器 A 短时间内接收大量的请求，压力陡增。而 B 和 C 无请求，处于空闲状态。我们期望的结果是这样的 [A, A, B, A, C, A, A]，不同服务器可以穿插获取请求。为了增加负载均衡结果的平滑性，社区再次对 RoundRobinLoadBalance 的实现进行了重构。这次重构参考自 Nginx 的平滑加权轮询负载均衡，实现原理是这样的。每个服务器对应两个权重，分别为 weight 和 currentWeight。其中 weight 是固定的，currentWeight 是会动态调整，初始值为0。当有新的请求进来时，遍历服务器列表，让它的 currentWeight 加上自身权重。遍历完成后，找到最大的 currentWeight，并将其减去权重总和，然后返回相应的服务器即可。

上面描述不是很好理解，下面还是举例说明吧。仍然使用服务器 [A, B, C] 对应权重 [5, 1, 1] 的例子进行说明，现在有7个请求依次进入负载均衡逻辑，选择过程如下：

如上，经过平滑性处理后，得到的服务器序列为 [A, A, B, A, C, A, A]，相比之前的序列 [A, A, A, A, A, B, C]，分布性要好一些。初始情况下 currentWeight = [0, 0, 0]，第7个请求处理完后，currentWeight 再次变为 [0, 0, 0]，是不是很神奇。这个结果也不难理解，在7次计算过程中，每个服务器的 currentWeight 都增加了自身权重 weight * 7，得到 currentWeight = [35, 7, 7]，A 被选中5次，要被减去 5 * 7。B 和 C 被选中1次，要被减去 1 * 7。于是 currentWeight = [35, 7, 7] - [35, 7, 7] = [0, 0, 0]。

以上就是平滑加权轮询的计算过程，现在大家应该对平滑加权轮询算法了有了一些了解。接下来，我们来看看 Dubbo-2.6.5 是如何实现上面的计算过程的。

以上就是 Dubbo-2.6.5 版本的 RoundRobinLoadBalance，大家如果能够理解平滑加权轮询算法的计算过程，再配合我写的注释，理解上面的代码应该不难。

以上就是关于 RoundRobinLoadBalance 全部的分析，内容有点多，大家慢慢消化吧。好了，本节先到这。

3.总结

本篇文章对 Dubbo 中的几种负载均衡实现进行了详细的分析，总的来说，这篇文章写的还是有点累的。主要是每介绍一种负载均衡实现，就要介绍一下相关背景。另一方面，这里很多东西对于我来说，也完全是新的。在此之前，我对负载均衡算法并没太多了解。这篇文章基本上是边学边写的，总共耗时5天。本来想简单写写算了，但最后还是决定写详细点。好在，现在写完了，我也可以放松一下了。

本篇文章是我的 Dubbo 源码分析系列文章关于集群容错部分的最后一篇文章，写完感觉学到了很多东西。通过坚持不懈的阅读代码，写技术文章，使得我对 Dubbo 有了更深入的了解。当然，这还远远不够。后续还有很多东西要了解，比如 Nacos、Sentinel 等。长路漫漫，步履不停。

好了，本篇文章到这里就结束了。感谢大家的阅读。

参考

• 负载均衡之加权轮询算法 - CSDN
• dubbo源码-预热warmup过程 - 简书
• 一致性哈希算法原理 - 博客园

附录：Dubbo 源码分析系列文章

• 本文链接： https://www.tianxiaobo.com/2018/11/29/Dubbo-源码分析-集群容错之-LoadBalance/
• 版权声明： 本博客所有文章除特别声明外，均采用 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议 许可协议。转载请注明出处！

田小波

勿在浮沙筑高台

本文转自 http://www.tianxiaobo.com/2018/11/29/Dubbo-%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99%E4%B9%8B-LoadBalance/，如有侵权，请联系删除。