Nginx 的 weight 参数通过设置相对权重实现按能力差异分配请求，如 3:1:2；weight=0 表示下线，默认为 1；需结合 CPU、内存、响应时间等指标设定，并配合健康检查、slow_start 及动态 upstream 持续调优。
当后端服务器性能差异明显（比如 CPU 核心数、内存、磁盘 IO 不同），单纯用轮询（round-robin）会导致高配机器空转、低配机器过载。Nginx 的 weight 参数就是为此设计的——它不改变调度算法本质，而是调整每台服务器在轮询序列中被选中的概率。
权重值不是百分比，而是相对比例
比如三台服务器：
server 192.168.1.10:8080 weight=3;server 192.168.1.11:8080 weight=1;server 192.168.1.12:8080 weight=2;
它们的实际请求分配比约为 3:1:2，即每 6 次请求中，分别分发 3、1、2 次。注意：weight=0 表示该节点不参与负载，常用于临时下线；weight 默认为 1，未显式声明即按 1 计算。
结合实际性能指标设定初始权重
避免凭感觉拍脑袋设值。建议参考以下维度做粗略换算：
- CPU 核心数占比（例如 8 核 vs 4 核 → 权重比可设为 2:1）
- 内存容量比（若应用强依赖内存，如缓存密集型服务）
- 历史平均响应时间倒数（响应快 2 倍，可考虑权重高约 1.5–2 倍）
- 观察 Nginx 的
upstream状态页（需开启stub_status或用第三方模块如nginx-module-vts）验证真实请求分布
权重不能替代健康检查与动态伸缩
静态 weight 只解决“能力差异”，不应对付“故障”或“瞬时过载”：
- 务必搭配
max_fails和fail_timeout，自动剔除异常节点 - 对突发流量敏感的服务，可配合
slow_start（Nginx 1.11.5+）避免新节点上线时被压垮 - 若后端支持自动扩缩容（如 Kubernetes HPA），建议将 Nginx 配置为基于服务发现（如 consul-template 或 nginx-plus 动态 upstream），而非固定 IP + 手动调权
验证与持续调优的关键动作
上线后别只看平均值：
- 用
curl -I或 Prometheus + nginx-exporter 监控各 upstream 的request_time和upstream_response_time分布 - 对比各节点的
active连接数（通过nginx-module-vts或 OpenResty 的ngx.var.connections_active）是否与权重趋势一致 - 每次调整 weight 后至少观察 15–30 分钟，避开业务高峰时段做变更
