权重算法本身不保证绝对均匀，哪怕后端机器配置完全相同，出现小幅负载偏差是正常现象，关键在于偏差是否在合理范围内、是否持续恶化；Nginx加权轮询按请求次序调度，非实时按比例分配，受时间抖动、连接复用、健康检查重试及监控粒度等多因素影响，短期统计偏差属正常波动。
权重算法本身不保证绝对均匀，哪怕后端机器配置完全相同，出现小幅负载偏差是正常现象，关键在于偏差是否在合理范围内、是否持续恶化。
请求分发机制决定“理论权重”≠“瞬时流量比”
Nginx 的 weighted round robin 是按请求次序轮询调度的，不是按毫秒级实时计算权重比例。比如两台 server 都设 weight=1，Nginx 会严格交替转发：第 1 个请求→A，第 2 个→B，第 3 个→A……但实际请求到达有时间抖动、处理耗时不同、连接复用状态不一致，导致统计窗口内看到的请求数可能 A 比 B 多 1–2%。
- 短连接场景下，每个请求新建 TCP 连接，连接建立/关闭开销叠加，放大微小调度间隔差异
- 客户端并发行为不均（如浏览器默认 6 个连接限制、移动端重试策略），造成上游请求洪峰分布不平滑
- proxy_buffering 开启时，Nginx 可能批量读取响应再转发，掩盖了后端真实处理节奏
连接复用与 keepalive 状态影响实际负载感知
即使硬件配置一样，运行时连接池使用率、TCP ESTABLISHED 数、TIME_WAIT 回收速度都受系统参数（net.ipv4.tcp_fin_timeout、somaxconn）、内核版本、甚至当前 CPU 调度优先级影响。Nginx 仅按配置权重分发新请求，但无法感知后端已建立连接的实际压力。
- 某台机器刚重启，连接池空闲，前几个请求响应快，后续请求因连接复用命中率高而更快被选中
- 另一台机器若经历过突发流量，残留大量 CLOSE_WAIT 或未及时回收的 socket，虽未宕机，但有效吞吐略降
- keepalive 超时（keepalive_timeout）与后端服务的 connection idle timeout 不对齐，导致连接提前断开或僵死，间接改变活跃连接分布
健康检查与失败重试引入隐性偏移
即使所有节点都“在线”，Nginx 的被动健康检查（max_fails/fail_timeout）仍会临时剔除节点。一次超时或 502 响应就会让该 server 在 fail_timeout 内被跳过，后续请求全打向剩余节点——哪怕只持续几秒，也会在分钟级监控图表中留下可测偏差。
- 网络抖动（如交换机瞬时丢包）触发单次失败，但未达 max_fails 阈值，仅影响当次请求重试路径
- proxy_next_upstream 默认包含 error timeout，意味着任意 upstream 连接阶段失败都会触发重试，而重试目标受限于当前可用 server 列表
- 日志中 $upstream_addr 字段显示“10.0.1.10:8080, 10.0.1.11:8080”，说明发生了重试，这本身就是负载短期偏移的证据
可观测性不足导致误判“偏差”
很多所谓“负载偏差”，其实是监控粒度或指标口径不一致造成的错觉：
- 只看 Prometheus 中 node_load1，忽略容器内 CPU steal 或 memory pressure；只看 Nginx 的 $request_time，没对比 $upstream_response_time，无法区分是网络延迟还是后端慢
- 用 top 查看 CPU 使用率，但没注意是否被其他进程抢占；用 ss -s 统计 socket，却没过滤掉本地回环或监控探针连接
- ELK 中按 host 分组统计 QPS，但没排除爬虫、健康检查 probe、前端埋点等非业务流量干扰
真正需要干预的是偏差持续扩大、伴随延迟上升或错误率跳变。单纯数值差 3–5%，且各节点 P95 延迟稳定、错误率趋近于零，属于分布式系统的正常波动范畴。
