nginx的weight仅实现请求计数比例分配，非算力均摊；需结合健康检查、least_conn或外部监控动态调权才能逼近资源均衡。
Nginx 本身不支持“算力完美均摊”这种动态感知 CPU、内存或响应时间的智能调度——它没有内置的实时负载采集能力。所谓“轮询权重”只是静态比例分配，weight 参数控制的是请求数量的理论占比，而非实际算力消耗的平衡。想靠 weight 实现“完美均摊”，本质是误解了它的作用边界。
真正可行的做法，是用 weight 做初步流量倾斜 + 配合健康检查与连接策略，逼近资源利用率均衡。下面分几个关键点讲清楚怎么做、怎么调、容易踩什么坑：
轮询权重不是算力权重，而是请求计数权重
weight 只影响 Nginx 分发请求的频次比例，比如：
-
server A:8080 weight=4 -
server B:8080 weight=1
→ 理论上每 5 个请求中，4 个去 A，1 个去 B
但它完全不关心：
- A 正在处理 200 个慢查询，CPU 98%
- B 空闲，响应只要 10ms
→ Nginx 仍会继续按 4:1 派发新请求，直到触发max_fails才暂停转发
所以，“完美均摊”不能只靠 weight，得组合其他机制。
权重设置要基于可测指标，不是拍脑袋
别写 weight=100 或 weight=37。合理做法是：
- 先压测单台服务器：用
ab或wrk测出各节点在相同并发下的吞吐（req/s）和平均延迟 - 比如 A 能扛 1200 req/s，B 只能扛 300 req/s → 吞吐比为 4:1 → weight 设为
4和1 - 若三台：A(16C), B(8C), C(4C)，粗略按核数比设
weight=4,weight=2,weight=1
注意：weight 值本身无单位，只看比值。4:2:1 和 8:4:2 效果完全一样。
必须搭配健康检查，否则权重再准也白搭
光设 weight 不加故障隔离，一台机器卡死，Nginx 还会持续往它身上扔请求。必须给每个 server 行加上：
server 192.168.1.10:8080 weight=4 max_fails=3 fail_timeout=30s; server 192.168.1.11:8080 weight=1 max_fails=3 fail_timeout=30s;
-
max_fails=3：连续 3 次失败（超时/5xx）就标记为 down -
fail_timeout=30s：30 秒内不往它转发，之后自动试探恢复
这个组合才能让权重在“健康节点池”里生效，避免把流量塞进已瘫痪的机器。
更接近“算力均摊”的替代方案
如果真实业务对响应时间敏感（比如接口 RT 差异大、有长耗时任务），建议换策略：
-
least_conn：优先发给当前活跃连接最少的后端
upstream backend { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; }它比 weight 更适应“处理时间不均”的场景，比如文件上传、报表导出类请求。
配合外部监控动态调权（进阶）：
用脚本定期查各后端/metrics接口（如 Prometheus 暴露的 CPU/queue_length），生成带 weight 的临时 upstream 配置，再nginx -s reload。但这需要运维闭环，不是开箱即用。
配置示例（含必要防护）
http {
upstream api_backend {
server 192.168.1.10:8080 weight=4 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 weight=1 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 weight=2 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location /api/ {
proxy_pass http://api_backend;
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
改完务必执行：
sudo nginx -t && sudo systemctl reload nginx
不复杂但容易忽略
