Nginx负载均衡策略

一、引言：为什么需要多种负载均衡策略？

当你的应用从单机走向集群，Nginx 的 upstream 模块就成了流量调度的核心。但"一刀切"的分发方式并不总是最优解。

你的服务器硬件配置参差不齐？
你的应用需要会话保持（Session Sticky）？
你的请求处理时间长短不一？
你希望在增减节点时，对现有连接的影响最小？

面对这些不同的场景，Nginx 提供了多种负载均衡策略。选择合适的策略，能让集群资源利用更充分、用户体验更流畅、系统架构更健壮。本文将为你逐一拆解这五大核心策略。

💡 核心价值 ：
理解并善用不同策略，是区分普通使用者和高级架构师的关键一步！

二、基石：`upstream` 模块与 `server` 参数

在深入策略之前，先回顾 upstream 的基本构成。

复制代码

upstream backend {
    server 192.168.1.10:8080 [parameters];
    server 192.168.1.11:8080 [parameters];
}

`server` 指令常用参数

参数	作用
`weight=number`	服务器权重，默认为1。权重越高，接收请求越多。
`max_fails=number`	在 `fail_timeout` 时间内，允许请求失败的最大次数。默认为1。
`fail_timeout=time`	服务器被判定为不可用后的暂停服务时间。默认为10秒。
`backup`	标记为备份服务器，仅在其他服务器都宕机时启用。
`down`	手动标记服务器为永久不可用（用于维护）。

三、五大核心负载均衡策略详解

策略一：轮询（Round Robin） - 默认策略

原理：最简单的公平调度。Nginx 按照顺序，将每个新请求依次分配给服务器列表中的下一台服务器。

配置：

复制代码

upstream myapp {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

适用场景：所有后端服务器性能相近，且无状态（Stateless）的应用。这是最通用、开销最小的策略。

策略二：加权轮询（Weighted Round Robin）

原理：轮询的升级版。通过 weight 参数，让性能更强的服务器承担更多流量。

配置：

复制代码

upstream myapp {
    server 192.168.1.10:8080 weight=5; # 高配服务器
    server 192.168.1.11:8080 weight=2; # 中配服务器
    server 192.168.1.12:8080 weight=1; # 低配或旧服务器
}

效果：每8个请求中，5个去Server1，2个去Server2，1个去Server3。
适用场景：后端服务器硬件配置不均，或你想逐步灰度上线新版本服务器。

策略三：IP哈希（IP Hash）

原理：根据客户端的 IP 地址进行哈希计算，确保同一个 IP 的请求始终被转发到同一台后端服务器。

配置：

复制代码

upstream myapp {
    ip_hash; # 启用IP哈希
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

优点：天然实现会话保持，无需共享 Session 存储。
缺点：

如果客户端都在同一个 NAT 网关后（如公司网络），Nginx 看到的都是同一个公网 IP，会导致所有流量都打到一台服务器上，失去负载均衡意义。
当后端服务器数量发生变化时，几乎所有客户端的 IP 映射关系都会改变，导致会话丢失。

适用场景：无法使用 Redis 等集中式 Session 存储，且客户端 IP 分布较广的内部系统。

策略四：最少连接（Least Connections）

原理：Nginx 会将新请求分配给当前活跃连接数最少的服务器。它假设连接数少的服务器当前负载更低。

配置：

复制代码

upstream myapp {
    least_conn; # 启用最少连接
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

适用场景：后端请求处理时间差异很大（例如，有些请求是简单的读操作，有些是复杂的报表生成）。此策略能更公平地分配负载。

策略五：通用哈希 / 一致性哈希（Hash / Consistent Hash）

注意：此策略在开源版 Nginx 中需要 ngx_http_upstream_hash_module 模块支持（通常已编译进主流发行版）。

原理：

通用哈希 (hash) ：基于指定的键（如 $request_uri, $cookie_jsessionid）进行哈希，将相同键的请求固定到同一台服务器。
一致性哈希 (hash ... consistent)：在通用哈希基础上，采用一致性哈希算法。当增减节点时，能最大程度地减少已有键的重新映射，对缓存系统尤其友好。

配置：

复制代码

# 基于请求URI的通用哈希
upstream myapp {
    hash $request_uri;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

# 基于Cookie的一致性哈希（推荐用于缓存）
upstream cache_backend {
    hash $cookie_user_id consistent;
    server 192.168.1.10:11211; # Memcached
    server 192.168.1.11:11211;
}

适用场景：

通用哈希：需要基于特定业务键（如用户ID、文件名）做路由。
一致性哈希：后端是缓存集群（如 Memcached, Redis），希望在扩容/缩容时，缓存失效的比例最小化。

四、生产级配置最佳实践

一个完整的、可用于生产的负载均衡配置，除了选择策略，还需考虑健康检查和超时。

复制代码

upstream production_backend {
    # 选用加权轮询
    server app-server-01:8080 weight=3 max_fails=2 fail_timeout=30s;
    server app-server-02:8080 weight=3 max_fails=2 fail_timeout=30s;
    server app-server-03:8080 weight=1 max_fails=2 fail_timeout=30s backup;

    # 如果是缓存，可选用一致性哈希
    # hash $request_uri consistent;
}

server {
    listen 80;
    server_name api.yourcompany.com;

    location / {
        proxy_pass http://production_backend;
        
        # 必须传递的请求头
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # 超时设置
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 10s;
    }
}

五、如何选择正确的策略？

你的需求	推荐策略
通用场景，服务器同质	轮询 (Round Robin)
服务器性能不同	加权轮询 (Weighted Round Robin)
需要会话保持，且无集中式Session	IP哈希 (IP Hash) 或通用哈希 (Hash)
请求处理时间差异大	最少连接 (Least Connections)
后端是缓存集群，需平滑扩缩容	一致性哈希 (Consistent Hash)

六、结语

感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！

Nginx负载均衡策略

一、引言：为什么需要多种负载均衡策略？

二、基石：upstream 模块与 server 参数

server 指令常用参数

三、五大核心负载均衡策略详解

策略一：轮询（Round Robin） - 默认策略

策略二：加权轮询（Weighted Round Robin）

策略三：IP哈希（IP Hash）

策略四：最少连接（Least Connections）

策略五：通用哈希 / 一致性哈希（Hash / Consistent Hash）

四、生产级配置最佳实践

五、如何选择正确的策略？

六、结语

二、基石：`upstream` 模块与 `server` 参数

`server` 指令常用参数