Nginx原生限流不支持分布式一致性，因其shared memory zone仅限单机；需借助Redis+Lua、统一网关或双层限流实现跨节点一致限流。
Nginx 原生限流（如 limit_req_zone）无法在分布式多节点环境中保持一致的统计结果，因为它的共享内存区（shared memory zone）只存在于单机内存中，各节点完全隔离、互不同步。所谓“一致统计”，必须依赖外部中心化状态存储——这不是配置技巧问题，而是架构设计约束。
为什么多节点下原生限流必然不一致
- 每个 Nginx 实例独立维护自己的
zone，例如zone=api:10m，只记录本机收到的请求计数 - 同一用户 IP 的请求若被负载均衡打到 A 节点和 B 节点，会分别计数 → 实际通过量翻倍（漏放）
- 某节点宕机后，其内存中计数清零；用户切换到新节点，计数重置 → 短时超额（误放）
- 扩缩容导致流量重分，key 分布突变，限速曲线跳变，用户感知抖动
实现跨节点一致限流的可行路径
-
Nginx + Redis + Lua（OpenResty 推荐）
- 使用
lua-resty-limit-traffic和lua-resty-redis模块 - 每次请求执行 Lua 脚本，向 Redis 发起原子操作（如
INCR + EXPIRE），以用户 ID、IP+URI 或 token 为 key - 示例逻辑：
local lim = require "resty.limit.count".new("redis://127.0.0.1:6379", 100, 1) -- 每秒 100 次 local key = ngx.var.http_x_user_id or ngx.var.binary_remote_addr local delay, remaining, err = lim:incoming(key, true) if not delay then return ngx.exit(429) end - 优势：精确控制、key 可灵活组合、支持动态调整速率
- 使用
-
前置统一网关层（生产环境首选）
- 将限流能力上移到 APISIX、Kong 或 Traefik 等网关
- 网关内置分布式限流插件（如 APISIX 的
limit-count），底层直连 Redis 或 etcd 存储状态 - Nginx 退为纯负载均衡器，不再承担限流决策
- 优势：策略集中管理、与鉴权/日志/监控天然集成、无需修改 Nginx 部署结构
-
双层限流（L1本地 + L2中心化）作为兜底
- 在每台 Nginx 上仍配置
limit_req_zone（如按 IP 或 URI），用于快速拦截明显异常流量（防突发打崩） - 中心化限流（Redis/Lua 或网关）负责强一致性控制，作为主策略
- 当 Redis 不可用时，自动降级为本地限流，保障系统可用性
- 在每台 Nginx 上仍配置
关键提醒
- 不要试图用
limit_req_zone的 key 组合（如$binary_remote_addr$uri）伪装“分布式”——它只是让单机策略更精细，不解决跨节点状态同步问题 - 内存预估（如
10m ≈ 7 万 key）仅适用于单机 zone，对集群无效；集群规模扩大时，Redis 连接池、超时、持久化策略才是瓶颈点 - 若业务允许一定误差（如容忍 ±15% 放行偏差），且流量分布较均匀，可接受多节点独立限流 + 略保守的 rate 设置，但不能称为“一致统计”
不复杂但容易忽略：一致性限流的本质是状态共享，而 Nginx 的设计哲学是无状态转发。强行让它扛状态，就得加外挂；交给专业组件，反而更稳。
