权重需根据实测延迟动态设定，配合健康检查、连接复用与可观测性形成闭环；必须写在upstream的server行末weight参数中，值为正整数，默认1，设0仅隔离但持续探测；压测取p95响应时间计算权重，避免按硬件参数误配，最大权重比建议≤4:1，且须定期结合监控微调。
权重不是调大就更“强”，而是让流量分配更贴近后端真实处理能力。它本身不降低压力，只引导请求走向——真正起作用的是“合理权重 + 健康检查 + 连接复用 + 实时可观测性”这个闭环。
权重必须写在 upstream 的 server 行里
weight 参数只能出现在 upstream 块中、server 指令同一行的末尾，不能单独成行，也不能放在 location 或 proxy_pass 附近：
- ✅ 正确：
server 10.0.0.1:8080 weight=3; - ❌ 错误：
server 10.0.0.1:8080; weight=3;（Nginx 启动报 unknown directive） - ❌ 错误：
proxy_pass http://backend; weight=2;（语法无效）
权重值必须是正整数，默认为 1；设为 0 表示该节点不参与轮询，但仍会被健康检查探测——适合临时隔离但需持续监控的场景。
权重值不能靠硬件参数猜，得靠实测延迟定
按 CPU 核心数或内存大小设 weight 是常见误区。实际瓶颈常在磁盘 IO、慢 SQL、GC 停顿或锁竞争上。正确做法是压测每台后端的真实服务能力：
- 用 wrk 等工具对所有后端做统一压测：如
wrk -t4 -c100 -d30s http://host/health - 记录每台机器的 P95 响应时间与稳定 QPS
- 选一台基准机（比如 P95=80ms），其余节点权重 = 基准 P95 ÷ 自身 P95，四舍五入取整
- 例如：A（80ms）→ weight=1；B（240ms）→ 80/240≈0.33 → weight=1；C（120ms）→ 80/120≈0.67 → weight=1。三台权重都是 1，说明它们吞吐能力接近，强行设成 3:1:2 反而失衡
避免极端比例，保留弹性冗余
权重比过大（如 10:1）会导致低权重点长期空闲、高权重点持续承压，失去容错能力：
- 建议最大权重比控制在 1:4 以内，例如 4:2:1，而非 8:1:1
- 所有节点 weight ≥ 1，防止某台因瞬时抖动被完全跳过
- 备用机用
backup标记，而不是设 weight=0 —— backup 节点不参与常规分发，但会在其他节点全不可用时自动启用，运维更可控
权重只是起点，必须搭配运行时机制
静态 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 统计各后端 IP 出现频次，观察是否趋近理论比例；同时监控每台后端的 CPU、活跃连接数、P95 延迟，若某台负载偏高但权重未超标，说明其应用存在性能瓶颈，需单独优化。权重不是一劳永逸的值，建议每周结合监控数据微调一次。
