光靠@Cacheable注解+固定entryTtl配置必然引发缓存雪崩，因所有key同步失效导致并发请求集中穿透至数据库；必须结合过期时间随机化、多级缓存兜底与热点key重建保护三者协同防御。
直接结论：光靠 @Cacheable 注解 + 固定 entryTtl 配置，一定会在高并发下触发缓存雪崩；必须引入过期时间随机化 + 多级缓存兜底 + 热点 key 重建保护，三者缺一不可。
为什么固定 TTL 是雪崩的根源
Spring Boot 的 RedisCacheConfiguration 允许设置全局 entryTtl，比如 Duration.ofMinutes(30)。这看起来很干净，但实际是埋雷：所有通过 @Cacheable 写入的 key 都会在同一时间点（写入时刻 + 30 分钟）集体失效。一旦这批 key 是热点数据（如首页 banner、用户配置），失效瞬间的并发请求就会像闸门打开一样冲向数据库。
更隐蔽的问题是——这个“同一时间点”还会被批量操作放大。比如定时任务凌晨 2:00 刷全量商品缓存，30 分钟后整点雪崩；或者服务重启后集中预热，也会造成后续的同步过期。
常见错误现象：redis-cli KEYS "users:*" 查到大量 key 的 TTL 值几乎一致；监控看到 Redis expired_keys 指标出现尖峰，同时数据库 Threads_running 突增。
用偏移区间实现 per-key 随机 TTL
不能依赖注解层做随机，@Cacheable 不支持动态计算每个 key 的过期时间。真要落地，只有两条路可走：
- 业务代码里弃用
@Cacheable，改用redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS)，其中ttl由带偏移的随机逻辑生成，例如：3600 + ThreadLocalRandom.current().nextInt(-180, 181)（即 ±180 秒波动） - 保留
@Cacheable写法，但自定义RedisCacheWriter，继承DefaultRedisCacheWriter，重写put方法，在调用super.put(...)前对传入的ttl参数做扰动
关键细节：
- 别在方法里 new
Random()，复用ThreadLocalRandom.current()或注入单例Random - 偏移区间建议控制在基础 TTL 的 5%~10%，太大会导致部分 key 过期太快（冷数据还没读就被清掉），太小则起不到打散效果
- 该策略对所有 cacheName 生效，若需差异化（如
"configs"固定 24h、"products"随机 30±3min），得在 writer 内部加cacheName路由分支
本地缓存 + 空值占位双保险
只靠 Redis 层随机 TTL，仍无法应对 Redis 实例宕机或网络分区这类故障。必须叠加二级防护：
- 本地缓存用
Caffeine，配置expireAfterWrite(5, TimeUnit.MINUTES)+expireAfterAccess(2, TimeUnit.MINUTES)，并开启recordStats()。命中率骤降（比如从 95% → 40%）就是雪崩前兆信号 - 对查不到的数据（
null或空集合），也写入缓存，例如redisTemplate.opsForValue().set("user:999999", "NULL", 2, TimeUnit.MINUTES)，防止穿透式攻击反复冲击数据库 - 注意：空值缓存的 TTL 要显著短于正常数据（比如 2 分钟），避免长期阻塞真实数据写入
这里容易忽略的是——Caffeine 和 Redis 的序列化必须统一。如果 Redis 存的是 JSON 字符串，Caffeine 却按 JDK 序列化存对象，getIfPresent() 返回的就不是你预期的类型，可能导致 NPE 或 ClassCastException。
@Cacheable 下如何不改业务代码加互斥锁防击穿
雪崩关注“面”，击穿聚焦“点”。当某个 key 随机 TTL 到期后，第一个未命中请求去查 DB 并回填缓存，其余并发请求不该重复查 DB。但 @Cacheable 默认不提供锁机制。
可行方案是：在自定义 RedisCacheWriter 的 put 方法里，对 key 加分布式锁（比如用 redisTemplate.opsForValue().setIfAbsent("lock:user:123", "1", 3, TimeUnit.SECONDS)），仅允许一个线程执行加载逻辑，其他线程等待或降级返回旧值。
但要注意两点：
- 锁 key 必须带业务标识，不能所有请求共用一把锁，否则会串行化整个缓存层
- 锁超时时间必须严格小于缓存 TTL，否则可能锁已释放但缓存还没写入，导致多个线程同时加载
最复杂的其实是锁失败后的处理逻辑：是抛异常？返回默认值？还是让前端重试？这取决于你的业务容忍度，没有银弹。
