burst模式不提升吞吐，而是通过可控缓冲将突增请求摊平到时间轴上，避免后端瞬时过载；其本质是“时间换空间”，burst值决定排队长度，实际缓冲时长约等于burst/rate，需结合后端吞吐、历史峰值和用户可接受等待时长三维度合理设定。
burst 模式本身不提升系统吞吐能力，而是通过可控缓冲，把突增请求“摊平”到时间轴上，避免后端被瞬间压垮。关键在于合理设定 burst 值，并配合 rate 与后端实际处理节奏对齐。
burst 的真实作用：不是扩容，是时间换空间
rate=50r/s + burst=100 表示：系统每 20ms 放行 1 个请求，但允许最多 100 个请求排队等待。这些请求不会加速处理，而是严格按 20ms 间隔依次出队。相当于把 1 秒内 150 个请求的冲击，延展成约 2 秒内匀速消化（前 50 个按节奏放行，后 100 个排队补位）。
- burst 不等于并发数，它只定义等待队列长度；超出队列的请求直接返回 503
- 过大的 burst（如 1000）会导致尾部请求等待超 20 秒，违背服务 SLA，应结合 P95 响应时长反推上限
- 实际缓冲时长 ≈ burst / rate，但受毫秒级离散判断影响，并非精确线性
如何设置合理的 burst 值
不能拍脑袋定数字，要从三个维度交叉验证：
- 后端单节点稳定吞吐：压测得出其在低延迟下可持续处理的 QPS，比如为 60，则 rate 应略低于该值（如设 50），burst 则按峰值冗余设计（如历史最大突增为 80 QPS，持续 0.5 秒 → burst ≥ 40）
- 用户可接受等待时长：若业务要求 99% 请求响应
- 内存与 key 粒度匹配：zone 大小需支撑预期 key 数量，例如 zone=byip:10m 约支持 16 万个 IP；若 burst 过大又 key 过细（如 "$uri$arg_user_id"），易触发 zone 溢出导致限流失效
burst 必须和 rate 协同调优，而非孤立配置
单独加大 burst 而不调整 rate，只会拉长排队延迟，不缓解后端压力。正确做法是：
- 先用 rate 锁定基础服务能力（如核心接口 rate=30r/s）
- 再根据典型突发特征设 burst（如抢购前 2 秒流量翻 3 倍 → burst ≈ 2 × 30 = 60）
- 上线后通过 $limit_req_status 日志观察 rejected/delayed 分布，若 delayed 占比过高且延迟超标，说明 burst 偏大或 rate 偏小
搭配 nodelay 要谨慎：它让 burst 失去缓冲意义
加了 nodelay 后，burst 不再是队列，而是瞬时配额。此时 burst=100 + nodelay 相当于允许 1 秒内突增 100 个请求立刻打到后端——这只有在后端具备短时弹性（如自动扩缩容）且前端有退避重试时才安全。
- 读多写少类接口（如商品详情页）建议用 burst + 无 nodelay，靠排队平滑流量
- 强实时写操作（如下单、支付回调）若必须用 burst，应搭配较小值（如 burst=5）+ nodelay，并确保下游已压测验证
- 切忌全局 location 都加 nodelay，否则限流形同虚设
