应合理设置limit_req_zone共享内存大小，优先使用短定长key（如$binary_remote_addr），按活跃key峰值×1.5～2倍反推内存，并拆分zone按行为隔离哈希空间以降低冲突、提升效率。
直接调大 limit_req_zone 的共享内存大小，并不能降低散列表开销，反而会加剧内存浪费和哈希冲突——关键不是“给更多内存”，而是让散列表更紧凑、更少空槽、更少碰撞。
控制散列表初始桶数量（避免默认膨胀）
Nginx 不暴露显式哈希桶数配置，但实际桶数量由 共享内存大小 ÷ 每个节点平均开销 隐式决定。每个 $binary_remote_addr 节点实占约 64 字节（含头结构、计数器、时间戳、锁），所以：
- 10m 内存 ≈ 16 万个槽位（理论最大 key 数），但 Nginx 实际分配的哈希桶数远小于此，会按需动态扩容；桶太少 → 冲突高 → 查找变慢；桶太多 → 内存空闲率高 → 缓存不友好
- 经验做法：按你 真实活跃 key 的峰值数量 × 1.5～2 倍 反推所需内存，而非拍脑袋填 100m。例如预估活跃 IP 最多 8 万，则 zone=ip_active:6m（≈ 80000 × 64B × 1.5 ≈ 7.7MB）比 zone=ip_all:100m 更高效
用短且定长的 key 替代变量长度字段
散列表性能严重依赖 key 的哈希分布和比较成本。$http_x_forwarded_for 或带参 $request_uri 这类可变长、不可控字段会导致：
- 哈希计算慢（需遍历字符串）
- 内存对齐差，实际占用远超 64 字节（可能达 200B+）
- 哈希值易聚集，冲突率飙升
推荐方案：
- 优先用 $binary_remote_addr（IPv4 固定 4 字节，哈希快、内存稳）
- 若走 CDN，改用前端透传的短标识，如 $http_x_client_id（建议 ≤16 字节）或 $arg_token（JWT 中截取 cid 字段）
- 禁用 $remote_addr（文本格式，IPv4 平均 12+ 字节）、$http_x_forwarded_for（长度不定、可伪造）
启用状态自动淘汰机制减少桶负载
limit_req 默认保留所有访问过的 key，长期运行后散列表中充斥大量过期/低频 key，既占内存又拖慢查找。可通过以下方式精简活跃集：
- 为高频路径单独建 zone，配合较短的隐式过期窗口：例如 zone=api_hot:3m rate=50r/s —— 小内存 + 高速率，天然只存最近活跃者
- 用 burst 参数间接控制驻留时长：burst 值越小、rate 越高，不活跃 key 被新请求覆盖淘汰的概率越大
- 避免全局大 zone（如 zone=all_ips:100m），它会让冷 key 长期滞留，持续拉低散列表效率
拆分 zone 按行为维度隔离哈希空间
单个大 zone 相当于一个巨型散列表，所有 key 共享同一哈希空间，冲突概率随 key 总量线性上升。改为多个小 zone，等于划分多个独立哈希表：
- zone=login_ip:2m rate=3r/m（登录页，key=$binary_remote_addr）
- zone=user_api:4m rate=20r/s（用户接口，key=$http_x_user_id）
- zone=static_hit:1m rate=100r/s（静态资源，key=$server_name）
每个 zone 散列表更小、更热、冲突更少；总内存仍可控（如合计 7m），整体吞吐和响应稳定性反而更高。
