burst模式是为瞬时流量提供可控缓冲窗口，防止突发请求集中穿透缓存层引发雪崩；它不提升吞吐，仅排队缓冲，需按缓存能力、延迟容忍与内存限制合理配置，并分级隔离路径、配套监控验证。
burst 模式不是用来“撑住更多缓存请求”的，而是给瞬时流量一个可控的缓冲窗口，防止突发请求集中穿透到缓存层（如 Redis、Memcached），避免连接打满、超时堆积或雪崩式回源。
burst 的真实作用：为缓存层争取响应节奏
缓存系统对并发连接和短时 QPS 敏感，尤其在缓存失效、预热或热点 key 集中访问时。burst 不提升吞吐，只提供排队缓冲：
- rate=50r/s + burst=100 表示：每 20ms 放行 1 个请求，最多允许 100 个请求排队——相当于把 2 秒内的突增请求（比如 150 个）摊平成约 3 秒匀速转发
- 排队请求仍在 Nginx 内存中等待，不新建后端连接，也不触发缓存 miss 回源洪峰
- 若 burst=0，则毫秒级抖动（如两个请求间隔 19ms）就会返回 503，缓存层看似“清净”，但前端可能因重试反而加剧冲击
burst 值必须匹配缓存能力，而非拍脑袋填大数
设得过大，会把延迟压力转嫁给缓存；设得太小，又起不到缓冲作用。关键看三方面：
- 缓存平均响应时间：若 Redis P95 耗时约 8ms，单节点稳定吞吐 8000 QPS，则 burst 可按 rate × 0.1～0.3 秒估算（例如 rate=200r/s → burst=20～60）
- 可接受的最大排队延迟：若业务要求缓存命中请求端到端 ≤ 100ms，则 burst ≤ rate × 0.1（如 rate=100r/s → burst≤10）
- 共享内存容量限制：每个 IP 或用户 key 占约 64 字节，若用 $http_x_user_id 做 key，日活百万用户需 zone ≥ 64MB，否则旧记录被挤出，限流失效
区分缓存路径，分级配置 burst
不能所有接口共用一套限流规则，要按风险和语义隔离：
- 读缓存路径（如 /api/item/{id}）：可设 rate=100r/s + burst=150，允许短暂穿透，缓解缓存击穿
- 写缓存路径（如 /api/cache/refresh）：建议 rate=5r/s + burst=5 + nodelay，宁可快速失败，也不让批量刷新压垮 Redis 写队列
- 健康检查或监控探针（如 /health/cache）：rate=100r/s + burst=0，确保探测不被业务流量阻塞，同时不干扰限流统计
- 带参数的动态路径（如含 timestamp 或随机 query）：避免用 $uri 做 key，改用规范化后的 key（如 $host$upstream_cache_key），防 key 爆炸导致 zone 耗尽
必须配套验证与防护，光配 burst 不够
限流是否真生效，得靠日志和指标说话：
- 在 log_format 中加入 $limit 和 $limit_key，观察哪些用户 ID 或 IP 触发了排队或拒绝
- 开启 limit_req_log_level warn，不只是等 503 出现才记录，要看 excess 值变化趋势
- 搭配 limit_conn 控制单客户端并发连接数（如 limit_conn perip 20），防慢连接耗尽 worker_connections
- 监控 nginx_http_limit_req_delayed_total 和 redis_connected_clients 曲线，若前者上升而后者陡增，说明 burst 过大或 nodelay 使用不当，正在向缓存施加瞬时并发压力
