limit_req_zone不支持分布式限速，因其共享内存区仅本机worker可见；多实例下计数器完全独立，必须用Redis+Lua等外部状态中心替代实现全局限速。

直接看核心：limit_req_zone 本身是 Nginx 单机模块，**不支持分布式共享状态**。它在多实例反代场景下天然无法实现“全局限速”，更谈不上“无感知”。所谓“无感知反代全局限速”，必须绕过 limit_req_zone 的单机限制，用外部统一状态系统替代。

为什么 limit_req_zone 不能直接用于分布式限速

它依赖内存共享区（shared memory zone），该区域仅限本机 worker 进程间可见。即使你用 keepalive 或 upstream hash 做负载均衡，不同 Nginx 实例的计数器完全独立——用户 A 在实例1被限1次，在实例2仍可发起100次请求。这不是“全局限速”，是“每台机器各自限速”。

常见误操作包括：

• 把 limit_req_zone 配置写在 upstream 外层，误以为能跨实例生效
• 用 nginx-sticky 或 ip_hash 强制用户固定到某台，但这违背“无感知”和高可用原则（节点故障即中断）
• 依赖 Redis + lua-resty-limit-traffic 但未做连接池/失败降级，导致延迟飙升或雪崩

真正可行的分布式全局限速架构

关键不是“怎么调 limit_req_zone”，而是“用什么替代它”。主流可靠方案是：Nginx（反代层） + Lua 脚本 + 外部状态中心（如 Redis Cluster）。

• 状态中心选型：优先用 Redis Cluster（非单点），开启 lazyfree 和 maxmemory-policy=volatile-lru；若对一致性要求极高，可用 etcd + 分布式锁，但延迟更高
• 计数粒度设计：按 client_ip、user_id、api_key 三者之一作为 key 前缀；避免用完整 URI（太长且易被构造绕过）；加时间窗口哈希（如 “rate:ip:192.168.1.100:2026050910”）防热点
• Lua 脚本逻辑：使用原子命令 INCR + EXPIRE（或 Redis 6.2+ 的 INCRBYEX），单次 RTT 完成判断；失败时 fallback 到本地 limit_req_zone 保底，不阻断请求
• 内存预估公式：单 key 约占 64 字节（Redis string 类型），若支持 100 万并发用户、1 秒窗口、每用户 100 QPS，则峰值 key 数 ≈ 100 万 × 100 = 1 亿；内存 ≈ 1 亿 × 64B ≈ 6.4 GB（不含 Redis 自身开销，建议预留 2 倍）

如何做到“无感知”切换与容错

用户不该因限速模块异常而收到 500 或超时。需在 Lua 层控制行为边界：

• Redis 连接超时设为 5ms，失败后立即走本地内存计数（limit_req zone）并记录 warn 日志
• 对 write 操作（INCR）失败，读操作（GET）仍可尝试，保证降级逻辑可用
• 用 shared dict 缓存最近 1 分钟的限速结果（如 “ip:xxx:allowed:true”），减少 Redis 查询频次，但需设置短 TTL（如 10s）防 stale
• 通过 OpenResty 的 balancer_by_lua 动态剔除异常 Redis 节点，配合健康检查自动恢复

补充：别忽略上游服务的真实瓶颈

限速目标不是压测 Redis，而是保护后端模型服务。需同步做：

• 在 vLLM / TensorRT-LLM 等推理引擎侧启用 request-level queue（如 vLLM 的 max_num_seqs），防止请求堆积挤爆 GPU 显存
• 将限速阈值与 GPU 利用率（nvidia-smi dmon）联动：当 GPU util > 90% 且持续 30s，自动下调全局 QPS 上限 20%
• 对 Prefill/Decode 阶段分别限速：Prefill 耗 CPU 和显存带宽，Decode 耗 KV Cache 容量，二者资源冲突模式不同