levels 参数不提升单次查找速度，但通过哈希分层（如1:2）将百万缓存分散至4096目录，避免ext4元数据瓶颈、inode锁争抢与iowait升高，需配合keys_zone、inactive、use_temp_path等调优及稳定cache_key设计。
proxy_cache_path 的 levels 参数本身不提升单次缓存文件的查找速度，但它直接决定高并发下缓存目录的 I/O 承载能力——这是边缘缓存系统在负载均衡场景中保持低延迟的关键前提。
为什么 levels 影响负载均衡节点的缓存效率
当多个 upstream 节点共用同一套缓存路径（如通过共享存储或本地 SSD），且未合理分层时，所有节点的缓存文件会集中写入极少数目录。一旦总缓存条目超 10 万，ext4/xfs 文件系统在执行 stat、open 等元数据操作时会出现明显延迟，表现为：
- 缓存命中率未降，但响应 P95 延迟跳升
- 磁盘 iowait 升高，尤其在 cache revalidate 或 background update 高频时段
- 多个 Nginx worker 进程争抢同一目录 inode 锁，出现锁等待
推荐 levels=1:2 的实际效果与路径逻辑
该配置将缓存文件按 MD5(cache_key) 哈希值前三位分散到 16 × 256 = 4096 个叶子目录中，例如：
/var/cache/nginx/mycache/7/3a/73a9f0e8c...好处包括：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 百万级缓存项下，每个目录平均仅存 200–300 个文件，规避 ext4 线性扫描瓶颈
- 相同请求始终落入固定子目录，利于 page cache 局部性复用和 SSD 顺序读优化
- 比 levels=2:2（65536 目录）更轻量，避免过多空目录带来的管理开销
必须同步调整的配套参数
单独设 levels 不足以释放性能，需配合以下设置：
- keys_zone 至少 10m：1m 内存约存 8000 个 key，10m 可支撑 8 万个活跃项，防止 key 频繁淘汰引发重复落盘
- inactive 时间 ≥ 30m：过短（如 60s）会导致高频清理重建，加剧 I/O 波动
- use_temp_path=off：避免临时文件先写 tmp 再 move，减少一次磁盘 write 和 rename 开销
- 挂载选项加 noatime：SSD 上禁用访问时间更新，降低元数据写放大
cache_key 设计决定 levels 是否真正生效
如果 cache_key 包含高熵字段（如 $request_time、$cookie_sessionid、毫秒级时间戳），MD5 哈希结果将严重不均——部分子目录堆积数千文件，其余长期为空。结果仍是局部 I/O 热点。
应优先使用稳定字段组合：
- ✅ 推荐：
$scheme$host$request_uri（忽略 query 中的 tracking 参数） - ✅ 可选：
$scheme$host$uri$is_args$args+ map 过滤掉 utm_* 类参数 - ❌ 避免：
$scheme$host$request_uri$request_time
