RALB负载均衡算法的应用-Toy模板网

这篇具有很好参考价值的文章主要介绍了RALB负载均衡算法的应用。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、背景

搜索推荐算法架构为京东集团所有的搜索推荐业务提供服务，实时返回处理结果给上游。部门各子系统已经实现了基于CPU的自适应限流，但是Client端对Server端的调用依然是RR轮询的方式，没有考虑下游机器性能差异的情况，无法最大化利用集群整体CPU，存在着Server端CPU不均衡的问题。

京东广告部门针对其业务场景研发的负载均衡方法很有借鉴意义，他们提出的RALB(Remote Aware Load Balance)算法能够提升下游服务集群机器CPU资源效率，避免CPU短板效应，让性能好的机器能够处理更多的流量。我们将其核心思想应用到我们的系统中，获得了不错的收益。

本文的结构如下：

1.RALB简介

◦简单介绍了算法的原理。

2.功能验证

◦将RALB负载均衡技术应用到搜索推荐架构系统中，进行功能上的验证。

3.吞吐测试

◦主要将RALB和RR两种负载均衡技术做对比。验证了在集群不限流和完全限流的情况下，两者的吞吐没有明显差异。在RR部分限流的情况下，两者吞吐存在着差异，并且存在着最大的吞吐差异点。对于RALB来说，Server端不限流到全限流是一个转折点，几乎没有部分限流的情况。

4.边界测试

◦通过模拟各种边界条件，对系统进行测试，验证了RALB的稳定性和可靠性。

5.功能上线

◦在所有Server端集群全面开启RALB负载均衡模式。可以看出，上线前后，Server端的QPS逐渐出现分层，Server端的CPU逐渐趋于统一。

二、RALB 简介

RALB是一种以CPU均衡为目标的高性能负载均衡算法。

2.1 算法目标

1.调节Server端的CPU使用率，使得各节点之间CPU相对均衡，避免CPU使用率过高触发集群限流

2.QPS与CPU使用率成线性关系，调节QPS能实现CPU使用率均衡的目标

2.2 算法原理

2.2.1 算法步骤

1.分配流量的时候，按照权重分配（带权重的随机算法，wr）

2.收集CPU使用率：Server端通过RPC反馈CPU使用率（平均1s）给Client端

3.调权：定时（每3s）根据集群及各节点上的CPU使用率（窗口内均值）调节权重，使各节点CPU均衡

2.2.2 指标依赖

编号	指标	作用	来源
1	IP	可用IP列表	服务注册发现和故障屏蔽模块进行维护
2	实时健康度	IP可用状态实时变化，提供算法的边界条件	RPC框架健康检查功能维护
3	历史健康度	健康度历史值，用于判断ip故障及恢复等边界条件	指标2的历史值
4	动态目标（CPU使用率）	提供均衡算法的最直接目标依据	Server端定时统计，RPC框架通过RPC返回
5	权重weight	实时负载分发依据	算法更新

2.2.3 调权算法

2.2.4 边界处理

边界1：反馈窗口（3s）内，如果下游ip没被访问到，其CPU均值为0，通过调权算法会认为该节点性能极好，从而调大权重

边界2：网络故障时，RPC框架将故障节点设为不可用，CPU和权重为0；网络恢复后，RPC框架将IP设置为可用，但是权重为0的节点分不到流量，从而导致该节点将一直处于不可用状态

处理：权重的更新由定时器触发，记录节点的可用状态，当节点从不可用恢复为可用状态时，给定一个低权重，逐步恢复

2.3 落地关键

既要快又要稳，在任何情况下都要避免陷入僵局和雪崩，尤其要处理好边界条件

算法要点:

1.公式中各依赖因子的更新保持独立的含义和更新机制，以维护算法的可靠和简洁

◦IP列表的更新由服务注册发现和RPC框架共同保证

◦RPC更新CPU

2.注意边界值的含义，边界值的含义需要区分连续值

◦CPU = 0，表示未知，不表示CPU性能好

