全局限速需脱离nginx单机shared memory，改用redis分布式令牌桶+本地缓存兜底：redis统一维护计数并保障高可用，nginx通过lua调用原子脚本实现无状态限流，故障切换时速率连续不突变。
要通过 limit_req_zone 实现高可用架构下的全局限速且无感知，关键不在“单机限速”本身，而在于如何让限速规则在集群中一致生效、不因节点增减或故障切换导致速率突变或计数丢失。Nginx 的 limit_req_zone 默认基于共享内存（shared memory zone），天然只作用于本机——这恰恰是全局限速的瓶颈。真正的无感知全局限速，需要脱离单机内存，改用外部统一存储+轻量同步机制。
限速数据不能依赖单机 shared memory
Nginx 的 limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s 中的 10m 是本机共享内存，重启、扩缩容、节点故障都会清空计数，造成用户请求突然放行（超限请求被误放行）或误拦截（计数残留未清理）。在高可用场景下，这种状态本地化与“无感知升级/切换”直接冲突——你无法保证每次发布后所有节点的限速状态完全对齐。
推荐采用分布式令牌桶 + 本地缓存兜底
全局限速应由独立服务（如 Redis + Lua 脚本）统一维护令牌桶状态，Nginx 通过 lua-resty-redis 或 OpenResty 的 balancer_by_lua* 阶段调用：
- 每次请求先查 Redis 获取当前令牌数，尝试消耗一个；成功则放行，失败则拒绝
- 使用原子 Lua 脚本（如
eval "local c = redis.call('get', KEYS[1]); if c and tonumber(c) > 0 then redis.call('decr', KEYS[1]); return 1 else return 0 end" 1 key）避免并发竞争 - 为降低延迟，在 Nginx worker 内存中缓存最近访问的 key 及剩余令牌（TTL 同步 Redis），缓存失效时回源刷新
- Redis 部署为哨兵或 Cluster 模式，保障自身高可用；连接层配置自动重试与熔断
内存预估需分两层计算
所谓“内存预估”，实际是评估两个部分的资源开销：
- Redis 层：按限速维度（如用户ID、IP、API路径）估算 key 数量 × 单 key 存储开销（通常 64–128 字节，含过期时间与整型计数）。例如：100 万活跃用户 × 100 字节 ≈ 100MB；再叠加 30% 冗余与 AOF/RDB 开销，建议预留 150–200MB 内存
-
Nginx 本地缓存层：使用
lua_shared_dict定义共享字典（如lua_shared_dict rate_cache 10m），大小按热点 key 数量 × 每个缓存项约 256 字节估算。若预计缓存 1 万个 key，10MB 已足够
高可用切换时保持限速连续性
当某台 Nginx 节点下线或新节点加入，只要 Redis 集群正常、客户端能连上，限速策略就完全不受影响。重点在于：
- 避免在 Nginx 配置中硬编码 Redis 地址，改用服务发现（如 Consul DNS 或 Nacos API）动态获取
- 限速 key 设计需具备业务语义和可伸缩性，例如
"rate:uid:{uid}:api:/order/create"，而非仅用 IP，否则横向扩展时易倾斜 - 设置合理 fallback 行为：Redis 不可达时，可降级为本机
limit_req（保守速率）或直接放行（按业务容忍度选择）
