5. 对比实验
5.1 对比UniformLoadShedder + LeastLongTermMessageRate
5.1.1 异构环境
跟前面测试UniformLoadShedder + LeastLongTermMessageRate一样的异构环境和压力负载，机器XXX.34是异构的，它的性能比另外三台机器强很多。
可以观察到，机器XXX.34的流量吞吐、消息速率显著高于其他机器。
消息速率和流量吞吐的最大最小比值甚至达到了11，但这是很合理的，因为观察资源使用率我们就会发现：XXX.34这台机器的负载还是最低的！
可以看到，XXX.34的资源使用率还是不到其他机器的一半。读者可能会希望其他机器比如说XXX.83的负载进一步分给XXX.34，从而使得资源使用率进一步均衡下来，但是当前AvgShedder算法还没法做到这种程度，只是在异构环境下会比UniformLoadShedder更优秀。
5.1.2 负载抖动
进一步部署周期抖动的消费任务：
可以看到，一次bundle unload都没有触发！稳定性良好。
5.2 对比ThresholdShedder + LeastResourceUsageWithWeight
接下来部署跟ThresholdShedder + LeastResourceUsageWithWeight一样的测试环境，即机器是同构的，从而对比效果。
启动三个压测任务如下：
可以看到，启动压测任务后，XXX.83（绿色线）承载了最多的流量，也是CPU使用率最高的broker，XXX.161（蓝色线）承载了最少的流量，也是CPU使用率最低的broker，两者之间的打分差距63-38.5=24.5 > 15，因此连续检查8次（等待8min）后触发了负载均衡，XXX.83与XXX.161均摊了流量。
只需触发这一次bundle unload，集群就进入了稳定状态，而ThresholdShedder + LeastResourceUsageWithWeight花费了22min，执行了很多次错误的bundle unload。
执行完这唯一一次负载均衡后，集群的消息速率和流量吞吐的最大最小比值也从2.5下降到1.5了，效果良好。
另外，我们还观察到一次负载抖动，XXX.32的CPU负载突然飙高到86.5，后又迅速下降回来，但它的流量吞吐并没有变化，这可能是因为机器上部署的其他进程等原因导致的，但是不管是什么原因，负载均衡算法都不能立马触发bundle unload，而AvgShedder做到了这一点，再次展示了它应对负载抖动的能力。
5.2.1 broker缩容
将broker XXX.161（蓝色线）下线，观察集群流量变化情况。
可以看到，XXX.161（蓝色线）卸载下来的流量分给了XXX.83（绿色线）、XXX.87（橙色线）、XXX.32（红色线），而XXX.206（黄色线）没有分到流量。从日志中也可以看到这个分配结果：
可以看到，这个分配结果已经相当均匀了，总共3个bundle，选中了3个broker各分配一个，但从监控上看可以看到，不同broker上涨的流量幅度是不一样的，这表明了不同bundle的流量吞吐大小是不一样的，要想进一步优化效果，增加集群bundle的数目是合适的方案，不仅可以降低bundle之间的流量差距，还可以让部分流量也分配给第四个broker。
因为资源使用率差距没有持续性地超过15，缩容后没有触发bundle unload。
5.2.2 broker扩容
集群缩容并且稳定后，重新加入机器XXX.87，观察集群的负载均衡情况。
可以看到，新机器加入后没多久就触发bundle unload了，这是因为最高载和最低载的打分差距达到了高阈值40，因此只需要连续两次触发就可以执行bundle unload（1min执行一次，因此只需等待2min，不需要8min）。
触发bundle unload后，将最高载的XXX.161（蓝色线）与新加入的XXX.87（橙色线）均摊负载了。
Last updated
Was this helpful?