levels参数不能加速单次查找，但可防I/O瓶颈：通过1:2分层（16×256=4096目录）将百万文件均匀分布，使每目录仅存200–300文件，保障常数级查找；需配合keys_zone≥10m、inactive≥30m等调优。
proxy_cache_path 的 levels 参数本身不加快单次文件查找，但能从根本上防止海量缓存引发的目录级 I/O 瓶颈——关键在于把数百万个缓存文件均匀分散到多级子目录中，避免一个目录塞进上万文件，让文件系统不用“大海捞针”。
为什么必须设 levels（不能用 levels=0）
不设 levels（即 levels=0）时，所有缓存文件都堆在同一个目录里。当缓存条目超过 10 万：
- ext4 默认用线性扫描查目录项，平均查找延迟可达毫秒级
- XFS 在单目录超数万文件后，目录块分裂频繁、哈希桶冲突上升
- Nginx 每次缓存命中都要执行
stat和open，高频小文件元数据操作会放大目录查找开销 - dcache 锁竞争加剧，导致 worker 进程等待，P95 延迟跳升
推荐配置：levels=1:2 是最实用的分层方案
它基于 cache_key 的 MD5 值生成两级固定路径，天然负载均衡：
- 第一级：取 MD5 值最后 1 位十六进制字符（0–f），共 16 个目录
- 第二级：取倒数第 2–3 位（00–ff），每个一级目录下再分 256 个子目录
- 最终形成最多 4096 个叶子目录，路径形如
/var/cache/nginx/mycache/7/ab/cdef1234 - 百万级缓存下，每个目录平均仅存 200–300 个文件，目录查找基本稳定在常数时间
- 相同请求总落在同一子目录，利于 page cache 复用和 SSD 预读
只配 levels 不够，必须同步调优配套参数
单独设置 levels=1:2 效果有限，需协同优化：
- keys_zone 至少 10m：1MB 内存约存 8000 个 key 元数据；10m 可支撑约 8 万个活跃缓存项，避免因 key 驱逐引发额外磁盘 lookup
- inactive ≥ 30m：设为 60s 会导致高频清理重建，加剧 I/O 波动；建议按业务热度设为 30m–2h
- use_temp_path=off：让临时文件直接写入缓存目录，避免跨文件系统 copy，省一次磁盘 write 和 rename
-
挂载选项加 noatime：SSD 上推荐
noatime,nobarrier（XFS）或noatime,commit=60（ext4），降低元数据刷盘开销
cache_key 设计决定 levels 是否真正生效
路径由 cache_key 经 MD5 后取前几位生成。若 key 含高熵字段，哈希会严重不均：
- ❌ 避免：
$request_time、$cookie_sessionid、毫秒级时间戳、随机串 - ✅ 推荐：
$scheme$host$request_uri（可配合 map 过滤 utm_* 等 tracking 参数） - 上线后验证：用
find /var/cache/nginx/mycache -mindepth 3 -maxdepth 3 -type f | cut -d'/' -f5,6 | sort | uniq -c | sort -n观察分布是否相对均匀
