Nginx负载均衡配置实战：权重分配与健康检查机制

Nginx负载均衡是服务器运维中实现高可用架构的关键组件。通过将请求分发到多台后端服务器，Nginx负载均衡不仅提升系统吞吐量，还能在单节点故障时自动剔除异常节点，保障业务连续性。在物理机架设和云服务器选型场景中，合理的负载均衡配置直接影响系统的并发处理能力和稳定性。

Nginx负载均衡基础配置与upstream模块

Nginx通过upstream指令定义后端服务器组，再通过proxy_pass将请求转发到该组。最基础的配置只需指定服务器地址列表：

http {
    upstream backend {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
        server 192.168.1.12:8080;
    }
    
    server {
        listen 80;
        server_name api.example.com;
        
        location / {
            proxy_pass http://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;
        }
    }
}

默认采用轮询（round-robin）策略，请求按顺序依次分配到各后端服务器。配置后通过 nginx -t 验证语法，nginx -s reload 热加载生效。

负载均衡算法选择与权重分配策略

Nginx内置三种负载均衡算法，适用于不同场景：

# 1. 加权轮询 - 后端服务器性能不均时使用
upstream backend {
    server 192.168.1.10:8080 weight=3;  # 性能强，分配更多请求
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;  # 性能弱，分配少量请求
}

# 2. IP哈希 - 需要会话保持时使用
upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

# 3. 最少连接 - 长连接场景优先
upstream backend {
    least_conn;
    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;
}

ip_hash根据客户端IP哈希值分配服务器，同一客户端的请求始终落到同一后端节点，适合有session状态的应用。但IP哈希在后端节点变更时会导致大量请求重新映射，且在CDN或NAT环境下效果不佳。least_conn将请求分配到当前活跃连接数最少的服务器，适合请求处理时间差异较大的场景。

主动健康检查机制配置

Nginx开源版支持被动健康检查，通过max_fails和fail_timeout参数实现。当某台服务器在fail_timeout时间内连续失败max_fails次，Nginx会临时将其从负载均衡池中移除。

upstream backend {
    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 backup;  # 备用服务器，仅当其他全部不可用时启用
}

被动检查的局限在于无法感知服务”假活”状态——进程存在但无法正常响应。生产环境建议使用Nginx Plus的主动健康检查，或通过nginx_upstream_check_module第三方模块实现：

# 使用第三方模块实现主动健康检查
upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11: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;
}

interval=3000表示每3秒检查一次，rise=2表示连续2次成功后标记为可用，fall=3表示连续3次失败后标记为不可用。

会话保持与SSL卸载配置

除了ip_hash，还可以通过sticky cookie实现更精确的会话保持：

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    sticky cookie srv_id expires=1h domain=.example.com httponly secure path=/;
}

SSL卸载将HTTPS解密在Nginx层完成，后端服务器仅处理HTTP请求，降低后端CPU开销：

server {
    listen 443 ssl;
    server_name api.example.com;
    
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    
    location / {
        proxy_pass http://backend;
    }
}

Nginx负载均衡性能调优参数

高并发场景下需要调整worker进程和连接数参数。worker_processes设为auto可自动匹配CPU核心数，worker_connections控制单个worker的最大连接数。对于负载均衡专用节点，建议worker_connections设为10240以上。

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 10240;
    use epoll;  # Linux系统使用epoll事件模型
    multi_accept on;  # 一次接受所有新连接
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    keepalive_requests 1000;
    
    # upstream长连接
    upstream backend {
        server 192.168.1.10:8080;
        keepalive 32;  # 保持32个到后端的长连接
    }
    
    server {
        location / {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";  # 清除Connection头，启用长连接
        }
    }
}

upstream的keepalive参数配合proxy_http_version 1.1和proxy_set_header Connection “”能复用到后端的TCP连接，避免频繁握手，在高QPS场景下可降低延迟约20%到30%。定期检查Nginx错误日志和stub_status监控页面，关注active connections和waiting状态连接数，确保负载均衡节点本身没有成为瓶颈。