加权轮询削峰填谷能力验证需基于后端能力差异，通过梯度延迟配置、显式weight设置、阶梯压测及多维指标分析（分配比、失败率分布、P95延迟）综合评估，同时排除ip_hash等干扰机制。
测试加权轮询在突发流量下的削峰填谷能力，关键不是看“是否均匀”，而是验证它能否按权重比例动态承接压力、避免单点过载，同时体现后端能力差异带来的分流效果。这需要结合压测设计、状态观测与异常干扰排除。
构造有梯度的后端服务能力
真实削峰填谷的前提是后端本身存在处理能力差异。不能三台配置完全相同的机器——那样加权轮询就退化为普通轮询。
- 给每台后端设置不同响应延迟：例如用
sleep(0.1)模拟慢节点，sleep(0.02)模拟快节点，或直接限制 CPU/内存资源 - 在 upstream 中显式配置 weight，如：
server 192.168.1.10:8080 weight=5;server 192.168.1.11:8080 weight=3;server 192.168.1.12:8080 weight=1; - 所有后端返回唯一标识（如
X-Server-ID）和响应耗时（X-Response-Time），便于后续归因分析
发起阶梯式突发压测
单一并发无法暴露削峰行为，需模拟“洪峰—回落—再冲击”过程，观察流量是否按权重比例向高能力节点偏移。
- 第一阶段：用
ab -c 50 -n 500建立基线，记录各节点请求数与平均延迟 - 第二阶段：突增至
ab -c 300 -n 1500，持续 30 秒，观察连接堆积、超时、502/504 是否集中出现在低 weight 节点 - 第三阶段：快速降回
-c 50，检查高 weight 节点是否仍承担更高比例流量（即“填谷”延续性） - 全程禁用 keepalive：
proxy_http_version 1.1;+proxy_set_header Connection '';，避免连接复用掩盖真实调度
从日志中提取三类关键指标
仅统计请求数不够，要交叉验证“分得是否合理”“扛得是否住”“恢复是否稳”。
-
分配比：解析 access_log 或后端 access_log，统计各
X-Server-ID出现频次，对比实际占比与理论权重比（如 5:3:1 → 理论应为 55.6% : 33.3% : 11.1%），允许 ±3% 偏差 - 失败率分布：筛选 5xx 状态码，确认是否集中在 weight=1 的节点；若 weight=5 节点失败率反超，说明其已饱和或健康检查未生效
-
延迟分位值：用
awk '{print $NF}' | sort -n | awk 'NR==int(0.95*N)+1 {print}'计算 P95 延迟，观察高 weight 节点 P95 是否显著低于低 weight 节点
排除干扰策略与状态误判
很多“削峰失效”其实是其他机制在起作用，而非加权轮询本身问题。
- 检查是否误启
ip_hash或hash $request_uri：它们会覆盖加权轮询逻辑，哪怕配置被注释，也要确认未被 include 进来 - 确认
max_fails和fail_timeout设置合理：突发时短暂超时易触发临时摘除，导致剩余节点被迫超额承载，建议设为max_fails=5 fail_timeout=60s - 关闭健康检查中的主动探测（
health_check）或调大interval，避免压测期间频繁震荡节点状态
