在 Nginx 中实现集群级别的全局限流，本质是突破单机限制，让多个 Nginx 实例共享同一套限流状态。但需明确：Nginx 原生的 limit_req_zone 和 limit_conn_zone 仅支持本机内存共享，无法跨进程、更无法跨机器。因此，“集群级全局限流”必须借助外部组件协同完成，不能仅靠 Nginx 配置文件实现。

为什么原生 Nginx 不支持集群限流

Nginx 的限流模块（ngx_http_limit_req_module 和 ngx_http_limit_conn_module）依赖 本地共享内存区（shared memory zone） 存储计数器，例如：

• limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
• 该 zone=api:10m 仅存在于当前 Nginx worker 进程所在服务器的内存中
• 其他 Nginx 实例完全无法读写该区域，彼此状态隔离

可行的集群限流方案（需外部组件）

主流实践是将限流决策上移至一个中心化服务，Nginx 充当执行代理。以下是两种成熟路径：

方案一：Nginx + Redis（推荐，灵活可靠）

• 使用 nginx-plus（商业版）或开源模块 lua-resty-limit-traffic + lua-resty-redis
• 核心逻辑：每个请求到达时，Nginx 执行 Lua 脚本，向 Redis 发起原子操作（如 INCR + EXPIRE），判断是否超限
• 示例关键逻辑（Lua）：

  1 2 3 4

  local limit = require "resty.limit.count"     local lim, err = limit.new("redis://127.0.0.1:6379", 100, 1) -- 每秒100次     local key = ngx.var.binary_remote_addr     local delay, remaining, err = lim:incoming(key, true)

• 优势：支持精确速率、自定义 key（如用户ID、API 路径）、动态调整策略

方案二：前置统一网关层（如 Kong、APISIX、Traefik）

• 这些网关内置分布式限流插件，底层通常基于 Redis 或 etcd 实现状态同步
• Nginx 退为纯负载均衡器，所有流量先经网关做集群级限流，再转发至后端 Nginx 集群
• 例如 APISIX 的 limit-count 插件可配置 key 为 remote_addr，并指定 Redis 地址
• 优势：开箱即用、策略可视化、与鉴权/日志等能力天然集成

常见误区与替代思路

有人尝试用 Nginx 变量拼接“伪集群标识”，例如：

• limit_req_zone $server_name:$binary_remote_addr zone=cluster:10m rate=50r/s;
• 这仍是每台机器独立计数，只是 key 更细粒度，并非真正集群共享
• 若想近似“全局效果”，只能大幅降低单机阈值（如设为总目标的 1/N），但会牺牲突发容忍度且不精准

另一种轻量做法是：在 DNS 或 LVS 层做 IP 哈希调度，确保同一客户端始终落到同一台 Nginx —— 此时单机限流可等效为“会话级全局”，但失去高可用弹性，不推荐生产核心链路。