burst不是用来扛高并发的，而是将瞬时大量请求匀速喂给后端，实现“削峰填谷”；其本质是时间换空间，通过可控缓冲摊平流量脉冲，避免连接耗尽或回源雪崩。
直接说结论：burst 不是用来扛高并发的，而是把“瞬间打过来的大量请求”，变成“匀速喂给后端”。静态服务本身处理快、无状态，真正怕的不是 QPS 高，而是短时脉冲压垮连接数、触发上游超时或触发 CDN 回源雪崩。用对 burst，关键在缓冲、可控、不甩锅。
burst 的真实作用不是提速，是“削峰填谷”
静态资源（如 JS、CSS、图片）常被前端批量加载或缓存失效后集中回源。比如 1 秒内涌进 300 个 /static/logo.png 请求，后端 Nginx 若直接全量转发到磁盘或 upstream，可能瞬间打开数百文件句柄，或触发代理层连接耗尽。
这时设 rate=50r/s + burst=100，效果是：
- 前 50 个请求立即响应（静态服务本就毫秒级）
- 后续 100 个请求进入缓冲区，按每 20ms 一个的节奏依次处理
- 整批 300 请求被拉伸到约 3 秒内完成，避免瞬时毛刺
注意：它没让服务变快，但让压力曲线从“尖刺”变成“缓坡”，给系统留出喘息余地。
burst 值不能拍脑袋，要匹配静态服务特性
静态服务瓶颈通常不在 CPU，而在：
- 文件系统 I/O 并发能力（如 ext4 单目录 inode 密度、SSD 随机读吞吐）
- 网络连接复用效率（keepalive 超时、worker_connections 设置）
- CDN 回源带宽/连接数限制（若走反向代理）
所以 burst 推荐这样定：
- 先压测单节点静态服务：在 P95 延迟 ≤ 20ms 下，可持续承载多少并发请求？假设是 80 QPS → rate 设为 60–70r/s
- 再看历史突增特征：某次缓存失效后，/static/ 目录 0.3 秒内来了 120 请求 → burst ≥ 120 − 70 × 0.3 ≈ 100
- 最后卡用户容忍：静态资源排队超过 500ms 用户会感知卡顿 → burst ≤ 500ms × rate = 35（若 rate=70）→ 取交集，选 burst=35 更稳妥
搭配 nodelay 要特别小心——静态资源通常不该开
对静态资源加 nodelay，等于把缓冲区取消，burst 变成“瞬时放行额度”。例如 rate=70r/s + burst=35 + nodelay，就是允许 1 秒内最多 105 个请求立刻打到文件系统——这反而制造了新尖峰。
只在两种情况考虑 nodelay：
- 你用的是内存文件系统（如 tmpfs），且确认其随机读并发远超 burst 值
- 你做了强隔离：每个静态 location 独立 zone，且该 zone 专用于高频小图（如头像），其他大资源走另一套限流
绝大多数场景下，保留默认排队行为更安全：Nginx 内部调度稳定，不会把压力转嫁给磁盘或 upstream。
必须配合的两个实操细节
光写 burst 不够，还得盯住两件事：
- log_format 加 $limit_req_status：区分哪些是正常（passed）、哪些排队（delayed）、哪些被拒（rejected）。如果 delayed 占比高且平均延迟 >300ms，说明 burst 偏大或 rate 偏小
- zone 大小要够用：静态资源常按 IP 或 URI 限流。若用 $uri 作 key，10MB zone 最多支持约 16 万个不同路径；若站点有上万张图，又按 URI 细粒度限流，zone 很快溢出，限流失效
推荐做法：静态资源优先按 $binary_remote_addr 分流，再辅以 全局 rate + 合理 burst，既控住单 IP 扫描，又保整体平滑。
