常见的负载均衡算法

常见的负载均衡算法

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

负载均衡算法可部署在多种层级中，如七层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保持用户登录状态绑定特定应用节点。

表格对比

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

小结

负载均衡算法是实现水平扩展与流量调度的基础组件，选择合适的算法能显著提升系统稳定性与资源利用率。在微服务、容器平台与云原生架构中，还可结合服务网格实现自定义的调度策略。