Nginx 配置权重优化后端集群的任务流量分配比

Nginx的weight参数需结合健康检查、least_conn及实测性能动态设定，仅调权重无法优化流量分配；应以P95响应时间为基准计算权重，搭配max_fails、fail_timeout和proxy_next_upstream实现故障自动切换，并通过日志频次、延迟与错误率验证效果。

Nginx 的 weight 参数本身不直接“优化流量分配比”，而是让请求按服务器相对处理能力做长期倾向性分发。真正实现任务流量合理分配，靠的是权重设定 + 健康检查 + 连接策略的协同，而不是单改一个数字。

权重值要基于实测吞吐或延迟来设

凭 CPU 核数、内存大小设 weight 容易失真，因为瓶颈常在磁盘 IO、锁竞争或慢查询。更可靠的做法是：

1. 对每台后端用相同压测工具（如 wrk -t4 -c100 -d30s）测出稳定 QPS 或 P95 响应时间
2. 以性能最好的节点为基准，其余节点 weight = 基准 P95 ÷ 自身 P95（四舍五入取整）
3. 例如：A（P95=80ms）、B（P95=200ms）、C（P95=160ms）→ weight ≈ 1 : 0.4 → 1 : 0.5 → 取整为 1:1:1，说明三者实际承载力接近，强行设成 5:2:3 反而造成倾斜

必须搭配健康检查，否则权重失效

weight 只对“健康节点”生效。一台 weight=5 的机器若正在卡顿，Nginx 不会自动绕过它——除非触发失败机制：

1. 每个 server 行加上 max_fails=3 fail_timeout=30s
2. 在 location 中配 proxy_next_upstream error timeout http_500 http_502 http_503 http_504
3. 这样请求失败时自动切到下一个加权节点，避免把流量持续打向已响应缓慢的实例

长连接或耗时任务场景，加 least_conn 更公平

纯轮询+weight 在请求处理时长差异大时容易堆积连接。比如有文件上传、报表导出等接口：

1. 在 upstream 块开头加 least_conn;（注意不能和 ip_hash 共存）
2. 它会让新请求优先落到当前活跃连接最少的节点，既尊重权重倾向，又缓解瞬时堆积
3. 示例配置：

   upstream app {least_conn;server 192.168.1.10:3000 weight=4 max_fails=3 fail_timeout=30s;server 192.168.1.11:3000 weight=2 max_fails=3 fail_timeout=30s;}

上线后必须验证真实效果，不是看配置是否生效

reload Nginx 后，别只查进程是否启动成功，要盯三项指标：

1. 各后端 IP 在 access log 中出现频次（用 awk '{print $NF}' access.log | sort | uniq -c），数百次以上才趋于理论比例
2. 每台后端的 P95 延迟是否同步上升——如果高 weight 节点延迟明显变长，说明它实际扛不住，weight 设高了
3. 错误率（尤其是 5xx）是否某台异常突出，可能暴露应用层瓶颈（如未调优的数据库连接池）

权重不是一锤定音的静态参数，建议每周结合监控数据微调一次。比如某台机器升级 SSD 后延迟下降 25%，可将其 weight 提升 1～2 点。