burst是超额请求数上限，单位为1000等效请求单位；配合rate决定突发容忍窗口，需合理配比而非盲目增大；nodelay跳过排队但不跳过burst计数，应分级配置并配套监控调优。

burst 缓冲区不是排队队列，而是允许超额请求“赊账”的信用额度。它配合 rate 共同决定系统能容忍多长一段突发窗口，关键在合理设定二者比例，而不是盲目堆大 burst。

burst 的真实含义是“超额请求数上限”，单位是等效请求

每个请求在 Nginx 内部记为 1000 单位，burst=20 表示最多允许累积 20000 单位的超额信用。这个 credit（excess）会随时间按 rate 自动衰减——比如 rate=10r/s，每秒释放 10000 单位；若两次请求间隔超过 1 秒，excess 就会回落。

• burst=1 实际对应 1000 单位，不是“能塞下 1 个请求”
• burst=50 + rate=5r/s → 理论缓冲窗口 ≈ 10 秒（50 ÷ 5）
• 第 6 个请求没被限，可能是因为前几个请求之间空隙太大，excess 已部分清零

burst 和 rate 要搭配使用，避免失衡

单独调高 burst 或 rate 都可能带来副作用：rate 太小而 burst 过大，会导致请求在缓冲区积压太久，延迟飙升；rate 太大但 burst=0，则退化为严格漏桶，连毫秒级抖动都会被拒。

• 秒杀预热场景推荐：rate=5r/s + burst=50（10 秒容错窗）
• 登录接口可设：rate=20r/s + burst=40（2 秒突发缓冲）
• 健康检查接口建议：rate=100r/s + burst=0，避免干扰监控

nodelay 不是关闭限流，而是改变响应方式

加了 nodelay 后，超出速率的请求不会等待，而是立即通过（但仍计入 excess）。它不跳过 burst 缓冲区，只是跳过排队等待过程。是否启用需确认后端能否扛住 burst 规模的瞬时并发。

• 支付下单类接口适合开启 nodelay，失败比长延迟更可接受
• 必须配套前端退避重试机制，否则 503 后密集重发易引发雪崩
• 不要全局加 nodelay，应按接口重要性分级配置（如 /login 开，/search 关）

排查和调优离不开日志与监控

默认 limit_req 日志只记录 error 级别（即 503 拒绝），建议显式配置 log_format 包含 $limit 和 $limit_key，并把 limit_req_log_level 设为 warn，这样能看清哪些 IP 或用户 ID 触发了限流、是排队还是被拒。

• 在 http 块中添加：limit_req_log_level warn;
• 自定义日志格式加入：$limit $limit_key 变量
• 观察 access.log 中 excess 值变化趋势，判断 burst 是否设置偏小或偏大