固定过期时间会引发缓存雪崩，因其导致大量key在同一时刻集中失效，使并发请求瞬间穿透至数据库；应采用基础TTL叠加±5%～10%随机偏移（如3600秒+0～360秒）来离散化失效时间，避免毫秒级扎堆或语义失真。
为什么固定过期时间会引发雪崩
缓存雪崩最常见诱因就是大量 key 设置了完全相同的 TTL。比如凌晨2点批量写入商品缓存，统一设为 3600 秒（1小时），那所有缓存会在 3:00:00 整集体失效。此时并发请求一拥而上，数据库瞬间被打满。
这不是理论风险——电商大促、秒杀活动后常复现该现象。关键在于“集中”二字：不是缓存过期本身有问题，而是过期时间缺乏离散性。
随机偏移量怎么加才安全
核心是让每个 key 的实际过期时间落在一个合理区间内，而非简单加个固定随机数。
- 偏移量不能过大：比如基础 TTL 是 30 分钟，随机 ±15 分钟，实际范围变成 15–45 分钟，跨度太大可能影响业务语义（如库存缓存延迟太久不准）
- 偏移量不能过小：±10 秒对高并发场景几乎无效，仍可能在毫秒级窗口内集中失效
- 推荐做法：基础 TTL × (0.8 ~ 1.2) 区间取随机值，或固定加减 5%~10% 的基础值。例如
baseExpire=3600，则用3600 + new Random().nextInt(360)（±6 分钟） - 注意：Java 的
Random.nextInt(n)生成的是 [0, n) 范围，别漏掉 0 边界
Spring Boot @Cacheable 怎么注入随机逻辑
@Cacheable 默认不支持动态 TTL，必须绕过注解直接操作底层 RedisTemplate 或 LettuceClient。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见错误是试图在 @Cacheable(expire = "...") 里写表达式——它只接受静态值，运行时无效。
- 正确路径：禁用
@Cacheable的自动过期，改用redisTemplate.opsForValue().set(key, value, duration, timeUnit)手动控制 - 若坚持用注解，可自定义
CacheManager，重写getCache()返回带随机策略的RedisCache实例 - 更轻量方案：封装一个工具方法
setWithRandomTtl(String key, Object value, long baseSeconds)，内部调用setEx并传入计算后的秒数
容易被忽略的边界问题
随机化只是缓解手段，不是银弹。以下三点常被跳过，却直接影响效果：
- 同一业务数据的不同
key（如user:1001:profile和user:1001:orders）如果都按相同规则随机，仍可能在统计意义上扎堆失效——建议按业务维度分组设置不同随机种子 - 使用
RedisTemplate时，setEx的单位是秒，但TimeUnit.MILLISECONDS容易误传，导致 TTL 变成毫秒级（如 3600ms ≈ 3.6 秒），务必核对单位 - 本地开发环境用
redis-server单机版测试时，看不出集群下节点时钟漂移的影响；生产环境 Redis Cluster 各节点系统时间不一致，会使实际过期行为偏离预期，需校准 NTP
真正起作用的从来不是“加了随机”，而是随机范围是否匹配业务吞吐节奏、是否覆盖了最坏的并发峰值窗口。没压测验证的随机值，和没加一样。