◦w = 0，表示不会被分配流量，只有在不可用的情况下才为0；可用情况下，应该至少有一个较小的值，保证仍能触发RPC，进而可以更新权重

3.算法更新权重，不要依赖RPC触发，而应该定时更新

三、功能验证

3.1 压测准备

Module	IP	CPU
Client端	10.173.102.36	8
Server端	11.17.80.238	8
11.18.159.191	8
11.17.191.137	8

3.2 压测数据

指标	RR负载均衡	RALB负载均衡
QPS	Server端的QPS均衡	从上图可以看出，Server端的QPS出现分层
CPU	CPU表现也比较均匀，维持在10%左右，不过相比于RALB，节点间CPU差距大些	****Server端CPU表现均匀，均维持在10%左右
TP99	延时稳定，存在一些差异	延时稳定，存在些微差异，相对RR小一些

由于机器性能差距不大，所以压测的CPU效果并不明显，为了使CPU效果更明显，给节点”11.17.80.238“施加起始的负载(即无流量时，CPU使用率为12.5%）

指标	LA负载均衡	RR负载均衡	RALB负载均衡
QPS	QPS极不均匀，而且流量倾斜严重，会出现流量全集中在一个节点上的现象	QPS均匀	QPS出现明显分层，其中QPS出现变化，是因为对“权重最大调整比例“进行了两次调整（1.5 → 2.0 → 2.5） 11.17.80.238：125 → 96 → 79 11.18.159.191：238 → 252 → 262 11.17.191.137：239 → 254 → 263
CPU	CPU不是LA均衡的目标，所以跟QPS趋势一致，全集中单个节点上	CPU出现明显分层，11.17.80.238的CPU明显高于其他节点	1、刚开始压测，11.17.80.238的CPU高于其他两个节点，因为“权重最大调整比例“为1.5（相对于base，固定值为10000），达到了调整极限 2、“权重最大调整比例“调整为2.0，节点间的差距变小 3、“权重最大调整比例“调整为2.5，节点间的差距进一步变小
TP99	承接流量的节点延时是稳定的，由于存在节点接受的流量很低（几乎没有），这些节点的延时看起来波动就比较大，不过LA对于延时的效果应该是稳定的，因为大部分请求是以比较均衡的延时得到处理的。	延时稳定，存在些微差异	延时稳定，存在些微差异，相对RR小一些

3.3 压测结论

经过压测，RR和LA均存在CPU不均衡的问题，会因为机器资源的性能差异，而导致短板效应，达不到充分利用资源的目的。

RALB是以CPU作为均衡目标的，所以会根据节点的CPU实时调整节点承接的QPS，进而达到CPU均衡的目标，功能上验证是可用的，CPU表现符合预期。

四、吞吐测试

4.1 压测目标

RALB是一种以CPU使用率作为动态指标的负载均衡算法，能很好地解决CPU不均衡的问题，避免CPU短板效应，让性能好的机器能够处理更多的流量。因此，我们期望RALB负载均衡策略相比于RR轮询策略能够得到一定程度的吞吐提升。

4.2 压测准备

Server端100台机器供测试，Server端为纯CPU自适应限流，限流阈值配置为55%。

4.3 压测数据

通过压测在RALB和RR两种负载均衡模式下，Server端的吞吐随着流量变化的趋势，对比两种负载均衡策略对于集群吞吐的影响。

4.3.1 RALB

4.3.1.1 吞吐数据

下表是Server端的吞吐数据，由测试发压Client端，负载均衡模式设置为RALB。在18:17Server端的状况接近于刚刚限流。整个压测阶段，压测了不限流、部分限流、完全限流3种情况。

时间	17:40	17:45	17:52	18:17	18:22
总流量	2270	1715	1152	1096	973
处理流量	982	1010	1049	1061	973
被限流量	1288	705	103	35	0
限流比例	56.74%	41%	8.9%	3.2%	0%
平均CPU使用率	55%	55%	54%	54%	49%

4.3.1.2 指标监控

Server端机器收到的流量按性能分配，CPU保持均衡。

QPS	CPU

4.3.2 RR

4.3.2.1 吞吐数据

下表是Server端的吞吐数据，由测试发压Client端，负载均衡模式设置为RR。在18:46 Server端的整体流量接近于18:17 Server端的整体流量。后面将重点对比这两个关键时刻的数据。

时间	18:40	18:46	19:57	20:02	20:04	20:09
总流量	967	1082	1149	1172	1263	1314
处理流量	927	991	1024	1036	1048	1047
被限流量	40	91	125	136	216	267
限流比例	4.18%	8.4%	10.92%	11.6%	17.1%	20.32%
平均CPU使用率	45%（部分限流）	51%（部分限流）	53%（部分限流）	54%（接近全部限流）	55%（全部限流）	55%（全部限流）

4.3.2.2 指标监控

Server端收到的流量均衡，但是CPU有差异。

QPS	CPU

4.4 压测分析

4.4.1 吞吐曲线

根据4.3节的压测数据，进行Server端吞吐曲线的绘制，对比RALB和RR两种负载均衡模式下的吞吐变化趋势。

import matplotlib.pyplot as plt
import numpy as np
       
x = [0,1,2,3,4,5,6,7,8,9,9.73,10.958,11.52,17.15,22.7]
y = [0,1,2,3,4,5,6,7,8,9,9.73,10.61,10.49,10.10,9.82]
  
w = [0,1,2,3,4,5,6,7,8,9.674,10.823,11.496,11.723,12.639,13.141,17.15,22.7]
z = [0,1,2,3,4,5,6,7,8,9.27,9.91,10.24,10.36,10.48,10.47,10.10,9.82]
  
plt.plot(x, y, 'r-o')
plt.plot(w, z, 'g-o')
plt.show()

4.4.2 曲线分析

负载均衡策略	RALB	RR
阶段一：所有机器未限流	接收QPS=处理QPS，表现为y =x 的直线	接收QPS=处理QPS，表现为y =x 的直线
阶段二：部分机器限流	不存在RALB根据下游CPU进行流量分配，下游根据CPU进行限流，理论上来讲，下游的CPU永远保持一致。所有的机器同时达到限流，不存在部分机器限流的情况。所以在图中，不限流与全部机器限流是一个转折点，没有平滑过渡的阶段。	RR策略，下游的机器分配得到的QPS一致，由于下游根据CPU进行限流，所以不同机器限流的时刻有差异。相对于RALB，RR更早地出现了限流的情况，并且在达到限流之前，RR的吞吐是一直小于RALB的。
阶段三：全部机器限流	全部机器都达到限流阈值55%之后，理论上，之后无论流量怎样增加，处理的QPS会维持不变。图中显示处理的QPS出现了一定程度的下降，是因为处理限流也需要消耗部分CPU	RR达到全部限流的时间要比RALB更晚。在全部限流之后，两种模式的处理的QPS是一致的。

4.5 压测结论

临界点：吞吐差异最大的情况，即RALB模式下非限流与全限流的转折点。

通过上述分析，可以知道，在RALB不限流与全部限流的临界点处，RR与RALB的吞吐差异最大。

此时，计算得出RALB模式下，Server集群吞吐提升7.06%。

五、边界测试

通过模拟各种边界条件，来判断系统在边界条件的情况下，系统的稳定性。

边界条件	压测情形	压测结论
下游节点限流	CPU限流	惩罚因子的调整对于流量的分配有重要影响
QPS限流	符合预期
下游节点超时	Server端超时每个请求，固定sleep 1s	请求持续超时期间分配的流量基本为0
下游节点异常退出	Server端进程被杀死直接kill -9 pid	杀死进程并自动拉起，流量分配快速恢复
下游节点增减	Server端手动Jsf上下线	jsf下线期间不承接流量
Server端重启stop + start	正常反注册、注册方式操作Server端进程，流量分配符合预期