limit_req_zone无法实现分布式全局限速，因其仅在单机共享内存中维护独立计数器，多实例间不同步，导致超限放行、无法按业务维度统一控制、重启扩缩容引发窗口突刺。
直接用 limit_req_zone 无法实现真正的分布式全局限速，它只是 Nginx 单机维度的共享内存限流机制，不跨节点同步状态。所谓“无感知的全局流量限速”，本质是要求所有服务实例对同一限流规则（如某用户、某接口）执行统一计数和判定，而 Nginx 的 limit_req_zone 仅在本机 worker 进程间共享，不同机器之间完全隔离。
为什么 limit_req_zone 不适合分布式全局限速
该指令基于 Nginx 共享内存区（shared memory zone），数据只驻留在当前 Nginx 实例内存中：
- 多个 Nginx 实例（如部署在不同 Pod 或服务器上）各自维护独立的计数器，没有协调机制；
- 例如配置
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s，10 台 Nginx 就可能放行最多 100 r/s，远超预期阈值； - 无法支持按业务维度（如 user_id、app_key、tenant_id）做精细化、一致性的全局控制；
- 重启或扩缩容会导致计数清零，产生“窗口突刺”，违背稳定性目标。
真正可行的分布式全局限速替代方案
要达成“无感知”的体验（即业务方无需区分调用路径、限流逻辑透明生效），需将限流决策中心化或强一致性同步：
- 网关层统一接入 + Redis + Lua 原子脚本：所有流量经 API 网关（如 Spring Cloud Gateway、Kong、自研网关）转发，网关调用 Redis 执行预置的令牌桶/滑动窗口 Lua 脚本，保证单 key 的原子计数与更新；
- 服务网格（Sidecar）限流：通过 Istio/Envoy 在请求入口自动注入限流策略，配置中心下发规则，所有 Sidecar 实时拉取并执行，天然具备集群一致性；
-
独立限流服务 + gRPC 接口：部署高可用限流服务（如基于 Redis Cluster + 分片 Key 设计），业务服务通过轻量 gRPC 调用
CheckRate接口，由服务端聚合判断并返回是否放行； - 客户端 SDK 埋点 + 中心化策略引擎：在 SDK 中采集调用上下文（IP、UID、URI 等），上报至流式处理系统（Flink/Kafka），策略引擎实时计算并下发拦截指令到边缘节点（如 CDN 或边缘网关）。
若仍想复用 Nginx，可作为二级限流兜底
在已部署中心化限流的前提下，limit_req_zone 可作为本地快速拒绝层，降低打到后端的无效流量：
- 设置宽松阈值（如单 IP 100r/s），仅防突发扫描或误配；
- 配合
burst和nodelay缓冲瞬时毛刺，避免误伤正常用户； - 内存预估公式（供参考）：
zone_size ≈ (key_length + 64) × max_keys，其中$binary_remote_addr固定 16 字节，若预估 10 万 IP，则100000 × (16 + 64) = 8MB，建议预留 10–20% 冗余； - 注意：此内存估算仅适用于单机，不能用于推导集群总内存需求。
真正可靠的分布式限流，核心不在 Nginx 配置，而在决策点的统一与状态的一致性。把限流当成基础设施能力来建设，比在边缘反复修补更可持续。
