权重配置需动态反映后端真实处理效率，必须写在upstream的server行内且为正整数；应基于p95响应时间倒数设定初始权重，建议比值不超1:4，并配合健康检查、连接复用与持续监控调优。
权重配置不是“设完就跑”的静态参数，而是连接 Nginx 调度逻辑与后端真实能力的桥梁。真正缩短平均响应时间的关键，在于让 weight 值反映服务器当前处理效率，而非仅凭硬件规格拍脑袋设定。
权重必须写在 upstream 的 server 行里
这是最常踩的语法坑：weight 只属于 upstream 上下文，且必须紧贴 IP/域名之后。
- ✅ 正确写法：
server 10.0.0.1:8080 weight=3; - ❌ 错误写法：
server 10.0.0.1:8080; weight=3;（Nginx 启动报 unknown directive "weight"） - ❌ 错误写法：
proxy_pass http://backend; weight=2;（location 块内 weight 无效）
权重值必须是正整数，默认为 1；设为 0 表示该节点不参与轮询，但仍接受健康检查探测。
用响应时间倒数设定初始权重
CPU、内存、网络延迟和应用层耗时共同决定实际服务能力。单纯按 CPU 核数 2:1 设权重，可能因某台机器磁盘慢或 GC 频繁而拖慢整体 P95。
- 采集各后端 P95 响应时间（例如通过 Prometheus + nginx-exporter 或应用自身埋点）
- 选一台稳定节点作为基准（如 P95 = 120ms），其余节点权重 = 基准 P95 ÷ 当前节点 P95（四舍五入取整）
- 示例：A 节点 P95=100ms，B 节点 P95=250ms → 权重比 ≈ 120/100 : 120/250 ≈ 1.2 : 0.48 → 取整为 5:2
避免权重差异过大（如 1:10），最大建议比值控制在 1:4 内，否则低权重节点长期空闲，失去冗余价值。
搭配健康检查与连接复用提升实效性
再合理的权重，也扛不住瞬时拥塞或进程僵死。必须让 Nginx 具备“感知”和“适应”能力：
- 启用主动健康检查（需 OpenResty 或 Nginx Plus）：
health_check uri=/health?ready=1 interval=3s fails=2 passes=3; - 配合被动检查：
max_fails=3 fail_timeout=30s，防止抖动误剔除 - 开启 upstream keepalive：
keepalive 32;，并在 proxy 设置中启用 HTTP/1.1 复用：proxy_http_version 1.1; proxy_set_header Connection ''; - 调低超时项：
proxy_connect_timeout 3s; proxy_read_timeout 8s;（根据业务微调，防慢节点阻塞队列）
上线后必须监控并迭代调优
权重不是一劳永逸的常量。流量模式变化、版本升级、依赖服务波动都会改变节点实际吞吐能力。
- 监控维度至少包括：各 upstream server 的请求量、成功/失败率、平均响应时间、活跃连接数
- 使用
nginx -t验证配置后再nginx -s reload，切忌跳过语法检查 - 调整权重时采用渐进式（如从 3→4→5），每次变更后观察 10–15 分钟关键指标趋势
- 将 backup 和 down 状态纳入日常运维流程：扩容灰度、计划维护、故障隔离都依赖它们协同 weight 使用
