Nginx 通过 upstream 块中 server 的 weight 参数实现按服务能力加权分发,权重为正整数、默认1、呈相对比例关系,需经压测校准(QPS÷响应时间)、上线后依CPU负载微调,并支持路径级差异化分流与定期验证。

直接用 weight 参数就能让 Nginx 按能力分发请求,不是玄学,而是可算、可控、可调的资源调度方式。关键不在于设多少,而在于怎么设得准、调得稳。
权重配置的核心写法
所有权重逻辑都写在 upstream 块里,语法简洁明确:
- 每台后端服务器用 server IP:端口 weight=N 定义,N 是正整数,默认为 1
- 权重值之间是相对比例关系,比如 weight=6 和 weight=2 等价于 weight=3 和 weight=1
- 未显式写 weight 的服务器,统一按 weight=1 计算总权重
- 支持同时搭配其他参数,如 max_fails=2 fail_timeout=30s(健康检查)、backup(备用机)
权重值怎么定才合理
不能拍脑袋填数字,得结合真实服务能力来校准:
- 先做压测:分别对每台后端服务器跑相同接口(如 /health 或 /api/test),记录 QPS 和平均响应时间
- 用 QPS ÷ 平均响应时间 粗略估算处理效率比,作为初始权重参考(例如 A 服务器效率是 B 的 2.5 倍,可设 weight=5 和 weight=2)
- 上线后观察实际负载(CPU、内存、连接数),微调权重使各节点 CPU 利用率尽量接近 60%–75%
- 避免极端值:单台权重超过总和 60% 容易形成瓶颈,低于 10% 则调度意义弱化
结合路径做差异化权重转发
同一套 upstream 可通过 location + proxy_pass 实现路径级分流,让不同业务走不同权重组合:
- 为静态资源单独建 upstream,配高权重(如 weight=5),因为它们轻量、缓存友好
- 为支付类关键 API 单独建 upstream,用更高权重 + 更严健康检查(如 fail_timeout=10s)
- 示例:访问 /api/pay/* 走 high-priority 组,/static/ 走 static-cache 组,/ 走默认组
- 注意:不要在同一个 location 内混用多个 proxy_pass,否则权重逻辑会失效
权重生效后的验证与维护
配置 reload 后必须验证是否真正按预期工作:
- 用 curl -I http://your-nginx-domain/ 多次请求,看响应头中 X-Upstream-Addr(需在 proxy_set_header 中添加)是否符合权重比例
- 开启 Nginx stub_status 模块,访问 /nginx-status 查看 active connections 和 upstream 状态
- 定期(建议每周)检查 access.log 中各后端 IP 的 request count,计算实际分发比是否偏离设定值 ±5% 以内
- 扩容新机器时,先设低权重(如 weight=1),观察 1 小时无异常后再逐步加到目标值


















