权重参数需基于实测p95延迟设定，而非硬件参数；建议最大权重比控制在1:4内，且必须配合健康检查、连接复用和可观测性形成闭环，定期迭代优化。
权重参数本身不直接“优化压力”，而是让请求分配更贴近各后端的真实处理能力。真正起作用的是：用合理权重引导流量，再配合健康检查、连接复用和可观测性形成闭环。单纯调大 weight 反而可能压垮节点。
权重必须基于实测能力设定，而非硬件参数
很多人按 CPU 核心数或内存大小设 weight，但实际瓶颈常在磁盘 IO、网络带宽或应用层锁竞争。正确做法是：
- 先对每台后端做相同压测（如 wrk -t4 -c100 -d30s），记录 P95 响应时间与稳定 QPS
- 选一台基准机（比如 P95=80ms 的服务器），其余机器权重 = 基准 P95 ÷ 自身 P95（结果四舍五入为整数）
- 例如：A 机 P95=80ms → weight=1；B 机 P95=240ms → weight=80/240≈0.33 → 取整为 1；C 机 P95=120ms → weight=80/120≈0.67 → 取整为 1。此时三台权重都是 1，说明它们实际吞吐接近，强行设成 3:1:2 反而失衡
避免权重极端化，保留容错冗余
weight 比例过大（如 10:1）会导致低权重点长期空闲、高权重点持续承压，失去弹性。建议：
- 最大权重比控制在 1:4 以内（例如 4:2:1，而非 8:1:1）
- 所有节点至少保留 weight≥1，避免因临时抖动被完全跳过
- 用 backup 标记备用机，而不是把某台 weight 设为 0 —— weight=0 的节点仍会被健康检查探测，但完全不参与分发，运维上难感知其状态
权重只是起点，必须搭配运行时机制
静态 weight 无法应对 CPU 突增、GC 停顿或慢查询等瞬时问题。需组合以下配置：
-
健康检查：用
health_check（OpenResty/Nginx Plus）或第三方 check 模块，探测/health?ready=1，fails=2、passes=3，避免误剔除 -
连接复用：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 提升 1～2 点
