如何在高可用架构中，利用limit_req_zone内存预估实现无感知全局限速的最佳策略？

本文共计780个文字，预计阅读时间需要4分钟。

要使用 limit_req_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（保守速率）或直接放行（按业务容忍度选择）