limit_req_zone 不支持分布式全局限速，因其仅在单机共享内存中维护令牌桶状态，无法跨节点同步；必须借助 Redis、专用中间件或网关等外部协调层实现全局一致性。
直接说结论：limit_req_zone 本身不支持分布式全局限速，它只是 Nginx 单机内存内的令牌桶实现，天然不具备跨节点状态同步能力。所谓“无感知静态全局限速”，在纯 Nginx 原生机制下无法达成；必须借助外部协调组件或架构层改造来补足分布式一致性这个关键缺口。
为什么 limit_req_zone 不能直接用于分布式限速
它依赖共享内存 zone（如 shared:mylimit:10m），该内存仅存在于当前 Nginx 实例进程内或本机 worker 共享空间中：
- 多台 Nginx 服务器各自维护独立的计数器，同一用户请求打到不同节点时，限速统计完全隔离
- 没有内置机制向 Redis、etcd 或数据库写入/读取请求状态
- “静态”指规则固定（如每秒 100 次）、不依赖运行时决策，但“全局”要求所有节点看到同一份滑动窗口或漏桶状态——这与单机 zone 的设计目标相悖
实现真正全局限速的可行路径
需在 Nginx 层之上叠加一层状态协调层，常见组合如下：
- Redis + lua-resty-limit-traffic：用 Redis 的原子命令（INCR、EXPIRE、EVAL）模拟分布式漏桶或令牌桶，Nginx 通过 Lua 脚本调用；适合中小规模，延迟可控（毫秒级），需注意 Redis 连接池与超时配置
- Redis + OpenResty 自定义逻辑：更灵活，可实现分层限速（如 IP + UID 二级维度）、突发流量平滑（burst + nodelay）、冷热 key 隔离等，但开发与运维复杂度上升
- 专用限流中间件（如 Sentinel、Alibaba Cloud AHAS）：提供控制台配置、动态规则推送、集群熔断联动能力，适合大型微服务系统；Nginx 作为网关代理，将限速决策委托给中心化服务
- API 网关统一出口（Kong/Tyk/自研网关）：把限速逻辑下沉到网关层，由网关自身集成分布式缓存或调用限流服务；此时 Nginx 退为纯粹负载均衡器，不再承担策略判断
内存预估的关键不是 zone 大小，而是协调层容量
如果你仍想评估 Nginx 侧资源开销，可粗略估算：
- 每个
limit_req_zone $binary_remote_addr zone=ip:10m rate=1r/s中，10MB 内存约能存储 16 万左右的客户端标识（按 64 字节/条计） - 但该数字在分布式场景下无实际意义——因为各节点重复存储同一 IP，且无法合并统计
- 真正需要预估的是 Redis 内存：按每条限速记录约 100–200 字节（含 key、value、过期时间），乘以峰值并发用户数 × 时间窗口长度（如 60 秒）即可得基线用量
无感知落地的两个实操要点
要让业务方感觉不到限速存在，重点不在算法多精巧，而在失败响应与降级设计：
- 限速拒绝时返回 429 状态码，但响应体应轻量（空 body 或极简 JSON），避免触发重试风暴
- 对非核心接口（如埋点上报、日志上传）可配置宽松规则或直接放行，避免因限速导致监控失真
- 预留“紧急熔断开关”，当 Redis 不可用时自动降级为本地限速（允许一定超额），保障基础可用性
