nginx的limit_req模块不提供负载均衡功能，仅通过delay模式（burst+delay）实现请求速率整形，将突发流量摊平为匀速队列以缓解后端压力；需配合upstream的least_conn等策略及合理缓冲设置才能间接提升集群稳定性与资源利用率。
nginx 的 limit_req 模块本身不提供负载均衡功能，也不直接参与上游服务器的分发决策；它的 delay 模式（即配合 burst 和 nodelay 的反向使用）主要用于请求速率整形——把突发流量“摊平”成近似匀速的队列，从而缓解后端压力。这种平滑效果可间接提升负载均衡集群的整体稳定性与资源利用率，但需明确：它不替代 upstream 或 proxy_pass 的分发逻辑。
理解 delay 模式的实际行为
当配置 limit_req zone=foo burst=10 delay=5; 时：
- burst=10 表示允许最多 10 个请求排队等待处理（超出即 503）
- delay=5 表示：只要队列中等待请求数 ≥ 5，新请求就进入延迟队列；少于 5 则立即放行（不排队）
- 排队请求按令牌桶节奏（由 rate 决定）逐个释放，例如 rate=10r/s → 每 100ms 放行 1 个
- 效果是：突发流量被“拉长”，后端收到的请求时间间隔趋近均匀，避免瞬间打满单个 upstream 节点
与 upstream 协同实现平稳分发的关键配置
要让整形后的请求更均衡地落到后端节点，需结合以下策略：
- 启用 upstream 的 least_conn 或 random（带 consistent）：避免轮询在请求变慢时仍机械分发，优先导向活跃连接少或响应快的节点
- 设置合理的 proxy_buffering off + proxy_buffer_size 小值：减少 nginx 缓存响应体带来的延迟感知偏差，使限流释放节奏更贴近真实后端处理节奏
- 为不同 upstream 分组单独定义 limit_req zone：例如按业务线或地域划分 zone，避免高流量接口拖累低频接口的排队机会
- 配合 $binary_remote_addr 或 $server_name 做 key：防止单个客户端或虚拟主机独占 burst 队列，保障多租户/多服务间的公平性
典型配置示例（含注释）
（放在 http 或 server 块中）
limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
upstream backend_cluster {
least_conn;
server 192.168.1.10:8080 max_fails=2 fail_timeout=10s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=10s;
}
<p>server {
location /api/ {
limit_req zone=perip burst=30 delay=10; # 允许最多30排队，≥10才开始延迟
proxy_pass <a href="https://www.php.cn/link/26a9c7ab6107b61166fbbc7e64756a1f">https://www.php.cn/link/26a9c7ab6107b61166fbbc7e64756a1f</a>;
proxy_set_header X-Real-IP $remote_addr;
}
}</p>
该配置使单 IP 突发 50 请求时：前 10 个立即发出，中间 20 个按 50ms 间隔（因 rate=20r/s）依次转发，最后 20 个被拒绝。后端节点收到的请求流接近恒定 20qps，利于 CPU/DB 连接池稳定复用。
注意事项与常见误区
delay 不是缓冲池大小，而是触发排队的阈值——误设过小（如 delay=1）会导致轻微波动就排队，增大平均延迟；过大（如 delay=burst）则几乎无延迟效果。
- 不建议在 HTTPS 入口全局启用 high burst+low delay：TLS 握手和首字节延迟会干扰令牌桶计时精度
- 若后端有强会话依赖（如 sticky session），需确保同一用户始终命中相同 zone key，否则 delay 队列状态无法复用
- 监控重点应是
limit_req_status变量（需开启 log_format）和 upstream response time 分布，而非单纯看 503 数量
