未配置burst时Nginx高速率限流失效问题咨询

你的问题核心在于无burst参数时，Nginx的limit_req采用严格的“零突发”限流逻辑，和你对时间槽的理解存在偏差，具体原因如下：

1. 无burst时的限流逻辑本质 #

当未配置burst时，Nginx的令牌桶容量默认为1，这意味着：

• 令牌按配置的rate匀速生成（你的配置是30000000r/s，即每0.033微秒生成1个令牌）
• 每个请求必须获取到当前已生成的令牌才能被处理，不允许任何形式的突发请求
• 如果多个请求在同一时刻（或极短时间内）到达，即使总速率远低于配置的rate，超过当前可用令牌数量的请求会直接被拒绝

比如你测试的1000rps场景，压测工具通常是批量并发发送请求，同一毫秒内可能有多个请求同时到达。此时令牌桶中只有1个可用令牌（令牌是逐步生成的，Nginx不会等待后续令牌生成再处理），所以只能处理1个请求，其余都会被拦截，最终实际能处理的速率会远低于预期。

2. burst + nodelay的作用 #

配置burst和nodelay后，限流逻辑发生了两个关键变化：

• burst扩展了令牌桶的容量，允许临时存储超出当前令牌数量的请求，避免瞬间并发请求被直接拒绝
• nodelay允许缓冲中的请求立即被处理，无需等待令牌生成，只要后续生成的令牌能补上这些“预支”的额度

这就解决了请求突发到达的问题，让Nginx能稳定处理到配置的速率上限。

3. 关于“毫秒级时间槽”的误解 #

Nginx官方提到的毫秒级时间槽，是令牌生成的时间计算单位，但并非按时间槽批量放行请求。在无burst的情况下，Nginx仍然是逐个检查请求的令牌可用性，只有请求到达节奏完全匹配令牌生成节奏时，才能达到配置的rate——而实际场景中这种完美均匀的请求分布几乎不可能实现。

内容的提问来源于stack exchange，提问作者Dmitry Kalach