limit_req_zone 无法实现分布式全局限速，因其 zone 仅限单机共享内存，节点间状态不互通；真正无感知全局限速需 Redis + Lua 实现原子令牌桶，辅以 Nginx 本地缓存和降级机制。

直接说结论：limit_req_zone 本身无法实现分布式全局限速，它只是单机限流工具。所谓“通过 limit_req_zone 实现分布式全局限速”，本质是放弃其共享内存机制，转而用 Redis + Lua 做全局令牌桶，再用 Nginx 的本地缓存做性能兜底——limit_req_zone 在这里仅作配置参考或降级备用，不承担核心限流逻辑。

为什么不能直接用 limit_req_zone 做全局限速

limit_req_zone 的 zone（如 zone=ip_limit:10m）是 Nginx worker 进程间共享的内存段，只存在于当前机器。这意味着：

• 节点重启后，所有计数清零，用户瞬间被放行，可能触发后端雪崩
• 横向扩缩容时，新节点无历史计数，老节点负载不均
• 故障切换过程中，限速状态断裂，出现“突增流量”或“误拦截”
• 不同节点对同一用户（如相同 IP 或 token）的计数完全独立，无法达成全局一致

真正的无感知全局限速架构组成

核心思路：**状态外置 + 原子操作 + 本地缓存 + 故障平滑回退**

• Redis 集群：作为唯一可信源，存储每个限速维度（如 user:123、api:/v1/chat）的剩余令牌数和最后刷新时间
• 原子 Lua 脚本：每次请求调用 EVAL 执行补桶+扣桶逻辑，避免并发竞争，保证单 key 操作强一致
• Nginx lua_shared_dict：在 worker 内存中缓存热点 key 的令牌数（带 TTL），降低 Redis 访问频次，延迟从毫秒级降至微秒级
• 熔断与降级：当 Redis 不可用时，自动切到本地 limit_req_zone 或固定速率放行，避免全站限流失效

内存预估要算两笔账

不是只看一个“10m”，而是分层评估资源水位：

• Redis 层内存：按 key 数 × 单 key 开销估算
  例如：100 万用户 ×（key 名长度 + 8 字节整型值 + 过期字段）≈ 100–120 字节/key → 总需约 100–120MB；再加 AOF 缓冲、复制积压、30% 冗余 → 建议预留 160–200MB
• Nginx 本地缓存：用 lua_shared_dict rate_cache 10m 定义
  若缓存 5 万个活跃 key，每个缓存项含 key 字符串、剩余令牌、TTL 时间戳，约 256 字节 → 5w × 256B ≈ 12.5MB，10MB 稍紧但可接受

关键细节决定是否真“无感知”

切换节点、发布更新、Redis 故障时仍保持限速连续，靠的是这些设计：

• Redis key 的 TTL 必须显式设置（如 60 秒），且 Lua 脚本中 refresh 逻辑严格基于时间差计算补发令牌，而非依赖 Redis 过期删除
• 本地缓存项必须携带“最后同步时间戳”，过期后强制回源 Redis，不使用 stale 数据续命
• 限速维度要合理聚合：避免用原始 IP（易变），优先用登录态 user_id、device_id 或 API 路径+method 组合
• OpenResty 中推荐在 access_by_lua* 阶段调用限流逻辑，早于 rewrite 和 proxy_pass，确保未达后端即拦截