burst模式的核心是提供可控缓冲窗口而非扩容，其缓冲时长≈burst/rate（秒），如rate=20r/s+burst=60可缓存3秒突发请求；burst=0关闭缓冲，nodelay将burst转为瞬时额度但需配退避重试；过大burst易致尾延迟失控和上游压力转移，应依业务特征合理设定并结合日志验证。

burst 模式不是用来“扛住更多请求”的，而是给突发流量一个可控的缓冲窗口，让系统不因毫秒级抖动就崩掉。关键在“控”不在“扩”。

burst 的真实作用：制造安全缓冲时间窗

burst 值和 rate 共同决定你能容忍多长的突发空档期，近似公式是：缓冲窗口 ≈ burst / rate（秒）。比如 rate=20r/s + burst=60，理论可吸收约 3 秒内的密集请求而不拒绝——这 3 秒内进来的请求不会立刻压垮后端，而是在 Nginx 内排队，按每 50ms 一个的节奏匀速转发。

• 这个缓冲区存在于 Nginx 进程内存中，不增加后端并发连接数，只延长部分请求的端到端延迟
• burst=0 相当于关闭缓冲，任何微小超速（比如两个请求间隔 49ms）都会触发 503
• burst 设为 100 而 rate=1r/s，意味着可能有请求等待上百秒，违背服务 SLA，不可取

搭配 nodelay：把缓冲转为瞬时弹性，适用于强实时链路

加 nodelay 后，burst 不再是“排队池”，而是“即用额度”。例如 rate=30r/s + burst=15 + nodelay，表示：每秒前 45 个请求都可立即放行（首 30 个按规则，后 15 个走 burst 额度），第 46 个起才严格按 33.3ms 间隔处理。

• 适合下单、支付回调、风控校验等不能接受排队延迟的接口
• 必须配合前端退避重试（如指数退避），否则用户连续点击会瞬间打满 burst 额度，造成上游并发激增
• nodelay 单独写无效，必须和 burst 同时出现才生效

避免常见误用：burst 不是越大越稳

过大的 burst 会掩盖真实瓶颈，带来两类风险：

• 尾延迟失控：用户看到 HTTP 200，但响应耗时从 100ms 拉长到 2s+，监控里却无错误，排查困难
• 上游压力转移：尤其开启 nodelay 后，burst 区内请求被集中转发，可能让后端数据库或缓存瞬间被打穿
• 建议按业务典型突发特征设定：登录接口 burst=5～10，商品页 burst=50～100，后台管理 API 可设为 0

验证是否真正生效：别只看配置，要看日志和 excess 行为

在 log_format 中加入 $limit 和 $limit_key，能直接看到每个请求是否命中限流、用了哪个 key、excess 当前值是多少。真实环境中常发现：

• burst=10 却第 15 个请求才被拒——因为前几个请求间隔较长，excess 已随时间衰减
• 大量 200 日志伴随后端超时——极可能是 nodelay + 大 burst 导致瞬时并发翻倍
• 需配合 limit_conn 控制连接数，防止 burst 缓冲区被单个恶意连接占满