1. Antecedentes
La arquitectura del algoritmo de búsqueda y recomendación brinda servicios para todos los negocios de búsqueda y recomendación de JD.com, y devuelve los resultados del procesamiento al upstream en tiempo real. Cada subsistema del departamento ha implementado una limitación de corriente adaptativa basada en CPU, pero la llamada del cliente al servidor sigue siendo un sondeo de RR, que no tiene en cuenta las diferencias de rendimiento de las máquinas posteriores y no puede maximizar el uso de la CPU general del clúster Finalice el problema de desequilibrio de la CPU.
El método de equilibrio de carga desarrollado por el departamento de publicidad de JD para sus escenarios comerciales es de gran referencia. El algoritmo RALB (Remote Aware Load Balance) que propusieron puede mejorar la eficiencia de los recursos de la CPU de las máquinas del clúster de servicio descendente, evitar los efectos de cortocircuito de la CPU y permitir máquinas con buen rendimiento para manejar más tráfico. Aplicamos sus ideas centrales a nuestro sistema y obtuvimos buenos resultados.
La estructura de este artículo es la siguiente:
1. Introducción a RALB
◦ Se introduce brevemente el principio del algoritmo.
2. Verificación funcional
◦ Aplicar la tecnología de equilibrio de carga RALB al sistema de arquitectura de recomendaciones de búsqueda para la verificación funcional.
3. Prueba de rendimiento
◦ Comparar principalmente las tecnologías de equilibrio de carga RALB y RR. Se ha verificado que no hay una diferencia significativa en el rendimiento entre los clústeres sin límite de corriente y con límite de corriente total. En el caso de limitación de corriente parcial RR, hay una diferencia en el rendimiento entre los dos, y hay un punto de diferencia de rendimiento máximo. Para RALB, es un punto de inflexión del límite de flujo ilimitado al límite de flujo completo en el lado del servidor, y casi no hay caso de límite de flujo parcial.
4. Prueba de límites
◦Mediante la simulación de varias condiciones de contorno, se probó el sistema para verificar la estabilidad y confiabilidad de RALB.
5. Función lanzada
◦ El modo de equilibrio de carga RALB está completamente habilitado en todos los clústeres del lado del servidor. Se puede ver que antes y después del lanzamiento, el QPS en el lado del servidor se estratifica gradualmente y la CPU en el lado del servidor tiende gradualmente a unificarse.
2. Introducción a RALB
RALB es un algoritmo de equilibrio de carga de alto rendimiento que tiene como objetivo el equilibrio de la CPU.
2.1 Objetivos del algoritmo
1. Ajuste el uso de la CPU en el lado del servidor, de modo que las CPU de cada nodo estén relativamente equilibradas y evite la limitación actual del clúster provocada por un uso excesivo de la CPU.
2. QPS tiene una relación lineal con el uso de la CPU, y el ajuste de QPS puede lograr el objetivo de un uso equilibrado de la CPU
2.2 Principio del algoritmo
2.2.1 Pasos del algoritmo
1. Al asignar el tráfico, distribuir según el peso (algoritmo aleatorio con peso, wr)
2. Recopilar el uso de la CPU: el servidor retroalimenta el uso de la CPU (promedio de 1) al cliente a través de RPC
3. Ajuste de peso: ajuste el peso regularmente (cada 3 s) de acuerdo con el uso de la CPU (valor promedio en la ventana) del clúster y cada nodo para equilibrar la CPU de cada nodo
2.2.2 Dependencia del índice
| número de serie | índice | efecto | fuente |
|---|---|---|---|
| 1 | IP | Lista de IP disponibles | Módulos de detección de registro de servicios y enmascaramiento de fallas para mantenimiento |
| 2 | salud en tiempo real | El estado de disponibilidad de IP cambia en tiempo real, proporcionando las condiciones límite del algoritmo | Mantenimiento de la función de verificación de estado del marco RPC |
| 3 | Salud historica | Valor del historial de salud, utilizado para juzgar las condiciones de contorno, como fallas y recuperación de ip | Valor histórico del indicador 2 |
| 4 | Objetivo dinámico (uso de CPU) | Proporcione la base objetivo más directa para el algoritmo de ecualización | Estadísticas de tiempo del lado del servidor, el marco RPC regresa a través de RPC |
| 5 | peso de peso | Distribución de carga en tiempo real basada en | actualización del algoritmo |
2.2.3 Algoritmo de ajuste de peso
2.2.4 Procesamiento de límites
Límite 1: dentro de la ventana de retroalimentación (3 s), si no se accede a la IP descendente, su valor de CPU promedio es 0 y el algoritmo de ajuste de peso considerará que el nodo tiene un rendimiento excelente, lo que aumenta el peso
Límite 2: cuando falla la red, el marco RPC establece el nodo fallido como no disponible y la CPU y el peso son 0; después de restaurar la red, el marco RPC establece la IP como disponible, pero el nodo con peso 0 no puede compartir el tráfico, lo que resultará en que el nodo permanecerá no disponible
Procesamiento: la actualización del peso se activa mediante un temporizador y se registra el estado disponible del nodo. Cuando el nodo se recupera de no disponible a disponible, se asigna un peso bajo para recuperarse gradualmente.
2.3 La clave para aterrizar
Sea rápido y constante, evite estancamientos y avalanchas en cualquier situación y, especialmente, maneje las condiciones límite
Puntos del algoritmo:
1. La actualización de cada factor dependiente en la fórmula mantiene un significado independiente y un mecanismo de actualización para mantener la confiabilidad y simplicidad del algoritmo.
◦La actualización de la lista de IP está garantizada conjuntamente por el descubrimiento de registro de servicios y el marco RPC
◦ CPU de actualización de RPC
2. Preste atención al significado del valor límite, que debe distinguir valores continuos
◦CPU = 0, significa desconocido, no significa buen rendimiento de la CPU
◦w = 0, lo que significa que no se asignará tráfico, y será 0 solo cuando no esté disponible; si está disponible, debe haber al menos un valor más pequeño para garantizar que aún se pueda activar RPC, y luego el peso se puede actualizar
3. Peso de actualización del algoritmo, no confíe en el disparador RPC, pero debe actualizarse regularmente
3. Verificación de funciones
3.1 Preparación de la prueba de presión
| Módulo | IP | UPC |
|---|---|---|
| Cliente | 10.173.102.36 | 8 |
| lado del servidor | 11.17.80.238 | 8 |
| 11.18.159.191 | 8 | |
| 11.17.191.137 | 8 |
3.2 Datos de medición de presión
| índice | Equilibrio de carga de RR | Equilibrio de carga RALB |
|---|---|---|
| SWC | ||
| UPC | **** |
|
| TP99 |
Debido a la pequeña diferencia en el rendimiento de la máquina, el efecto de la prueba de presión en la CPU no es evidente. Para que el efecto de la CPU sea más evidente, se aplica una carga inicial al nodo "11.17.80.238" (es decir, cuando hay sin tráfico, la tasa de uso de la CPU es del 12,5 %)
| índice | Equilibrio de carga LA | Equilibrio de carga de RR | Equilibrio de carga RALB |
|---|---|---|---|
| SWC | |||
| UPC | |||
| TP99 |
3.3 Conclusión de la prueba de presión
Después de la prueba de presión, tanto RR como LA tienen el problema del desequilibrio de la CPU, lo que provocará un efecto de tablero corto debido a la diferencia de rendimiento de los recursos de la máquina y no logrará el propósito de utilizar los recursos por completo.
RALB utiliza la CPU como objetivo de equilibrio, por lo que ajustará el QPS realizado por el nodo en tiempo real de acuerdo con la CPU del nodo y luego logrará el objetivo del equilibrio de la CPU. La verificación funcional está disponible y el rendimiento de la CPU cumple Expectativas.
4. Prueba de rendimiento
4.1 Objetivo de medición de presión
RALB es un algoritmo de equilibrio de carga que utiliza el uso de la CPU como un indicador dinámico. Puede resolver el problema del desequilibrio de la CPU, evitar el efecto de cortocircuito de la CPU y permitir que las máquinas con buen rendimiento manejen más tráfico. Por lo tanto, esperamos que la estrategia de balanceo de carga RALB pueda lograr un cierto grado de mejora en el rendimiento en comparación con la estrategia de sondeo RR.
4.2 Preparación de la prueba de presión
Hay 100 máquinas en el lado del servidor para realizar pruebas, y el lado del servidor usa una limitación de corriente adaptable de CPU pura, y el umbral de limitación actual se establece en 55 %.
4.3 Datos de medición de presión
A través de pruebas de presión en los dos modos de equilibrio de carga de RALB y RR, el rendimiento del lado del servidor cambia con la tendencia del tráfico y compara el impacto de las dos estrategias de equilibrio de carga en el rendimiento del clúster.
4.3.1 RALB
4.3.1.1 Datos de rendimiento
La siguiente tabla son los datos de rendimiento del lado del servidor, que la prueba envía al lado del cliente, y el modo de equilibrio de carga se establece en RALB. A las 18:17, la situación en el lado del servidor estaba cerca del límite actual en este momento. Durante toda la fase de prueba de estrés, se probaron tres situaciones de flujo sin restricción, restricción de flujo parcial y restricción de flujo total.
| tiempo | 17:40 | 17:45 | 17:52 | 18:17 | 18:22 |
|---|---|---|---|---|---|
| flujo total | 2270 | 1715 | 1152 | 1096 | 973 |
| manejar el tráfico | 982 | 1010 | 1049 | 1061 | 973 |
| tráfico limitado | 1288 | 705 | 103 | 35 | 0 |
| Relación de limitación actual | 56,74% | 41% | 8,9% | 3,2% | 0% |
| Uso promedio de la CPU | 55% | 55% | 54% | 54% | 49% |
4.3.1.2 Monitoreo de Indicadores
El tráfico recibido por la máquina del lado del servidor se distribuye según el rendimiento y la CPU permanece equilibrada.
| SWC | UPC |
|---|---|
4.3.2 RR
4.3.2.1 Datos de rendimiento
La siguiente tabla son los datos de rendimiento del lado del servidor, que la prueba envía al lado del cliente, y el modo de equilibrio de carga se establece en RR. El tráfico general del lado del servidor a las 18:46 está cerca del tráfico general del lado del servidor a las 18:17. Lo siguiente se centrará en comparar los datos en estos dos momentos críticos.
| tiempo | 18:40 | 18:46 | 19:57 | 20:02 | 20:04 | 20:09 |
|---|---|---|---|---|---|---|
| flujo total | 967 | 1082 | 1149 | 1172 | 1263 | 1314 |
| manejar el tráfico | 927 | 991 | 1024 | 1036 | 1048 | 1047 |
| tráfico limitado | 40 | 91 | 125 | 136 | 216 | 267 |
| Relación de limitación actual | 4,18% | 8,4% | 10,92% | 11,6% | 17,1% | 20,32% |
| Uso promedio de la 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端进程，流量分配符合预期 |
六、功能上线
宿迁机房Client端上线配置，在所有Server端集群全面开启RALB负载均衡模式。可以看出，上线前后，Server端的QPS逐渐出现分层，Server端的CPU逐渐趋于统一。
| 上线前后Server端QPS分布 | 上线前后Server端的CPU分布 |
|---|---|
参考资料
1.负载均衡技术
2.深入浅出负载均衡
作者：京东零售 胡沛栋
来源：京东云开发者社区