Nginx的delay参数实现柔性限流：配合burst启用请求排队，超额请求暂存内存并按令牌桶节奏放行，避免瞬时丢弃；delay=10表示最多10个请求排队，超时1秒未处理则返回429。
通过 limit_req 的 delay 参数，Nginx 能在限流基础上实现“柔性整形”——即允许短暂突发流量排队等待而非直接拒绝，从而兼顾系统稳定性与用户体验。
delay 参数的核心作用：启用请求排队缓冲
默认情况下，limit_req 在超出速率限制时直接返回 503（或自定义状态码）。加入 delay 后，Nginx 会将超额但可接受的请求暂存进队列，按令牌桶节奏逐个放行。这避免了因瞬时毛刺导致大量请求被粗暴丢弃。
-
delay=10表示最多允许 10 个请求排队等待（单位为请求数，非时间） - 排队请求不占用后端连接，只在 Nginx 内存中暂存，超时未被处理则自动丢弃（默认超时 1 秒，可通过
burst+nodelay组合对比理解） - 必须配合
burst使用，例如burst=20 delay=10：总容量 20，其中前 10 个立即处理，后 10 个进入延迟队列
典型配置示例：反向代理场景下的柔性限流
假设后端服务最大稳定吞吐为 100 r/s，但能容忍短时排队：
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
server {
location /api/ {
proxy_pass http://backend;
limit_req zone=api burst=200 delay=100;
limit_req_status 429;
}
}
说明：
– 每秒生成 100 个令牌；
– 最多接纳 200 个请求（含排队）；
– 其中 100 个即时处理，剩余 100 个进入延迟队列，按每 10ms 一个的速度释放（100r/s ≈ 10ms/req）；
– 若某请求在队列中等待超 1 秒仍未获得令牌，则返回 429。
关键注意事项与调优建议
-
delay值不宜过大，否则积压请求拉长整体响应延迟，反而影响 SLA；建议设为burst的 50%~80% - 需配合
proxy_buffering on和合理proxy_buffers设置，避免排队请求因缓冲区不足被中断 - 监控
ngx_http_limit_req_module暴露的变量（如$limit,$limit_rate）或使用 OpenResty + Prometheus 抓取排队时长分布 - 对低延迟敏感接口（如实时消息推送），慎用
delay，优先考虑更激进的限流或客户端重试退避
与 nodelay 的对比：刚性 vs 柔性策略
nodelay 会跳过排队，所有超出 burst 的请求立刻拒绝；而 delay=N 相当于把 burst 拆成「即时窗口 + 缓冲窗口」两段。前者适合防刷、保底线，后者适合平滑流量、提升可用率。
不复杂但容易忽略：真正起柔性作用的不是 delay 本身，而是 burst 和 delay 的差值所定义的缓冲深度，以及后端实际消化能力是否匹配该深度。
