weight参数不提升物理性能但可优化请求分配，需基于实测p95延迟设定权重，搭配健康检查、连接复用与超时控制，并通过日志和监控持续验证调优。
权重必须基于实测响应能力设定
不能按 CPU 核数或内存大小拍脑袋设值——实际瓶颈常在磁盘 IO、慢查询或锁竞争。正确做法是：
- 对每台后端用相同压测工具（如
wrk -t4 -c100 -d30s）测试同一接口，记录 P95 响应时间和稳定 QPS - 选一台基准机（比如 P95=80ms），其余机器权重 = 基准 P95 ÷ 自身 P95，结果四舍五入为整数
- 若 A 机 P95=80ms → weight=1；B 机 P95=240ms → weight≈0.33 → 取整为 1；C 机 P95=120ms → weight≈0.67 → 取整为 1，则三台都设 weight=1，说明它们吞吐接近，强行拉成 4:1:2 反而破坏均衡
避免权重极端化，保留冗余弹性
weight 比例过大（如 10:1）会导致低权重点长期闲置、高权重点持续承压，失去容错空间。建议：
- 最大权重比控制在 1:4 以内（例如 4:2:1，而非 8:1:1）
- 所有节点 weight ≥ 1，防止因瞬时抖动被完全跳过
- 备用机用
backup标记，而不是设weight=0—— 后者节点仍被健康检查探测，但完全不参与分发，运维上难感知其状态
静态权重必须搭配运行时保护机制
单靠 weight 无法应对 CPU 突增、GC 停顿或慢 SQL 等瞬时问题。需同步配置：
-
健康检查：启用
max_fails=2 fail_timeout=15s，或集成第三方 check 模块，探测/health?ready=1，连续失败才剔除 -
连接复用：upstream 内加
keepalive 32，proxy 区域配proxy_http_version 1.1和proxy_set_header Connection '' -
超时收紧：如
proxy_connect_timeout 3s、proxy_read_timeout 8s（根据业务 P99 调整），防慢响应阻塞连接池
上线后必须验证并持续迭代
reload 后不能只看 Nginx 启动成功，要确认真实效果：
- 查 access log，用
awk '{print $upstream_addr}'统计各后端 IP 出现频次，观察是否趋近理论比例（数百请求以上才稳定） - 监控每台后端的 CPU、活跃连接数、P95 延迟——若某台负载明显偏高但权重未超标，说明其应用存在性能瓶颈，需单独优化
- 权重不是一劳永逸，建议每周结合监控数据微调一次，比如 SSD 升级后延迟下降 30%，可将其 weight 提升 20%
