Nginx upstream负载均衡算法配置与主动健康检查实战

Nginx作为高性能反向代理服务器，其upstream模块提供了多种负载均衡算法和后端健康检查机制。在实际生产环境中，合理配置负载均衡策略和健康检查参数，直接关系到服务器集群的可用性和请求分发效率。本文从Nginx upstream负载均衡的核心算法入手，结合主动健康检查模块的部署实践，给出完整的配置方案和故障排查路径。

Nginx upstream负载均衡算法对比与选型

Nginx原生支持四种负载均衡算法：轮询（Round Robin）、最少连接（Least Connections）、IP哈希（IP Hash）和通用哈希（Generic Hash）。

# 轮询（默认）
upstream backend_rr {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# 最少连接数
upstream backend_lc {
    least_conn;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# IP哈希（会话保持）
upstream backend_ihash {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# 通用哈希（可自定义哈希key）
upstream backend_ghash {
    hash $request_uri consistent;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

轮询算法按服务器列表顺序逐个分发请求，适用于后端服务器性能均等的场景。最少连接算法将请求分发到当前活动连接数最少的服务器，适合长连接应用如WebSocket。IP哈希通过对客户端IP计算哈希值固定到某台后端服务器，实现会话保持，但存在节点增减时哈希重分布问题。通用哈希配合consistent参数使用一致性哈希环，节点变动时只影响相邻区间的请求，适合缓存场景。

权重配置与慢启动参数详解

当后端服务器硬件配置不一致时，通过weight参数调节分配比例。Nginx 1.11.5引入了slow_start参数，新加入或恢复的服务器在指定时间内逐步增加权重，避免瞬时流量冲击。

upstream backend_weighted {
    # 高配服务器权重5
    server 192.168.1.10:8080 weight=5;
    # 中配服务器权重3
    server 192.168.1.11:8080 weight=3 slow_start=30s;
    # 低配服务器权重1
    server 192.168.1.12:8080 weight=1 slow_start=30s;
}

weight参数控制请求分配比例，5:3:1的配置意味着每9个请求中，10号服务器分到5个、11号分到3个、12号分到1个。slow_start仅在backup和down状态的节点恢复时生效，需要配合健康检查使用。

被动健康检查机制与故障阈值配置

Nginx原生的健康检查属于被动检查：当请求转发到某台后端服务器返回错误时，Nginx标记该服务器为不可用，并在一段时间后重试。

upstream backend_passive {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 max_fails=3 fail_timeout=30s backup;
}

max_fails指定在fail_timeout时间窗口内允许的最大失败次数。超过该次数后，服务器被标记为不可用，持续fail_timeout秒后再次纳入分配。proxy_next_upstream指令控制哪些错误触发请求重试：

location /api {
    proxy_pass http://backend_passive;
    proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;
}

max_fails=0表示禁用被动检查。backup参数标记服务器为备用节点，仅在所有主节点不可用时才接收请求。

主动健康检查模块nginx_upstream_check_module部署

被动检查的局限在于：只有在请求到达时才能发现后端故障，存在一个请求被浪费的窗口期。主动健康检查通过定期探测后端服务器状态，在故障发生时立即将节点摘除。

nginx_upstream_check_module是淘宝开源的第三方模块，需要在编译Nginx时静态集成：

# 编译集成
cd /usr/local/src
git clone https://github.com/yaoweibin/nginx_upstream_check_module.git
cd nginx-1.24.0
patch -p1 < /usr/local/src/nginx_upstream_check_module/check_1.20.1+.patch
./configure --add-module=/usr/local/src/nginx_upstream_check_module
make && make install

配置主动健康检查：

upstream backend_active {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;

    # 主动健康检查配置
    check interval=3000 rise=2 fall=3 timeout=2000 type=http;
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

# 健康状态查询接口
server {
    listen 8081;
    location /status {
        check_status;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}

interval=3000表示每3秒检查一次，rise=2表示连续2次成功后标记为健康，fall=3表示连续3次失败后标记为不可用。type支持tcp、http、ssl_hello、ajp四种协议。

负载均衡会话保持与一致性哈希实战

对于需要会话保持的应用，IP Hash存在客户端IP变化导致会话丢失的问题。更可靠的方案是基于Cookie或Header的一致性哈希：

# 基于Cookie的会话保持
upstream backend_sticky {
    hash $cookie_session_id consistent;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

# 基于自定义Header的会话保持
upstream backend_hdr {
    hash $http_x_user_id consistent;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

一致性哈希的虚拟节点数量通过参数控制，默认160。虚拟节点越多，请求分布越均匀，但内存开销也越大。当节点数少于10台时，建议保持默认值；超过50台时可降至100以减少内存占用。

连接超时与长连接保活参数调优

Nginx到后端服务器的连接管理是性能调优的重点。以下参数控制连接的生命周期：

upstream backend_keepalive {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;

    keepalive 32;           # 保持32个空闲长连接
    keepalive_timeout 60s;  # 空闲连接超时时间
    keepalive_requests 1000; # 单个连接最大请求数
}

location /api {
    proxy_pass http://backend_keepalive;
    proxy_http_version 1.1;
    proxy_set_header Connection "";  # 清除Connection头以启用长连接
    proxy_connect_timeout 3s;        # 连接建立超时
    proxy_send_timeout 30s;          # 发送请求超时
    proxy_read_timeout 30s;          # 读取响应超时
}

keepalive 32表示Nginx为每个worker进程维护最多32个到后端服务器的空闲长连接。proxy_http_version必须设为1.1才能启用长连接。proxy_set_header Connection ""用于清除客户端传递的Connection: close头，防止连接被提前关闭。keepalive_requests设为1000可以避免连接因长时间复用导致的内存泄漏累积。