burst模式不提升吞吐，而是提供可控缓冲窗口以整形瞬时流量；rate=30r/s+burst=90表示每33.3ms放行1个请求，最多90个排队匀速漏出，真实缓冲时长约3秒，需结合后端能力合理设定。
burst 模式本身不增强负载均衡器的吞吐能力，而是为瞬时峰值提供可控缓冲窗口，防止突发请求未经节制地穿透到后端服务。它让 Nginx 在反代层承担“流量整形”职责，把秒级洪峰摊平成毫秒级匀速转发，从而避免 LB 后端节点被瞬间打满连接或压垮资源。
burst 的作用不是扛压，是控流延时
rate=30r/s + burst=90 表示：每 33.3ms 放行 1 个请求，最多允许 90 个请求排队等待。这些排队请求不会加速处理，而是严格按节奏漏出——相当于把 3 秒内的突增请求（比如 120 个）延展成约 4 秒匀速消化（前 30 个即时放行，后 90 个排队补位）。这给后端争取了喘息时间，也避免 LB 因连接激增、超时堆积而自身失稳。
- burst=0：关闭缓冲，任何微小超速（如两个请求间隔 32ms）即返回 503
- burst 过大（如 1000）：尾部请求可能排队等待超 30 秒，表面 HTTP 200，实则 SLA 彻底失效
- 真实缓冲时长 ≈ burst / rate（单位：秒），但受毫秒级离散判断影响，并非精确线性
burst 值必须结合后端实际吞吐设定
不能脱离后端能力拍脑袋填数字。例如压测确认单节点稳定吞吐为 40 QPS、平均响应 120ms，则：
- rate 应略低于该值（如设 35r/s），留出安全余量
- burst 可按历史最大突增特征设计：若抢购前 1.5 秒流量达 90 QPS → 突增冗余量 = (90 − 35) × 1.5 ≈ 82 → burst 取 80～100 较合理
- 若业务要求 P99 响应 ≤ 600ms，则 burst ≤ 35 × 0.6 ≈ 21，此时需权衡是调低 burst 还是提升后端能力
必须与负载均衡场景协同配置
单纯加 burst 不足以保障 LB 层稳定，还需匹配实际部署结构：
- 区分接口粒度：/health 接口用独立 zone（如 zone=health:1m rate=100r/s burst=0），避免健康检查被业务突发阻塞；核心下单路径单独配置（如 rate=20r/s burst=10），宁可快速失败也不拖垮事务链路
- 适配真实客户端标识：若 LB 前有 CDN 或四层代理，$binary_remote_addr 会失效，须改用 $http_x_real_ip 或业务用户 ID 作为 limit_req_zone 的 key
- 配合 limit_conn 防连接耗尽：burst 缓解请求频率压力，limit_conn 控制单 IP 并发连接数（如 limit_conn perip 10），二者构成基础防护双保险
- 监控验证是否生效：log_format 中加入 $limit_key 和 $limit_req_status，观察 rejected/delayed 分布；延迟集中出现在 33ms/66ms/99ms 等固定间隔，说明 burst 正在按漏桶节奏工作
nodelay 要慎用，尤其在 LB 场景下
加 nodelay 后，burst 不再是排队缓冲，而是瞬时额度。例如 rate=30r/s + burst=30 + nodelay，等于允许 1 秒内最多 60 个请求立刻打到后端——这对 LB 来说风险极高：
- 可能瞬间击穿后端数据库连接池或缓存并发上限
- 若前端无指数退避重试，用户连续点击会快速耗尽 burst，造成上游并发雪崩
- nodelay 必须和 burst 同时出现才生效，单独写无效
仅建议用于极短时延要求的强实时链路（如风控回调），且必须配套前端退避策略与后端弹性能力（如自动扩缩容）。
