负载均衡算法完全指南：从轮询到一致性哈希

什么是负载均衡

负载均衡（Load Balancing）是指将客户端请求按照某种策略分发到多个后端服务节点，目标是：

• 避免单点过载：防止某一节点 CPU/内存耗尽
• 提升整体吞吐：充分利用集群资源
• 容灾与高可用：节点故障时自动剔除，流量转移

负载均衡分为两大类：静态算法（不考虑节点实时状态）和动态算法（根据节点当前负载调度）。

静态负载均衡算法

1. 轮询（Round Robin）

最简单的算法：请求依次分发给每个节点，循环往复。

请求序列: 1  2  3  4  5  6
节点:     A  B  C  A  B  C

优点：实现简单，分布均匀（假设节点同质）
缺点：不考虑节点性能差异和请求处理时长

Nginx 配置：

upstream backend {
    server 192.168.1.10;
    server 192.168.1.11;
    server 192.168.1.12;
    # 默认就是轮询
}

2. 随机（Random）

每次请求随机选择一个节点。大量请求下，统计上接近均匀分布。

优点：无状态，实现最简
缺点：小请求量时分布不均

3. 加权轮询（Weighted Round Robin）

根据节点处理能力分配权重，权重越高分得请求越多。

节点 A: weight=3, 节点 B: weight=1, 节点 C: weight=2
请求分配: A A A B C C A A A B C C ...

适用场景：集群中机器配置不均等（高配机器分更多流量）

upstream backend {
    server 192.168.1.10 weight=3;
    server 192.168.1.11 weight=1;
    server 192.168.1.12 weight=2;
}

weight=3:1:2 的实际请求分配比例：

4. IP Hash

对客户端 IP 取哈希，映射到固定节点。同一 IP 的请求始终路由到同一后端。

hash(client_ip) % server_count = 目标节点索引

优点：天然实现会话保持（Session Sticky），无需额外 Session 共享
缺点：节点增减时映射变化，大量 Session 失效；NAT 场景下多用户共享 IP 导致负载不均

upstream backend {
    ip_hash;
    server 192.168.1.10;
    server 192.168.1.11;
}

5. URL Hash

对请求 URL 取哈希，相同 URL 路由到同一节点。

适用场景：缓存服务器集群——同一资源固定落在同一节点，提升缓存命中率
缺点：热点 URL 可能导致某节点过载

upstream backend {
    hash $request_uri consistent;
    server 192.168.1.10;
    server 192.168.1.11;
}

6. 一致性哈希（Consistent Hashing）

普通哈希的问题：增减节点时，hash(key) % N 的 N 变化，几乎所有 key 都需要重新映射。

一致性哈希将所有节点和 key 映射到同一个圆环（0 ~ 2³²），key 顺时针找到的第一个节点即为目标节点。

          0
    ┌─────┼─────┐
  A(90°)  │   C(270°)
          │
        B(180°)

key_hash=120° → 顺时针 → C(270°)
key_hash=200° → 顺时针 → C(270°)
key_hash=300° → 顺时针 → A(90° + 360°)

优点：增减节点时只影响相邻区间，平均只有 1/N 的 key 需要迁移
缺点：节点少时容易分布不均；引入虚拟节点（每个物理节点映射多个点）可解决

动态负载均衡算法

7. 最少连接（Least Connections）

将新请求发送给当前活跃连接数最少的节点。

节点 A: 活跃连接 100  → 不选
节点 B: 活跃连接 20   → 选择
节点 C: 活跃连接 55   → 不选

优点：自适应节点处理能力，长连接场景效果好（如 WebSocket）
缺点：需要维护连接计数，有一定开销

upstream backend {
    least_conn;
    server 192.168.1.10;
    server 192.168.1.11;
}

8. 加权最少连接（Weighted Least Connections）

综合权重和当前连接数：score = connections / weight，选 score 最小的节点。

9. 最快响应时间（Fastest Response）

选择近期平均响应时间最短的节点。需要负载均衡器持续采集各节点的响应时间。

适用场景：节点间网络延迟差异大（如多机房混合部署）

10. 预测（Predictive）

基于历史响应时间和当前趋势预测节点下一时刻的负载，选择预测负载最低的节点。

F5 BIG-IP 等商用产品支持此算法。

11. QoS 感知调度

根据请求的服务等级（优先级）调度，高优先级请求优先发送到性能最好的节点。多用于混合业务场景（在线请求 vs 批处理任务）。

高级策略

灰度发布（Canary Release）

通过权重或请求头将少量流量（1%~10%）路由到新版本节点，验证无误后逐步扩大。

upstream backend {
    server prod.example.com  weight=9;
    server canary.example.com weight=1;
}

版本隔离

按请求头（如 X-Version）或 Cookie 将特定用户路由到指定版本，实现 AB 测试或内测。

故障隔离（Circuit Breaker）

节点连续失败超过阈值后，临时从轮询中摘除，避免雪崩。常与健康检查配合使用。

主流框架支持对比

⚠️ Netflix Ribbon 已于 2021 年进入维护模式，Spring Cloud 2020+ 默认切换为 Spring Cloud LoadBalancer。新项目不建议继续使用 Ribbon。

三大框架算法支持对比：

注：条形高度表示支持程度：满格=支持，半格=需自定义，空=不支持。

选型建议