burst模式本质是可控缓冲而非扩容，定义等待队列长度（单位：请求数），不改变rate设定的长期速率；其合理取值需结合后端响应时间、可接受排队延迟及共享内存容量，并须与接口粒度配置、日志记录和连接数限制协同使用。
burst 模式本身不提升处理能力，而是为突发流量提供可控缓冲，让后端免于被瞬间洪峰冲垮。关键不在“放多少”，而在“怎么放、放多久、放给谁”。
burst 的真实作用：不是扩容，是缓冲窗口
burst 定义的是等待队列长度，单位是请求数，它不改变 rate 设定的长期处理速率。比如：
- rate=20r/s + burst=40：每秒最多处理 20 个请求，但允许最多 40 个请求排队等待；
- 这些排队请求仍按 50ms 一个（20r/s ≈ 每 50ms 放行 1 个）匀速出队，不会加速；
- 第 41 个请求到达时，若队列已满且前序请求尚未漏完，就会被直接拒绝（返回 503）。
所以 burst 值不是越大越好——设为 1000，意味着用户可能排队等上 50 秒才被处理，严重违背服务 SLA。
合理设置 burst 值的三个依据
不能拍脑袋填数字，需结合业务特征与基础设施实际：
- 后端平均响应时间：若 upstream 平均耗时 100ms，burst 可设为 rate × 1～2 秒，即短时容纳 1～2 秒的积压；
- 可接受的最大排队延迟：如 SLA 要求 P99 响应 ≤ 800ms，则 burst ≤ rate × 0.8；
- 共享内存容量：每个限流 key（如 IP）在 zone 中占用约 64 字节，burst 过大会快速耗尽 zone 内存，导致限流失效（Nginx 回退为无限制）。
必须搭配的配置要点
单独加 burst 不足以保障稳定，需组合使用：
- 区分接口粒度配置：/health、/login、/api/order 应使用不同 zone 或不同 burst，避免健康检查被业务突发拖垮；
- 开启 limit_req 日志字段：在 log_format 中加入 $limit 和 $limit_key，出问题时能立刻定位是哪个 IP 或用户触发了限流；
- 配合 limit_conn 控制连接数：burst 缓解请求频率压力，limit_conn 防止单 IP 占满 worker_connections，二者构成基础防护双保险。
典型参考值（非通用，需压测验证）
以下数值基于中等复杂度 Web API（平均响应 80–120ms）和容器化后端（支持分钟级弹性伸缩）：
- 用户登录接口：rate=3r/s + burst=6（防暴力尝试，缓冲约 2 秒突发）；
- 商品详情页（读多写少）：rate=100r/s + burst=150（允许热点缓存穿透时短暂排队）；
- 下单核心路径：rate=50r/s + burst=10（宁可快速失败，也不让长队列拖垮事务一致性）。
