burst缓冲区本质是可控排队窗口，非扩容手段；rate=10r/s+burst=30表示每秒处理10个请求，最多30个排队按100ms间隔放行，超队列则返503。
burst 缓冲区不是用来“扛住大流量”的，而是给瞬时业务峰值留出一个可控的等待窗口。它不提速、不扩容，只让请求排队等节奏放行——关键在“可控”二字。
burst 的真实作用：缓冲而非扩容
rate=10r/s + burst=30 表示：每秒最多处理 10 个请求，但允许最多 30 个请求在队列中等待；这些排队请求仍按每 100ms 一个的节奏被漏出，不会加速处理。
- 第 1 个请求立即通过，第 2–11 个分别在 100ms、200ms…1000ms 后放行
- 第 12–41 个进入 burst 队列，其中第 41 个要等到 4000ms 后才开始处理
- 第 42 个请求到来时若队列已满（30 个待处理），直接返回 503
burst 值怎么设才合理
不能拍脑袋填个 1000，得结合业务 SLA 和后端吞吐能力来算：
- 普通读接口（如商品详情）：burst 设为正常 QPS 的 2–3 倍，比如日常 50r/s，burst=120，可容纳约 2.4 秒突发
- 写接口（如下单）：慎用纯 burst，优先考虑 burst + nodelay 组合，避免长尾延迟破坏事务时效性
- 后台管理类接口：burst=0 更稳妥，这类请求本不该有突发，硬限流反而利于快速定位异常调用方
配合监控确认缓冲区是否真起作用
光配对没用，得看实际行为是否符合预期：
- 在 log_format 中加入 $limit 和 $limit_key，日志里能直接看到哪个 IP 或用户触发了排队或拒绝
- 观察 access 日志中响应时间分布：如果大量请求延迟集中在 200ms/400ms/600ms 等固定间隔，说明 burst 正在按漏桶节奏放行
- 搭配 Prometheus + nginx-exporter，监控 nginx_http_limit_req_rejected_total 和 nginx_http_limit_req_delayed_total 指标变化趋势
别忘了内存和 key 设计这两个隐形瓶颈
burst 再合理，也架不住 zone 内存不够或 key 粒度太粗：
- IPv4 地址状态条目约占 64 字节，10MB zone 最多存约 16 万个 IP；若业务用的是代理集群，$binary_remote_addr 会把所有用户映射成同一个 key，必须改用 $http_x_real_ip 或用户 ID
- key 设计要匹配业务防护粒度：防刷用 IP，防薅羊毛用 user_id，灰度发布用 header 中的版本标识
- zone 大小建议预留 20% 余量，避免高并发下因内存不足导致限流失效
