常见的负载均衡算法

在实现水平扩展过程中，负载均衡算法是决定请求如何在多个服务实例间分配的核心逻辑。一个合理的负载均衡策略能够有效分散系统压力，提升系统吞吐能力与稳定性。

负载均衡算法可部署在多种层级中，如七层HTTP反向代理（Nginx、Envoy）、四层TCP网关（LVS、HAProxy）或服务网格控制面（如Istio Pilot），其本质都是决定“某个用户请求分配给哪个后端实例”。

本节将介绍工程中常用的五种负载均衡算法，并分析其优劣与应用场景。

1. 轮询（Round Robin）

轮询算法是最简单且最常用的一种策略。它将每个请求按照顺序轮流分配给后端服务器，一轮分配完再从头开始。

实现原理：维护一个指针，每次请求到达后，该指针指向下一个实例。

适用场景：

实例处理能力相对一致；
请求处理时间差异不大；
无需考虑服务器负载差异。

优点：

实现简单；
分配公平；
容易排查与调试。

缺点：

无法识别后端实例负载；
对高并发突发请求响应不敏感。

实际案例：Nginx 默认使用轮询算法将用户请求均匀地分配到多个后端API服务。

2. 加权轮询（Weighted Round Robin）

加权轮询是在普通轮询的基础上，为不同的后端服务器设置权重，高性能服务器分配更多请求，低性能服务器分配较少。

实现原理：维护一个“当前权重表”，根据预设权重比例顺序分配请求。

适用场景：

多节点硬件性能差异明显；
后端实例资源分配不均。

优点：

合理利用资源；
避免弱实例过载；
简化容量规划。

缺点：

动态权重调整不够灵活；
不适合实时变动的场景。

实际案例：某AI模型推理服务集群中，GPU实例设为权重3，CPU实例设为权重1，以保证推理服务优先走高性能GPU节点。

3. 最少连接数（Least Connections）

该算法实时监控各实例的连接数，优先将请求分配给当前连接数最少的节点，适用于请求处理时长不确定的情况。

实现原理：每个请求到达时，调度器检查所有实例当前活跃连接数，选择最少者。

适用场景：

后端任务执行时间波动大；
数据库代理、AI推理任务等。

优点：

动态负载感知；
更智能的资源分配；
提高服务响应稳定性。

缺点：

需维护连接状态；
状态同步复杂，分布式中需引入共享状态存储。

实际案例：在 Redis Cluster 的 Proxy 层中，使用最少连接数策略实现写请求的均衡调度，有效降低单节点压力。

4. 一致性哈希（Consistent Hashing）

一致性哈希将请求按特征（如用户ID、订单号等）哈希映射到特定实例，确保同一用户或会话尽可能落在同一节点上，从而减少缓存穿透、提升数据局部性。

实现原理：构建一个虚拟哈希环，服务器节点和请求都映射到该环上，请求路由到其顺时针最近的节点。

适用场景：

高并发缓存系统（如分布式Redis）；
用户态状态存储（如购物车、会话等）。

优点：

提升命中率；
降低跨节点通信；
新增或剔除节点时影响范围小。

缺点：

实现复杂；
对负载均衡精度要求高时需引入虚拟节点。

实际案例：在某大型直播平台中，主播用户ID通过一致性哈希映射到固定流媒体服务器，避免直播状态频繁迁移。

5. 源地址哈希（IP Hash）

源地址哈希根据请求的IP地址进行哈希后分配到特定后端，实现用户请求固定落点（sticky session）。

实现原理：对客户端IP做hash，结果与节点数取模决定目标服务器。

适用场景：

需保持用户粘性；
简单状态保持（如token验证前的用户预热流程）。

优点：

实现简单；
可保持用户连接稳定性。

缺点：

某些IP集中度高可能导致单点过载；
不适合代理层IP复用的场景。

实际案例：传统BBS论坛在未使用Redis缓存时，采用IP Hash保持用户登录状态绑定特定应用节点。

表格对比

下表总结了几种负载均衡算法的核心对比：

算法类型	是否感知负载	是否支持权重	是否保持会话	应用场景
轮询	否	否	否	请求时间均衡，实例性能一致
加权轮询	否	是	否	节点性能差异，轻负载分配
最少连接数	是	否	否	请求时间不确定，服务异构场景
一致性哈希	是（隐式）	是（需设计）	是	高命中缓存、状态绑定型服务
源地址哈希	否	否	是	轻量级会话保持，简单状态追踪