burst参数本质是为缓存穿透设置柔性缓冲时间窗，与rate配合将突发回源请求排队匀速转发，用时间换稳定性，而非提升吞吐；需结合源站压测能力、业务延迟容忍度及共享内存容量合理配置，并配合$uri限流、cache_lock等机制协同防护。
burst 参数在 CDN 回源场景中不是用来“扛住更多请求”的，而是为缓存穿透瞬间制造一个可控的缓冲时间窗，避免源站被毫秒级回源洪峰直接击穿。它不提升后端吞吐，只把突发请求在 Nginx 内排队匀速转发，本质是“用时间换稳定性”。
burst 的真实作用：给回源加一道柔性闸门
当大量用户同时访问未命中缓存的资源（如新上线商品页、热点文章），Nginx 会集中发起回源请求。此时 burst 和 rate 共同决定这道闸门的缓冲能力：
- rate=10r/s + burst=30 表示：每秒最多向源站发送 10 个请求，但允许最多 30 个回源请求在 Nginx 内排队等待
- 这些排队请求仍按 100ms 间隔依次发出，不会加速——相当于把 3 秒内的突发回源压力，摊平成 4 秒匀速消化
- 第 31 个请求到达时若队列已满，直接返回 503 或走 stale 缓存（需配合 proxy_cache_use_stale）
burst 值怎么设才不踩坑
不能凭经验拍脑袋，要结合回源链路实际特征交叉验证：
- 看源站真实扛压能力：压测得出源站在 P95
- 看业务可接受的额外延迟：若前端要求首字节响应 ≤ 1s，且当前平均回源耗时 120ms，则 burst 上限 ≈ (1000 − 120) / 100 × 10 ≈ 88（即最多排队 880ms）
- 看共享内存是否够用：每个 $uri 或 $host$request_uri key 占约 64 字节，zone=hoturi:10m 最多支持约 16 万个唯一 URI；若 burst 过大又 key 过细（如带 timestamp 参数），易触发 zone 溢出导致限流失效
必须搭配的关键配置
单独加 burst 对回源防护效果有限，需组合使用：
- 用 $uri 做 key，而非 IP：防止单个热门资源（如 /api/v1/product/123）引发全量回源雪崩；配置 limit_req_zone $uri zone=hoturi:10m rate=5r/s;
- 开启 proxy_cache_lock + proxy_cache_use_stale：确保同一 URI 只有一个请求真正回源，其余等待锁释放或返回过期缓存，大幅降低 burst 区内实际并发数
- 记录 $limit_req_status 和 $limit_key 到 access_log：上线后快速识别是哪个 URI 触发了限流、是否集中在特定资源，避免误判为源站故障
- 慎用 nodelay：回源场景一般不建议开启。加了 nodelay 后 burst 变成瞬时额度，30 个请求可能在 20ms 内全部打到源站——除非源站已具备秒级弹性扩容能力
典型回源限流参考值
以下基于中等复杂度 API（平均回源耗时 80–150ms）和容器化源站（支持分钟级扩缩容）：
- 静态资源回源（JS/CSS/图片）：rate=20r/s + burst=40（允许缓存预热或 CDN 驱逐后的短暂穿透）
- 动态接口回源（商品详情、用户信息）：rate=8r/s + burst=24（缓冲约 3 秒突发，兼顾响应及时性与源站安全）
- 后台管理类接口（低频、高一致性要求）：rate=2r/s + burst=0（拒绝微小超速，避免脏请求积压）
