如何根据业务量精准分配内存配置Nginx proxy_cache_path的keys_zone？

本文共计809个文字，预计阅读时间需要4分钟。

keys_zone 分配的内存只存储缓存 key 和元数据（例如访问次数、过期时间），不存在响应实体本身。1MB 共享内存 + 存 8000 个 key。如果您的业务每秒产生 100 个唯一 URL，按 1 小时内不重复计算，就是 36 万 key；按 1 天计算，就是 864 万 key — 此时 keys_zone=my_cache:1m 显然不足，会导致频繁淘汰 key，降低缓存命中率。

怎么算出实际需要的 keys_zone 大小

先确认你最关心的缓存粒度：是按 $uri？还是带完整 query 的 $scheme$host$uri$is_args$args？粒度越细，key 越多。再结合业务日志估算：

• 用 awk '{print $7}' access.log | sort -u | wc -l 粗略统计一天内独立 URI 数量
• 若启用了 proxy_cache_key "$scheme$host$uri$is_args$args"，再用 awk -F'"' '{print $2}' access.log | awk '{print $1,$2}' | sort -u | wc -l 估算带参数的唯一请求量
• 把结果除以 8000，向上取整，就是所需 MB 数。例如 200 万个唯一 key → 至少 keys_zone=my_cache:250m

配置时容易忽略的三个硬约束

proxy_cache_path 的 keys_zone 值一旦写死，重启 Nginx 后无法动态扩容；且该内存区域在 worker 进程间共享，但不跨机器。常见踩坑点：

• proxy_temp_path 和 proxy_cache_path 必须在同一个文件系统分区，否则缓存写入失败（错误日志里会出现 open() "/path/to/cache/xxx" failed (18: Invalid cross-device link)）
• 如果用 use_temp_path=off（推荐），Nginx 会直接把缓存文件写进 proxy_cache_path 目录，此时 keys_zone 内存不足只会导致 key 淘汰，但磁盘空间满会导致整个缓存失效
• 多个 server 块共用同一个 keys_zone 名称时，key 是全局去重的；若误配成不同名称（如 my_cache_v1 / my_cache_v2），等于人为切分缓存池，浪费内存

上线前必须验证的两件事

光写对配置没用，得看它是否真按预期工作：

• 用 sudo nginx -t 检查语法后，执行 sudo ss -tulpn | grep :80 确认 Nginx 已加载新配置（避免 reload 失败静默回退）
• 访问一个已知接口后，立刻查 curl -I http://your-domain/test.jpg | grep N-Cache-Status（前提是配置了 add_header N-Cache-Status $upstream_cache_status），返回 HIT 才说明 key 和缓存路径都通了

缓存 key 的内存分配是个“看不见但压垮性能”的点：太小，key 频繁踢出，命中率上不去；太大，又白白占着 worker 进程的共享内存，影响其他模块。真实业务中，建议从预估值起步，上线后用 nginx -V 2>&1 | grep -o 'built by.*' 确认版本，并持续观察 $upstream_cache_status 统计分布，再微调。