加权轮询验证目标是资源消耗匹配权重而非请求次数，需在相同请求和配置下，对比CPU等资源利用率与权重比例的一致性，并排除健康检查、keepalive等干扰因素。
明确验证目标：不是看“请求次数”，而是看“资源消耗是否匹配权重”
加权轮询的 weight 控制的是请求数量比例，不是 CPU、内存或响应时间的均摊。高负载下验证均匀性，重点不是统计每台后端收到多少次请求，而是检查这些请求带来的实际资源压力是否与权重设置逻辑一致。比如 weight=4 和 weight=1 的两台机器，理想状态是前者的平均 CPU 利用率约为后者的 4 倍（在相同请求类型和并发下），而非单纯要求请求比严格等于 4:1。
构造可比性高的压测环境
必须让所有后端面对完全相同的请求内容、路径、Header 和 body，否则响应差异会干扰结果判断：
- 使用 wrk 或 ab 发起固定路径、固定参数、无 Cookie 的请求，例如：
wrk -t4 -c100 -d30s http://nginx/health - 禁用后端缓存（如 Redis、本地缓存）和 Nginx 缓存（
proxy_cache off），避免响应时间被缓存掩盖真实处理开销 - 确保所有后端服务启动时配置一致（JVM 参数、线程池大小、数据库连接池等），排除单点配置偏差
- 压测期间关闭自动扩缩容、日志滚动、监控采集等可能争抢资源的后台任务
采集多维指标并交叉比对
仅看 Nginx access log 中的 X-Server-ID 计数不够，高负载下需同步抓取三类数据：
- 请求分发层：Nginx 日志中记录 upstream_addr 和 upstream_response_time，按 server IP 分组统计平均响应时间、超时次数、5xx 比例
-
后端资源层：每台机器上实时采集 CPU 使用率（
top -bn1 | grep 'Cpu(s)' | awk '{print $2}'）、内存 RSS、活跃连接数（ss -s | grep estab） -
应用性能层：在响应头中统一注入
X-Proc-Time（服务端处理耗时）和X-Queue-Time（入队等待时间），便于定位瓶颈在计算还是排队
若发现某台 high-weight 机器 CPU 才 40% 而 low-weight 机器已到 90%，说明权重设置偏高或该机器存在 I/O 阻塞、锁竞争等隐藏瓶颈。
识别并排除非策略干扰因素
高负载下以下配置或状态极易导致分配“看似不均”，实则合理：
-
健康检查误剔除：检查
max_fails和fail_timeout是否过严，高负载时偶发超时可能触发临时摘机，造成剩余节点承接超额流量 -
keepalive 连接复用：客户端复用长连接会导致后续请求持续打在同一后端，应确认 upstream 中未启用
keepalive，或压测时显式加Connection: close - 上游限流或熔断：后端框架（如 Spring Cloud Gateway、Sentinel）若开启限流，会主动拒绝部分请求，造成 Nginx 层统计失真
-
DNS 缓存或 IP 复用：若压测工具复用同一源 IP，且 Nginx 启用了
ip_hash（即使注释了也要确认未生效），会导致流量固化
