权重设置通过匹配服务器实际能力优化流量分配，提升资源利用率；需基于压测吞吐量设定比值权重，并配合健康检查（max_fails=3、fail_timeout=30s）及least_conn等策略动态调优。
权重设置本身不直接“提升”资源利用率，而是让流量分配更匹配服务器实际能力，从而避免部分机器过载、部分闲置——这才是资源利用率提升的关键。
权重要基于可测性能数据来设
别凭感觉写 weight=5 或 weight=10。真实有效的做法是：
- 对每台后端服务器单独压测：用 wrk 或 ab 测出在相同并发下能稳定支撑的请求吞吐量（req/s）
- 按吞吐比设定 weight：比如 A 能处理 1500 req/s，B 只能处理 500 req/s → 吞吐比 3:1 → weight 设为 3 和 1
- 若硬件差异明显（如 CPU 核数 16C vs 4C），可先按核数比粗设（4:1），再结合压测微调
- weight 是比值，不是绝对值：3:1 和 30:10 效果完全一样
必须搭配健康检查才能让权重真正起作用
光设 weight 不加故障隔离，等于把流量继续往已卡死的机器上送。关键配置项：
- max_fails=3：连续 3 次超时或返回 5xx 就标记为不可用
- fail_timeout=30s：30 秒内不再转发请求，之后自动试探恢复
- 每台 server 行都要加上这两个参数，否则权重只在“理论健康池”里生效
单一权重不够时，换更贴近业务的策略
如果后端响应时间波动大（比如有长耗时任务），轮询+weight 容易导致负载倾斜。这时可考虑：
- least_conn：优先发给当前活跃连接最少的节点，适合请求处理时长差异大的场景
- ip_hash：强制同一客户端始终落到同一台后端，适用于需会话保持的 ThinkPHP 等框架
- 不要强行用 weight 模拟“算力均摊”——Nginx 没有实时采集 CPU/内存的能力，那不是它的职责
上线后要验证和迭代
配置不是一劳永逸的，得看实际效果：
- 观察各后端的 CPU 使用率、平均响应时间、错误率，而不是只看访问日志里的 IP 分布
- 发现某台长期高负载？说明 weight 偏低或它本身存在瓶颈（如慢 SQL、未调优 PHP-FPM）
- 流量模型变化（如新增批量导出接口）后，需重新压测并调整 weight
