如何通过 limit_req_zone 内存计算模型在生产环境实现支持百万并发的限速配置-Nginx-PHP中文网

要让 limit_req_zone 在百万级并发场景下稳定运行，关键是精准控制每个客户端内存开销并确保共享内存容纳活跃IP状态；Nginx通过毫秒级令牌桶+共享内存管理真实请求频率，10MB zone约支持8万个活跃IPv4 IP，256MB zone可支撑50万+活跃IP，需结合分层建模、合理key设计与实时监控。

如何通过 limit_req_zone 内存计算模型在生产环境实现支持百万并发的限速配置

要让 limit_req_zone 在百万级并发场景下稳定运行，关键不是盲目扩大内存，而是精准控制每个客户端占用的内存开销，并确保共享内存区域能容纳活跃 IP 的状态数据。Nginx 本身不直接处理“百万并发请求”，而是通过毫秒级令牌桶 + 共享内存状态管理，实现对海量连接中真实请求频率的高效约束。

理解 limit_req_zone 的内存占用模型

每个客户端 IP（以 $binary_remote_addr 为例）在 zone 中对应一个 state 结构体：

IPv4 地址固定占 4 字节，IPv6 占 16 字节；
state 本身在 64 位系统上占 128 字节（含计数器、时间戳、锁等）；
1MB zone 约可存储 8000 个 IPv4 客户端状态（1048576 ÷ 128 ≈ 8192）；
因此 10MB zone ≈ 支持约 8 万个活跃 IP 的限流状态。

注意：zone 存储的是“最近访问过且尚未过期”的客户端状态，不是所有历史 IP。Nginx 会自动淘汰最久未用的 state，但若活跃 IP 数远超 zone 容量，会导致频繁驱逐和重建，增加 CPU 开销并削弱限流精度。

面向百万并发的 zone 规划策略

百万并发 ≠ 百万活跃限流 IP。实际生产中需按业务特征分层建模：

区分冷热流量：核心接口（如登录、下单）IP 活跃度高，可单独配 zone；静态资源、开放 API 可共用轻量 zone 或不启用；
按地域/代理聚合：对使用 CDN 或 NAT 网关的用户，改用 $http_x_forwarded_for 需谨慎，推荐结合 geo + map 对可信 CDN IP 段跳过限流，或按 $server_name 或 $host 做虚拟主机维度限速；
合理设置 zone 大小：若预估峰值有 20 万真实客户端 IP 需限流，建议 zone ≥ 256MB（200000 × 128B ≈ 25.6MB，再乘以 10 倍冗余），避免抖动；
避免 key 过宽：不用 $request 或长 cookie 值作 key，防止单个客户端生成多个 state，快速耗尽内存。

高性能配置示例（支撑 50 万+ 活跃 IP）

以下配置兼顾内存效率与限流弹性：

http {
    # 主限流区：按二进制 IP，支持约 50 万活跃客户端
    limit_req_zone $binary_remote_addr zone=api_limit:256m rate=10r/s;
<pre class="brush:php;toolbar:false;"># 补充区：针对高频爬虫特征（如无 UA、固定 header）
map $http_user_agent $is_bot {
    ~*(?i)python-requests|curl|httpie  1;
    default 0;
}
limit_req_zone $binary_remote_addr$is_bot zone=bot_limit:64m rate=2r/s;

server {
    location /api/ {
        # 正常用户走主区，突发允许 30 请求缓冲
        limit_req zone=api_limit burst=30 nodelay;

        # 疑似爬虫额外叠加更严限制
        limit_req zone=bot_limit burst=5;
    }
}

}

说明：256MB zone 在 64 位系统下理论支持约 200 万个 state（256×1024² ÷ 128 ≈ 2,097,152），远超 50 万需求，留出充足空间应对 IP 快速轮换或扫描探测。