Nginx 负载均衡详解

下面是一份真正生产可用、体系化、可直接落地的《Nginx 负载均衡详解》，从基础 -> 机制 -> 算法 -> 健康检查 -> 会话保持 -> 性能优化 -> 实战配置，全部覆盖。

Nginx 的负载均衡由 upstream 模块驱动，用于把客户端请求分发到后端多个服务节点（upstream servers）。

1. 负载均衡的基本结构

http {
    upstream backend {
        server 10.0.0.1;
        server 10.0.0.2;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

2. Nginx 负载均衡算法（4 个核心 + 2 个增强）

2.1 round_robin（默认）

轮询：

upstream backend {
    server 10.0.0.1;
    server 10.0.0.2;
}

适合：后端性能一致、无 session 场景。

2.2 weight（权重）

按性能分配负载：

upstream backend {
    server 10.0.0.1 weight=5;
    server 10.0.0.2 weight=1;
}

CPU 强的给更多 weight。

2.3 ip_hash（按客户端 IP 粘性会话）

同一 IP 永远访问同一后端：

upstream backend {
    ip_hash;
    server 10.0.0.1;
    server 10.0.0.2;
}

适合：后端有 session 但不支持共享。

不适合：移动网络用户（IP 变动频繁）。

2.4 least_conn（最少连接）

把请求给当前连接数最少的节点：

upstream backend {
    least_conn;
    server 10.0.0.1;
    server 10.0.0.2;
}

适合：请求处理时间差异大。

2.5 hash（自定义 key，一致性哈希）

（需要 nginx hash module）

upstream backend {
    hash $request_uri consistent;
    server 10.0.0.1;
    server 10.0.0.2;
}

适用于：

内容缓存
文件上传切片
A/B 测试精准路由

2.6 least_time（第三方模块）

按响应时间最短的服务分配（更智能）。

3. 后端服务器配置参数（生产必备）

3.1 max_fails + fail_timeout（失败重试）

server 10.0.0.1 max_fails=3 fail_timeout=30s;

含义：

30 秒内失败 3 次 -> 认为该节点 down
不再转发，直到 fail_timeout 到期

3.2 backup（备用节点）

upstream backend {
    server 10.0.0.1;
    server 10.0.0.2 backup;  # 只有主都挂掉才用它
}

用于：灾备 / 灾难切换

3.3 down（临时下线某个节点）

server 10.0.0.3 down;

4. 健康检查（active + passive）

Nginx 开源版：只有被动检查（passive health check）

商业版（Plus）：主动检查（active health check）

被动健康检查（免费版）

依赖 upstream 参数：

max_fails
fail_timeout

一旦请求失败（超时、非 200），Nginx 会自动标记不健康。

主动健康检查（使用第三方模块）

使用 nginx_upstream_check_module：

check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "GET /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;

5. 会话保持（Sticky Session）

方法 1: ip_hash

简单，但不靠谱（移动 IP 不稳定）。

方法 2: sticky 模块（更专业）

upstream backend {
    sticky cookie srv_id expires=1h path=/;
    server 10.0.0.1;
    server 10.0.0.2;
}

客户端带 cookie，每次打到同一后端。

适用于：登录状态、购物车。

方法 3. 自行共享 session（最推荐）

Redis Session
JWT
数据库存储

-> Nginx 负载均衡就可以随便换算法。

6. Nginx 负载均衡 + Keepalive（提高性能）

减少后端连接损耗：

upstream backend {
    server 127.0.0.1:9001;
    server 127.0.0.1:9002;

    keepalive 32;
}

适合：有大量短连接的 API 服务

7）负载均衡 + 超时设置（避免雪崩）

在 location 中：

proxy_connect_timeout   3s;
proxy_send_timeout      30s;
proxy_read_timeout      30s;

proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;

可自动重试下一个节点，避免单节点卡死导致系统雪崩。

8. 负载均衡架构设计模式

单层 LB

客户端 -> Nginx -> 后端

适用于小规模服务。

双层 LB（企业推荐）

外层：DNS 轮询 / Cloud LB
内层：Nginx upstream 负载均衡

优点：

避免单点故障
全球加速
更好的可扩展性

动态注册（自动发现）

使用 consul + consul-template
或 OpenResty + Lua 做自动更新上游节点。

9. 生产级完整示例（可直接复制）

轮询 + 健康检查 + 超时 + keepalive

upstream backend {
    least_conn;

    server 10.0.0.1 max_fails=3 fail_timeout=30s;
    server 10.0.0.2 max_fails=3 fail_timeout=30s;

    keepalive 50;
}

server {
    listen 80;

    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://backend;

        proxy_connect_timeout   3s;
        proxy_send_timeout      30s;
        proxy_read_timeout      30s;

        proxy_next_upstream         error timeout http_500 http_502 http_503 http_504;
        proxy_next_upstream_tries   3;
    }
}

这是大部分公司生产环境直接采用的最佳组合。

10. 不同场景最佳选择

场景	推荐算法	原因
普通网站、微服务 API	least_conn	动态均衡最好
上传下载服务	hash $request_uri	一致性哈希避免断点
内容分发、缓存系统	hash	精准路由
后端性能不一致	weight	按性能分配
有 session 且不共享	sticky	强制绑定
移动用户大量变 IP	❌ 不推荐 ip_hash	粘性不可靠
不想管 session	JWT / Redis	最稳定