权重分配是使流量与后端真实能力对齐的过程，weight 表示相对份额而非百分比，调优需验证处理能力、连接配置和会话依赖，并遵循动态微调节奏，避开混用 ip_hash、误解 weight 作用等常见误区。
权重分配不是简单填个数字，而是让流量和后端真实能力对齐的过程。调得准，系统稳、资源省；调得偏，可能一台压垮、另一台空转。
先看懂 weight 的真实含义
weight 不是百分比，是相对份额。比如三台服务器设为 weight=4、2、2，长期来看请求比例就是 4:2:2（即 50% : 25% : 25%），不是 40%、20%、20%。单次或低流量时会有波动，别拿几条日志判断是否“分错了”。
未写 weight 的默认是 1；设为 weight=0 可临时下线节点，不参与调度；数值建议控制在 1–100 之间，方便团队理解与协作。
调优前必须验证的三个关键点
- 后端处理能力是否真实匹配？ 查 CPU 使用率、P95 响应时间、错误率。一台 weight=5 但平均响应 1.8s 的服务，不如 weight=3 且稳定在 120ms 的节点可靠。
- 连接配置是否一致？ keepalive 连接数、proxy_read_timeout、max_fails 和 fail_timeout 要协同调整。否则健康检查频繁失败，节点被踢出，weight 再合理也白设。
- 业务是否依赖会话或本地缓存？ 若用 session 文件或本地 Redis，强行按 weight 分流会导致登录态丢失或数据不一致。这时优先考虑 ip_hash 或 sticky cookie，而不是硬调 weight。
实战中推荐的动态调优节奏
- 用 nginx -T | grep upstream 确认当前配置，再用 curl -I http://node-ip/health 快速核对各节点健康状态。
- 首次调整建议用倍数微调，比如从 weight=2 → 3，或 4 → 6，避免跳变过大引发抖动。
- 上线后紧盯 5–10 分钟：对比各节点的请求数（$request_number）、上游响应时间（$upstream_response_time）、5xx 错误率（$upstream_status ≥ 500）。
- 加一条 log_format，记录 chosen_server 和 upstream_name，出问题能快速定位哪台被选中、为什么被选中。
避开常见踩坑点
- 别混用 weight 和 ip_hash：两者逻辑冲突，ip_hash 强制绑定 IP，weight 失效，Nginx 会忽略 weight 值。
- weight 越大 ≠ 请求越快：它只影响被选中的频次，不改变单个请求的处理速度。性能瓶颈在后端，不在 Nginx 调度层。
- 扩容时别直接拉满新节点 weight：新机器可先设为 weight=1，观察 15 分钟无异常，再逐步提到 3、5，最后按能力定终值。
