通过Nginx配置负载均衡讲解权重分配、健康检查、会话保持等核心配置

1. 为什么我们需要负载均衡？

每次走进网红奶茶店总能看到这样的场景：三个收银台排着长队，但中间柜台的小哥动作特别快，左右两边的队伍却动得慢。这时候聪明的店家会把新来的顾客引导到中间柜台，这就是现实版的负载均衡。

在Web服务领域，当我们的应用访问量突破单台服务器极限时，就需要像奶茶店老板一样，把用户的请求合理分配给多个服务器。这就是负载均衡的核心价值——提高系统吞吐量、保证服务可用性、实现灵活扩展。

2. Nginx负载均衡的三大实战场景

2.1 高并发分流场景

假设我们的电商平台正在做双十一促销，单台服务器每秒只能处理500个请求。当实际访问量达到每秒2000次时，通过Nginx将流量分发给4台服务器，就像开通了4个收银通道。

2.2 服务冗余保障

某天凌晨3点，服务器B突然宕机。配置了健康检查的Nginx会自动停止向它发送请求，就像奶茶店及时关闭出故障的收银台，保证其他顾客正常下单。

2.3 灵活扩展场景

当我们的在线教育平台新增直播功能时，可以单独为直播服务部署专用服务器集群，通过Nginx实现特定路径的定向分发，好比在奶茶店里单独开设"外卖专用通道"。

3. 手把手配置实战（基于Nginx 1.18 + Ubuntu 20.04）

3.1 基础版配置

# 定义服务器集群（这里用docker创建了3个测试节点）
upstream backend {
    server 192.168.1.101:8080 weight=3;  # 权重3，处理更多请求
    server 192.168.1.102:8080;           # 默认权重1
    server 192.168.1.103:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name myshop.com;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这个配置实现了：

请求按3:1:1的比例分配
对103节点设置失败熔断机制（30秒内失败3次则暂时剔除）
保留原始请求的Host头和客户端真实IP

3.2 高级策略配置

upstream backend {
    least_conn;                 # 最少连接数策略
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    server 192.168.1.103:8080 backup;  # 备用服务器
}

upstream upload_cluster {
    ip_hash;                    # 基于IP的会话保持
    server 192.168.2.201:8080;
    server 192.168.2.202:8080;
}

server {
    location / {
        proxy_pass http://backend;
    }
    
    location /upload {
        proxy_pass http://upload_cluster;
        # 文件上传需要更长的超时时间
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
    }
}

这个配置展示了：

不同业务路径使用不同负载策略
文件上传服务的特殊超时设置
主备服务器切换机制
会话保持的IP哈希方案

4. 必须知道的注意事项

4.1 健康检查的陷阱

很多新手会忽略主动健康检查的配置：

upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    
    # 新增健康检查参数
    check interval=3000 rise=2 fall=3 timeout=1000;
}

location /nginx_status {
    check_status;               # 查看节点健康状态
    access_log off;
    allow 192.168.1.0/24;       # 限制内网访问
    deny all;
}

需要配合nginx_upstream_check_module模块使用

4.2 会话保持难题

当使用轮询策略时，用户的登录状态可能会丢失。除了ip_hash方案，更推荐的方式是：

upstream backend {
    sticky cookie srv_id expires=1h domain=.myshop.com path=/;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

这种方式通过cookie实现会话绑定，比ip_hash更灵活

5. 技术方案深度对比

方案	配置复杂度	会话保持	健康检查	适用场景
轮询	★☆☆☆☆	无	被动	静态资源分发
加权轮询	★★☆☆☆	无	被动	异构服务器环境
最少连接数	★★☆☆☆	无	被动	长连接服务
IP哈希	★★☆☆☆	强	被动	有状态服务
Nginx Plus	★★★★☆	多种方式	主动	企业级应用

6. 常见故障排查指南

6.1 节点状态异常

使用调试命令观察流量分配：

# 实时监控请求分发情况
tail -f /var/log/nginx/access.log | awk '{print $6}'

# 查看当前节点状态
curl http://localhost/nginx_status

6.2 性能瓶颈定位

当发现Nginx服务器CPU飙升时，检查：

# 查看工作进程负载
top -p $(pgrep -d',' nginx)

# 分析慢请求
cat /var/log/nginx/access.log | awk '$request_time > 1'

7. 最佳实践方案推荐

根据三年运维经验，推荐生产环境采用如下配置：

upstream backend {
    zone backend 64k;              # 共享内存区域
    least_conn;                    # 连接数均衡
    queue 100 timeout=60s;         # 排队机制防雪崩
    
    server web01:8080 weight=2;
    server web02:8080;
    server backup01:8080 backup;   # 备用节点
    
    keepalive 32;                  # 保持长连接
}

server {
    proxy_next_upstream error timeout http_500;
    proxy_connect_timeout 1s;
    proxy_send_timeout 10s;
    proxy_read_timeout 10s;
}