2万字长文带你细细盘点五种负载均衡策略( 六 ) _负载均衡

剖析源码
com.alibaba.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance的源码如下，我逐行进行了解读。可以点开查看大图，细细品读，非常爽：

文章插图

下图中红框框起来的部分就是一个基于权重选择invoker的逻辑：

文章插图

我给大家画图分析一下：

文章插图

请仔细分析图中给出的举例说明。同时，上面这图也是按照比例画的，可以直观的看到，对于某一个请求，区间(权重)越大的服务器，就越可能会承担这个请求。所以，当请求足够多的时候，各个服务器承担的请求数，应该就是区间，即权重的比值。
其中第 81 行有调用 getWeight 方法，位于抽象类 AbstractLoadBalance 中，也需要进行重点解读的代码。
com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance 的源码如下，我也进行了大量的备注:

文章插图

在 AbstractLoadBalance 类中提到了一个预热的概念。官网中是这样的介绍该功能的：
权重的计算过程主要用于保证当服务运行时长小于服务预热时间时，对服务进行降权，避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段，与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间，使其效率慢慢提升至最佳状态。
从上图代码里面的公式(演变后)：*计算后的权重=(uptime/warmup)weight 可以看出：随着服务启动时间的增加(uptime)，计算后的权重会越来越接近weight 。从实际场景的角度来看，随着服务启动时间的增加，服务承担的流量会慢慢上升，没有一个陡升的过程。所以这是一个优化手段。同时 Dubbo 接口还支持延迟暴露。
在仔细的看完上面的源码解析图后，配合官网的总结加上我的灵魂画作，相信你可以对最小活跃数负载均衡算法有一个比较深入的理解：

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

文章插图

所以我觉得最小活跃数负载均衡的全称应该叫做：有最小活跃数用最小活跃数，没有最小活跃数根据权重选择，权重一样则随机返回的负载均衡算法。
Bug在哪里？Dubbo2.6.0最小活跃数算法Bug一

文章插图

问题出在标号为 ① 和 ② 这两行代码中：
标号为 ① 的代码在url中取出的是没有经过 getWeight 方法降权处理的权重值，这个值会被累加到权重总和(totalWeight)中。
标号为 ② 的代码取的是经过 getWeight 方法处理后的权重值。
取值的差异会导致一个问题，标号为 ② 的代码的左边，offsetWeight 是一个在 [0，totalWeight) 范围内的随机数，右边是经过 getWeight 方法降权后的权重。所以在经过 leastCount 次的循环减法后，offsetWeight 在服务启动时间还没到热启动设置（默认10分钟）的这段时间内，极大可能仍然大于 0 。导致不会进入到标号为 ③ 的代码中。直接到标号为 ④ 的代码处，变成了随机调用策略。这与设计不符，所以是个 bug 。
前面章节说的情况就是这个Bug导致的。
这个Bug对应的issues地址和pull request分为:

https://github.com/apache/dubbo/issues/904

https://github.com/apache/dubbo/pull/2172

那怎么修复的呢？我们直接对比 Dubbo 2.7.4.1 的代码:

文章插图

可以看到获取weight的方法变了：从url中直接获取变成了通过getWeight方法获取。获取到的变量名称也变了：从weight变成了afterWarmup，更加的见名知意。
还有一处变化是获取随机值的方法的变化，从Randmo变成了ThreadLoaclRandom，性能得到了提升。这处变化就不展开讲了，有兴趣的朋友可以去了解一下。