keys_zone是proxy_cache_path中存储缓存键及元数据的共享内存区，大小应按预期活跃唯一key总数估算（约8000 key/MB），需兼顾命中率与内存效率，配合inactive和max_size实现分层缓存清理。
keys_zone 是 proxy_cache_path 中最关键的性能参数之一，它不存缓存文件本身，而是为缓存键（key）和元数据（如过期时间、状态、引用计数等）分配共享内存。这块内存直接影响缓存查找速度——所有缓存命中（HIT）、未命中（MISS）、锁竞争、后台更新判断都依赖它。配小了会频繁淘汰 key，导致“假未命中”；配大了又浪费内存，且可能拖慢内存管理效率。
keys_zone 容量估算：按 key 数量而非业务流量
共享内存大小与并发请求数、QPS 无关，只取决于你预期同时驻留在缓存中的**唯一 key 总数**。Nginx 官方经验是：1 MB 内存 ≈ 存储 8000 个 key（含元数据，实测范围在 7500–8500）。所以计算公式很直接：
- 预估活跃缓存 key 数（例如：10 万条 API 路径 + 参数组合）
- 所需 keys_zone 大小 ≈ ⌈key 数 ÷ 8000⌉ MB
- 示例：若日常有 64 万个有效缓存项 → 至少需 640000 ÷ 8000 = 80 MB → 建议配置 keys_zone=my_cache:100m（留 20% 余量）
避免常见误判：不是越大越好，也不是越小越省
超过 200 MB 的 keys_zone 很少必要，反而可能引发内核 slab 分配延迟；低于 10 MB 则容易因 key 淘汰过快，使 inactive 设置失效。特别注意：
- 同一 keys_zone 名称不能在多个 proxy_cache_path 中复用
- 重启 Nginx 后，共享内存重置，但磁盘缓存仍保留（除非手动清空）
- 可通过 nginx -T | grep keys_zone 检查实际加载值，用 curl -I http://your.site/xxx 配合响应头 X-Cache: HIT/MISS 验证效果
配合 inactive 和 max_size 实现分层清理
keys_zone 只管内存中 key 的生命周期，真正决定磁盘文件去留的是 inactive 和 max_size。三者协同才完整：
- keys_zone：决定“哪些 key 还值得记着”（内存级活跃度）
- inactive=7d：决定“哪个缓存文件太久没人要，可以删”（磁盘级冷热）
- max_size=10g：决定“磁盘满了，优先踢掉最老的缓存文件”（空间硬限）
比如配置 keys_zone=api_cache:128m inactive=1h max_size=50g，适合高频更新的接口缓存——内存保 128 万 key，但磁盘只留最近 1 小时访问过的文件，超量就自动轮转。
动态验证与调优建议
上线后别只看配置，用真实数据反推是否合理：
- 查 key 使用率：awk '/^KEYS/{print $3}' /proc/nginx/pid/cache_status（需开启 cache_status 模块）
- 观察日志中 proxy_cache_key 生成逻辑是否重复或过于宽泛（如含随机参数、session_id）
- 若发现大量 MISS 但上游响应快，优先检查 key 是否因时间戳、UTM 参数等导致不一致，而非盲目扩 keys_zone
