limit_req的delay模式通过让超限请求排队等令牌，平滑突发流量、缓解后端压力、兼顾可用性与公平性；其核心是控制burst队列中前n个请求是否立即执行，不改变rate与burst，仅调整调度策略。
用 limit_req 的 delay 模式做缓存网关的柔性速率管控，核心是让超限请求“排队等令牌”，而不是直接拒绝或硬性突刺处理。它不提升吞吐上限，但能平滑突发、缓解后端压力、兼顾可用性与公平性。
delay 模式的作用机制
delay 参数控制的是“burst 队列中前 N 个请求是否立即执行”。它不改变 rate（基础速率）和 burst（桶容量），只调整调度策略：
- 未设
delay时，默认delay=0，即所有超出rate的请求都进队列，但只有加了nodelay才会跳过排队、立刻处理 - 设了
delay=N（N ≤ burst），表示前 N 个超限请求可立即被处理，其余请求按漏桶节奏延时调度（比如每 100ms 放行一个） - 若
delay=burst，相当于关闭排队延迟，所有超限请求都立即执行——这等同于加了nodelay - 若
delay=0且没加nodelay，则超限请求全部排队，无一立即执行
适合缓存网关的典型配置逻辑
缓存网关常面临热点 key 突发访问、预热流量倾斜、客户端重试风暴等问题。此时直接 nodelay 易压垮下游缓存节点，全拒又伤体验。用 delay 可折中：
- 设定合理
rate（如 50r/s），保障缓存服务稳定吞吐 - 配置
burst=100，允许短时积压，避免瞬间打满连接数 - 设置
delay=30，即前 30 个超限请求立刻放行，后续 70 个按令牌节奏（20ms/个）匀速释放 - 配合
limit_conn控制单 IP 并发连接数（如 20），防连接耗尽
关键注意事项
delay 模式依赖 Nginx 共享内存计数器，需注意资源开销与精度边界：
- 每个 IP 状态约占 64 字节（IPv4），1MB 共享内存最多存约 1.6 万个 IP 计数器；高并发场景建议用
$server_name或业务 ID 做 key，而非粗粒度 IP - delay 调度基于系统时钟，无法保证毫秒级精确，但对缓存网关这类毫秒级响应的服务已足够平滑
- 若后端是 Redis 集群，应同步在应用层做热点 key 分片（如 hot_key_001 ~ hot_key_100），避免限流只拦住了请求，却把压力集中到单个分片
- 不要混用
nodelay和delay——二者互斥，同时出现时nodelay优先生效
效果对比：三种常见模式在缓存场景下的表现
假设配置为 rate=10r/s、burst=50：
- 纯 nodelay：第 1–50 个请求全秒级通过，可能触发 Redis 单分片 CPU >70%，引发超时或丢包
- 无 delay 也无 nodelay：第 11 个起全部排队或 503，用户感知明显卡顿或失败
- delay=20：第 1–30 个请求快速响应（含基础 10 + 前 20 个 burst），第 31–50 个请求以 100ms 间隔依次释放，Redis 负载曲线平稳上升，无尖峰
