L1本地缓存TTL设1–15分钟（如5–10分钟），快进快出扛瞬时压力；L2分布式缓存（如Redis）TTL设30分钟–24小时，稳基线兜冷请求；需配合随机抖动、后台刷新与主动失效机制防雪崩，磁盘类L2仅适用于边缘/IoT或归档场景。
缓存有效期配置不是简单设个数字，而是要结合数据变更频率、读写比例、容错成本和系统层级特性来分层设计。L1本地内存缓存短、L2磁盘（或远程分布式）缓存长，并非随意设定，而是有明确逻辑支撑的实践策略。
L1缓存用短TTL：快进快出，扛住瞬时压力
L1通常指应用进程内的内存缓存（如.NET的IMemoryCache、Java的Caffeine），它离业务代码最近，访问零网络延迟、无序列化开销，但容量小、重启即失。因此它的TTL应偏短：
- 典型范围：1–15分钟，常见设为5–10分钟
- 目的不是“长期保鲜”，而是缓解突发流量——比如秒杀开始前1分钟涌入的重复查询，靠L1快速响应，避免全部打到下一层
- 若数据变更较频繁（如用户余额、订单状态），TTL可进一步压缩至30秒–2分钟，配合主动失效（cache invalidation）更稳妥
L2缓存用长TTL：稳住基线，兜底冷请求
L2一般指跨进程/跨机器的共享缓存，如Redis（内存型）、或某些场景下的SSD-backed缓存（如RocksDB嵌入式缓存）。虽然也属“内存级”，但因涉及网络或持久化介质，访问成本显著高于L1。它的TTL设计重在“保底”：
- 典型范围：30分钟–24小时，视业务容忍 stale 数据的时间而定
- 例如商品基础信息（名称、类目、规格）更新不频繁，可设为4小时；而活动规则若每日凌晨刷新，可设为25小时，确保旧值自然过期后新值已就位
- 不建议盲目设“永不过期”（
noeviction或ttl=never），否则内存泄漏风险高，且无法自动承接上游变更
关键协同机制：不能只靠TTL，得加“软失效”与“后台刷新”
单纯依赖TTL会导致“集体过期雪崩”（大量请求同时穿透到数据库）。分级缓存必须配套以下机制：
- 随机抖动（Jitter）：在基础TTL上增加±10%~20%随机偏移，例如设10分钟TTL，实际存为9–11分钟，打散过期时间点
- 懒加载+后台刷新（Refresh-Ahead）：L1过期时，不直接回源查库，而是异步触发后台加载新值并更新L2；当前请求可返回L2中仍有效的旧值（stale-while-revalidate）
- 主动失效联动：当数据库发生写操作（如UPDATE商品价格），同步清除L1（本机）+ 失效或更新L2对应key，避免TTL期间脏数据滞留
特别注意磁盘类L2缓存的适用边界
严格来说，“L2用磁盘”在高性能服务中并不主流——磁盘I/O延迟（毫秒级）远高于内存（纳秒~微秒级），会抵消多级缓存价值。所谓“L2磁盘长”更多见于以下两类场景：
- 边缘计算或IoT设备：本地存储受限，用eMMC/SD卡做二级缓存，TTL设数小时甚至天级，容忍一定延迟
- 归档型服务：如日志检索、报表快照，数据写入后极少修改，用SSD缓存历史聚合结果，TTL按业务周期设置（如“保留最近7天缓存”）
- 真正高并发Web服务中，L2仍推荐Redis等内存型方案；若强调持久性，可用Redis混合RDB+AOF，而非降级到磁盘缓存
