ab或wrk可验证burst队列行为：开启nodelay时每秒处理rate+burst请求，关闭后前rate个立即响应、next burst个排队匀速处理、超限返回503；通过响应时间差值、失败请求数、延迟百分位及Nginx日志excess值确认排队逻辑。
直接用 ab（Apache Bench）或 wrk 模拟突发请求，就能清晰观察 burst 队列的等待行为。关键不是“能不能压”，而是看响应时间分布和错误率变化是否符合漏桶缓冲逻辑。
用 ab 测 burst 队列排队效果
假设你配置了 rate=5r/s burst=10 nodelay，那每秒最多可处理 15 个请求（5 个按速率 + 10 个立即从队列取）。但若去掉 nodelay，就进入真实排队场景：
-
ab -n 30 -c 30 http://your-api/：30 个请求并发打过去，前 5 个立刻响应，接下来 10 个在 burst 队列里等待被匀速消费（每 200ms 放行 1 个），剩余 15 个直接 503 - 观察
Time per request (mean)和Time per request (across all concurrent requests)的差值——差值越大，说明排队越深 - 查看
Failed requests数量，应接近30 − (5 + 10) = 15（若 rate=5、burst=10）
用 wrk 看时间分布更直观
wrk 支持统计百分位延迟，能直接反映 burst 队列中请求的“等待时长”：
wrk -t2 -c50 -d10s --latency http://your-api/- 重点看
Latency Distribution中 90%、99% 的值：如果rate=10r/s且burst=20，第 21~40 个请求大概率落在 100–200ms 区间（因每 100ms 处理 1 个），而第 41+ 个会超时或失败 - 对比开启/关闭
nodelay时的 P99 延迟：关掉后 P99 通常跳升 1–2 秒，就是排队等待时间
配合日志确认排队动作
Nginx 默认不记录限流细节，需手动加日志字段验证队列行为：
- 在
log_format中加入$limit和$limit_rate变量（需编译时含--with-http_realip_module等） - 或使用
limit_req_status 429并在 access_log 中标记状态码，观察 429 出现时机是否集中在 burst 耗尽后 - 搭配
limit_req_log_level warn，在 error.log 中搜limiting requests，可看到“excess”数值——比如excess=12表示该请求比当前漏桶水位高出 12，已排队或被拒
真实突发场景建议这样测
别只压单点，要模拟用户真实点击节奏：
- 用
hey -z 10s -q 20 -c 20 http://api/（每秒发 20 请求持续 10 秒），观察 burst 是否被反复填满又清空 - 故意错开多个 IP（如用不同代理或修改 Hosts 绑定多域名），验证
$binary_remote_addr隔离是否生效 - 把
burst设为 0，再跑一次——所有超出 rate 的请求应瞬间返回 503，响应时间几乎无波动，这是基准线
