你不觉得奇怪吗，为什么权重为200的活跃数是最高的？
其在业务上的含义是：我们有三台性能各异的服务器，A服务器性能最好，所以权重为300，B服务器性能中等，所以权重为200，C服务器性能最差，所以权重为100。
当我们选择最小活跃次数的负载均衡算法时，我们期望的是性能最好的A服务器承担更多的请求，而真实的情况是性能中等的B服务器承担的请求更多。这与我们的设定相悖。
如果你说20个请求数据量太少，可能是巧合，不足以说明问题。说明你还没被我带偏，我们不能基于巧合编程。
所以为了验证这个地方确实有问题，我把请求扩大到一万个。
同时，记得扩大 provider 端的 Dubbo 线程池：
由于每个服务端运行的代码都是一样的，所以我们期望的结果应该是权重最高的承担更多的请求。但是最终的结果如图所示:
各个服务器均摊了请求。这就是我文章最开始的时候说的Dubbo 2.6.0 版本中最小活跃数负载均衡算法的Bug之一。
接下来，我们带着这个问题，去分析源码。
剖析源码
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，性能得到了提升。这处变化就不展开讲了，有兴趣的朋友可以去了解一下。
Dubbo2.6.0最小活跃数算法Bug二
这个Bug我没有遇到，但是我在官方文档上看了其描述（官方文档中的版本是2.6.4），引用如下：
官网上说这个问题在2.6.5版本进行修复。我对比了2.6.0/2.6.5/2.7.4.1三个版本，发现每个版本都略有不同。如下所示：
图中标记为①的三处代码：
2.6.0版本的是有Bug的代码，原因在上面说过了。
2.6.5版本的修复方式是获取随机数的时候加一，所以取值范围就从**[0,totalWeight)变成了[0,totalWeight]**，这样就可以避免这个问题。
2.7.4.1版本的取值范围还是[0,totalWeight)，但是它的修复方法体现在了标记为②的代码处。2.6.0/2.6.5版本标记为②的地方都是if(offsetWeight<=0)，而2.7.4.1版本变成了if(offsetWeight<0)。
你品一品，是不是效果是一样的，但是更加优雅了。
朋友们，魔鬼，都在细节里啊！
好了，进入下一议题。
