2. 旧算法的缺陷

前面介绍了，除了新负载均衡算法AvgShedder，卸载策略有3种：ThresholdShedder、OverloadShedder、UniformLoadShedder，放置策略有2种：LeastLongTermMessageRate、LeastResourceUsageWithWeight。

因此用户可以搭配出3*2=6种组合方式，但实际上只有两种组合方式是值得推荐的：

• ThresholdShedder + LeastResourceUsageWithWeight

• UniformLoadShedder + LeastLongTermMessageRate

而默认配置是ThresholdShedder + LeastLongTermMessageRate，这是一个非常糟糕的组合，强烈要求用户修改默认配置。

此外，推荐的两种组合各有其优势与劣势。基于适应性、稳定性、正确性以及负载均衡速度等多个维度，我对它们进行了评分，后面章节我会详细介绍给不同组合评分的过程。以下是相应的评分表格：

策略	适应异构环境 （适应性）	适应负载抖动 （稳定性）	过度加载问题 （正确性）	过度卸载问题 （正确性）	负载均衡速度
ThresholdShedder + LeastResourceUsageWithWeight	一般	良	差	差	一般
UniformLoadShedder + LeastLongTermMessageRate	差	差	良	良	一般

可以看到：

• 组合ThresholdShedder + LeastResourceUsageWithWeight在负载均衡正确性方面比较差，经常导致错误的负载均衡决策，这也导致了它往往需要多轮迭代才能最终稳定，因此负载均衡速度也一般。

• 组合UniformLoadShedder + LeastLongTermMessageRate 则在适应性和稳定性方面比较差，无法适应异构环境，面对负载抖动时经常会触发错误的负载均衡决策。

下面详细介绍一下适应性、稳定性、正确性这三个问题。

2.1 适应性

适应性问题是指旧算法无法适应异构环境，相比低性能机器，更高性能的机器无法承担更多的流量负载。

显然，我们会希望更高性能的机器承担更多的负载，但是旧算法组合UniformLoadShedder +

LeastLongTermMessageRate 会根据流量吞吐来进行排序，排名越高的机器认为是负载越高，从而将流量由高性能机器卸给低性能机器，导致低性能机器CPU使用率过高，高性能机器CPU使用率过低。

下面看一个具体的例子：

单独看Byte In/Out监控，我们会认为这是一次非常完美的负载均衡执行，四台机器的流量分别为28MB/s、46MB/s、55MB/s、66MB/s，负载均衡完成后四台机器的流量均在40MB/s附近徘徊。

但是我们结合CPU使用率来看，会发现蓝色机器的CPU使用率远低于其他机器，蓝色机器的CPU使用率只有17%，而其他机器的CPU使用率达到了50%。这是因为蓝色机器的性能远超其他机器，CPU核数多了一倍多，因此施加同样的负载，蓝色机器的资源使用率会显著低于其他机器，但是我们会更希望蓝色机器承担更多的负载，因此，这不是一个正确的负载均衡操作。

2.2 稳定性

稳定性问题指的是旧算法在应对短期负载波动时，会频繁地进行负载切换，这导致用户连接经常被中断，以及流量的不稳定。

有时用户会启动一个数据吞吐量巨大，但运行时间极短的任务，例如处理上百兆的数据量，仅需一两分钟即可完成。这将对某些机器造成较大的负载压力，导致集群的负载分布不均。在这种情况下，应避免进行负载均衡操作。因为一旦执行了负载均衡，待用户任务在几分钟后结束，集群又会回到不均衡的状态，从而引发频繁且不必要的负载均衡调整，这将严重影响用户体验。

如下面例子，启动一个模拟流量，消费流量每运行1min就停止，等待1min后再继续消费，旧算法会一直执行负载切换。

bundle卸载个数指标一直上升，说明bundle unload一直触发，负载均衡算法频繁触发。

2.3 正确性

正确性指的是旧算法可能会做出错误的决策，导致机器出现过载或欠载的情况。具体来说，这包括过度加载和过度卸载两个问题。

• 过度加载问题

举例来说，当前存在 10 台 CPU 使用率处于 50% 的机器以及 1 台 CPU 使用率为 30% 的机器。鉴于集群压力较小，计划进行缩容操作，减少 3 台机器。然而，这 3 台被缩容机器的负载，很可能全部转移至那台原本 CPU 使用率为 30% 的机器上，进而致使其 CPU 使用率从 30% 急剧攀升至 80% 。

• 过度卸载问题

例如，机器 1 的 CPU 使用率达到 80%，而机器 2 的 CPU 使用率仅为 20%。理想情况下，若我们对两台机器的流量进行平均分配，二者的 CPU 使用率都变为 50%，这已然达到了最佳状态。然而，旧算法中存在一种历史均值打分算法，该算法使得机器的实际负载无法及时在得分排名中得以体现。因此系统仍会继续判定机器 1 处于高负载状态，机器 2 处于低负载状态，进而继续将机器 1 的流量转移至机器 2。最终的结果是，机器 1 转变为低负载，而机器 2 则转变为高负载。

下面举一个例子，使用ThresholdShedder + LeastResourceUsageWithWeight算法组合。

可以看到，黄色机器在高负载与低负载状态间频繁切换。其 CPU 使用率从 80% 降至 40%，随后又从 40% 回升至 80%。在此过程中，先是引发了过度卸载问题，紧接着又触发了过度加载问题。