提高后端处理利用率的关键是按真实吞吐能力分配流量：基于压测设weight（如1800:600→3:1），必须搭配健康检查（max_fails=3 fail_timeout=30s），依业务选算法（least_conn/ip_hash），并持续监控CPU、响应时间等指标调优。
提高后端处理利用率，核心不是让每台服务器“跑满”，而是让流量分配更贴合它们的真实处理能力，避免忙的忙死、闲的闲死。
基于压测数据设权重，别拍脑袋
权重不是调节“看起来均衡”的装饰参数，而是对真实吞吐能力的映射：
- 用 wrk 或 ab 对每台后端单独压测，在相同并发下记录稳定支撑的请求量（如 A：1800 req/s，B：600 req/s）
- 按吞吐比设 weight，比如 1800:600 → 3:1，可写为
weight=3和weight=1 - weight 是比值，
weight=30和weight=10效果完全一样，无需刻意取整或拉大数值 - 硬件差异明显时（如 16C vs 4C），可先按 CPU 核数比粗设（4:1），再用压测结果校准
必须搭配健康检查，否则权重失效
没有故障隔离的权重，等于把请求继续发给已卡住的机器：
- 每台
server行都要加max_fails=3 fail_timeout=30s -
max_fails=3表示连续 3 次超时或返回 5xx，就标记为不可用 -
fail_timeout=30s表示 30 秒内不转发新请求，之后自动试探恢复 - 只配 weight 不配健康检查，Nginx 仍会把请求轮到已响应缓慢或宕机的节点上
根据业务特征换算法，不止靠 weight
当后端响应时间波动大、存在长耗时任务时，单纯轮询+weight 容易引发负载倾斜：
- 用
least_conn：优先发给当前活跃连接最少的节点，适合 PHP-FPM、Java 应用等处理时长不均场景 - 用
ip_hash：同一客户端固定落到同一台后端，适用于 ThinkPHP、Laravel 等需会话保持的框架 - 避免强行用 weight 模拟“实时算力调度”——Nginx 不采集 CPU/内存，它只做连接层分发
上线后看真实指标，持续调优
配置不是一次写完就结束，要盯实际效果：
- 观察各后端的 CPU 使用率、平均响应时间、5xx 错误率，而不是只看 Nginx 访问日志里 IP 分布是否“均匀”
- 若某台长期高负载，可能是 weight 设低了，也可能是它自身有瓶颈（如慢 SQL、PHP-FPM 子进程不足）
- 业务变化（如新增导出接口、大文件上传）后，原有压测数据可能失效，需重新测试并调整 weight
