burst和nodelay是限流可用性的关键开关：burst定义等待队列长度（不提升处理速率），nodelay关闭排队转为即决模式，二者协同决定超限请求是排队、延时还是立即拒绝。
burst 和 nodelay 不是可有可无的“锦上添花”，而是决定限流是否真正可用的关键开关。它们共同决定了请求在超出基础速率时，是排队、延时、还是立刻拒绝——这直接影响后端稳定性与用户体验。
burst 的真实作用：不是扩容，而是缓冲窗口
burst 参数定义的是一个“等待队列”的最大长度，单位是请求数，但它不改变处理速率。比如 rate=10r/s + burst=20 表示：每秒最多放行 10 个请求，但允许最多 20 个请求在队列中等待被匀速消化。
- 队列中的请求仍按 rate 节奏出队，不会加速处理；例如 burst=20 时第 21 个请求到达，若前 20 个尚未处理完，它就会被拒绝（返回 503）
- burst 值不是越大越好：设为 1000 意味着极端情况下用户可能等待上百秒才收到响应，违背服务 SLA
- 实际生效受时间粒度影响：rate=10r/s 对应每 100ms 放行 1 个，burst=20 理论上最多容纳约 2 秒的突发流量（但非精确等价）
nodelay 的本质：关闭排队，切换为“即决模式”
默认情况下，超出 rate 的请求会进入 burst 队列并等待；加上 nodelay 后，这些请求不再排队，而是立即检查桶状态——有余量就放行，没余量就 503。
- nodelay 必须和 burst 一起使用才有意义；单独写 nodelay 会被忽略
- 启用后，burst 实际变成“瞬时弹性容量”：例如 rate=10r/s + burst=20 + nodelay = 允许每秒最多突增 20 个请求（只要桶里还有令牌），超过则立刻拦截
- 适合强实时接口（如支付回调、风控校验），不能接受任何延迟，但需配合前端重试退避策略，否则易引发重试风暴
典型场景选型对照
不同业务对延迟容忍度和突发特征差异很大，参数组合需匹配真实链路行为：
- 登录接口防爆破：rate=2r/s + burst=5 + nodelay —— 严格限制单 IP 瞬时尝试，避免耗尽认证服务资源
- 商品详情页（读多写少）：rate=50r/s + burst=100 —— 允许短时热点访问排队，保持响应连贯性，不加 nodelay
- 下单接口（核心链路）：rate=30r/s + burst=10 + nodelay —— 容忍小幅突增，但拒绝长队列等待，保障事务一致性与时效
- 后台管理 API：rate=5r/s + burst=0 —— 无突发需求，直接硬限流，简化运维判断
验证与调优要点
上线后不能只看配置是否生效，要结合日志与监控确认行为符合预期：
- 在 log_format 中加入 $limit 和 $limit_key，可直观看到每个请求匹配的限流 key 和是否被限
- 观察 error 日志中 “limiting requests” 记录频次，对比 access 日志中 503 状态码比例，判断 burst 是否过小或过大
- 用 ab 或 wrk 模拟突发压测：例如 -n 100 -c 50，观察 503 出现时机是否与 burst+rate 推算一致
- zone 内存大小需匹配并发 IP 数：10m ≈ 支持 16 万独立 key，高并发业务建议设为 32m 或更高
