Nginx权重分发的核心是按后端真实处理能力精准分配流量，避免资源闲置或过载；需结合硬件配置、业务特征设定weight，并配合least_conn、健康检查与实时监控持续校准。
匹配服务器实际性能配置 weight
权重不是拍脑袋定的数字，要对应后端服务器的硬件差异和业务负载特征：
- 一台 16C/64G 的机器处理能力约是 8C/32G 机器的 1.8–2.2 倍，weight 可设为 5 和 2（比例接近 2.5:1），比简单设 2:1 更贴合实测吞吐差异；
- 若某台机器跑的是 CPU 密集型服务（如图像压缩），另一台跑的是 IO 密集型（如日志写入），可分别设 weight=3 和 weight=1，避免 CPU 成瓶颈；
- 上线新机器时，不要直接设高权重，建议先用 weight=1 观察 10–15 分钟响应时间与错误率，再逐步调高。
权重必须配合 least_conn 或轮询使用
单纯加权轮询只管“分配比例”，不管“实时负载”。真正发挥权重价值，需叠加动态感知能力：
- 在
upstream块中同时写least_conn和weight：Nginx 会优先选连接数最少的节点，在连接数相当时才按权重分配； - 避免只用
ip_hash+weight：IP Hash 本身不支持权重生效（Nginx 官方文档明确说明），权重会被忽略； - 不要在健康检查失效时还硬扛流量——权重再合理，若后端已假死，只会放大延迟。务必配
max_fails=2 fail_timeout=5s。
验证权重是否真正起效
光看配置没用，得用数据确认流量是否按预期分布：
- 开启 Nginx stub_status 模块，用
stub_status on查看各 upstream server 的active连接数和requests总数； - 在后端服务打日志，统计单位时间内各实例收到的请求数，对比是否接近 weight 比例（例如 weight=3:1，应约为 75% : 25%）；
- 观察响应时间 P95：若高权重机器 P95 明显高于低权重机器，说明该节点可能有慢查询或资源争用，需单独排查，而非调低权重掩盖问题。
权重不是一劳永逸，需要持续校准
服务器负载会随业务变化浮动，权重也得跟着动：
- 大促前做压测，记录各机器在不同并发下的吞吐拐点，据此重设 weight；
- 监控 CPU 平均使用率持续 >70% 的节点，考虑降低其 weight 或扩容；
- 用 Prometheus + nginx-vts-exporter 实时采集 upstream 各 server 的 request rate、response time、failures，设置告警自动提示权重失衡。
