千万级并发限流需精准建模、分层分流、key降维：按业务分桶建轻量zone，用CIDR归并/IP哈希/路径正则压缩key，内存按峰值key数反推（1MB≈1.6万key），并组合limit_conn与upstream健康检查兜底。
在千万级并发场景下，limit_req_zone 的内存使用不是靠“堆大内存”硬扛，而是靠精准建模 + 分层分流 + key 降维。核心矛盾在于：10MB 内存最多存约 16 万个独立客户端状态（按 $binary_remote_addr），远低于千万量级。直接按 IP 全局限流会因共享内存区溢出导致限流失效，甚至引发 Nginx worker 崩溃。
按业务维度分桶，避免单 zone 过载
千万并发不等于千万个活跃限流 key。真实流量中，大量请求集中在少数路径、用户或服务节点。应拆分为多个轻量 zone，各自独立计数：
- 对登录接口用
$http_x_user_id或$cookie_sessionid建 zone，单用户限速（如 5r/s），内存按活跃用户数估算 - 对静态资源路径（如
/static/）用$request_uri或$server_name，按资源粒度限流，避免爬虫打爆 CDN 回源 - 对管理后台（如
/admin/）用$binary_remote_addr+ 白名单 map，只对非内网 IP 限流，大幅减少 key 数量
key 设计必须压缩且可聚合
$binary_remote_addr 虽比 $remote_addr 省内存，但 IPv4 固定占 4 字节、IPv6 占 16 字节，仍不够高效。更优做法是：
- 用
map按 CIDR 归并 IP 段：192.168.0.0/16→"office"，把数万 IP 映射为一个 key - 对移动端 API，提取设备指纹哈希前缀（如
md5($http_user_agent . $http_x_device_id)截取前 8 字符），降低 key 冲突率同时控制长度 - 禁用高基数变量（如完整
$request_uri），改用正则提取路径主干：map $request_uri $api_route { ~^/v1/(orders|users)/(.*)$ "$1"; default "other"; }
内存容量需按峰值 key 数反推，而非拍脑袋
1MB 共享内存 ≈ 存储 1.6 万个 key 状态（含计数器、时间戳、锁等元数据）。计算公式为：
zone_size = ceil(预估峰值活跃 key 数 ÷ 16000) MB × 1.2（冗余系数）
例如：某核心接口预计有 80 万活跃用户同时调用，选用 $http_x_user_id 为 key，则最小 zone 大小为 ceil(800000 ÷ 16000) × 1.2 = 60MB。若拆成 5 个 zone（按 region / app_version 划分），每个只需 12–16MB，更易调度且故障隔离。
配合 limit\_conn 和 upstream 健康检查做兜底
仅靠 limit_req 无法应对连接洪峰。必须组合使用：
- 用
limit_conn_zone $binary_remote_addr zone=conn_ip:10m+limit_conn conn_ip 100控制单 IP 并发连接数，防慢速攻击 - 在 upstream 中配置
max_fails=3 fail_timeout=30s，当后端响应超时或 5xx 达阈值，自动摘除节点，避免限流失效后流量全压向残血实例 - 对关键接口开启
proxy_cache缓存成功响应，降低后端压力，让限流真正作用于“不可缓存”的写操作
