缓存雪崩核心诱因是大量Key集中过期，通过设置随机过期时间可有效预防：在基础TTL上添加合理随机偏移（如3600±300秒），将瞬时失效压力摊薄至时间窗口，避免数据库被瞬间击穿。
缓存雪崩的核心诱因之一，就是大量 Key 在同一时刻集中过期，导致请求全部穿透到数据库。而“通过 and 随机过期时间避免”这个说法本身存在表述偏差——不是“通过 and”，而是“通过设置随机过期时间”来避免。这里的 “and” 很可能是误输入或混淆了逻辑连接词，实际要表达的是“如何通过随机过期时间这一手段来预防雪崩”。
为什么随机过期时间能有效防雪崩
固定过期时间会让缓存像定时炸弹一样，在整点（比如每小时第0分）集体失效。而加入随机偏移后，原本设为 3600 秒（1 小时）的缓存，实际过期时间可能分布在 3300～3900 秒之间。这样就把原本集中在 1 秒内的失效压力，摊开到 10 分钟甚至更长窗口内，数据库不会被瞬间打垮。
怎么实现随机过期时间
关键是在写入缓存时，不直接用固定 TTL，而是动态计算一个带扰动的值。常见做法包括：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 基础时间 + 随机秒数：例如 base=3600，offset=random(0,300)，最终 TTL=3600～3900 秒
- 基础时间 ± 百分比浮动：如 3600±10%，即 3240～3960 秒，分布更对称
- Spring Boot 中使用 @Cacheable 时，不能直接控制过期时间，需配合自定义 CacheManager 或手动调用 RedisTemplate 设置随机 TTL
- Java 示例中常用 Random.nextInt() 生成偏移；Go/Python 等语言也均有对应随机函数支持
注意事项和常见误区
随机策略不是万能解药，需配合其他措施才能真正稳住系统：
- 偏移范围不能太小（如只加±5秒），否则仍可能在高并发下“撞车”失效
- 不能只靠随机，还要检查是否所有缓存都走同一套逻辑——比如优惠券、用户、商品等不同业务缓存，应各自独立生成随机值
- Redis 宕机等物理层故障，随机过期时间无效，必须搭配集群高可用（如 Redis Cluster 或 Sentinel）
- 冷启动或批量预热时，若一次性写入大量带随机 TTL 的缓存，也可能造成后续某段时间集中失效，建议分批+错峰加载
结合 Spring Boot 的实用建议
如果你用的是 @Cacheable，默认不支持动态 TTL。推荐两种落地方式：
- 对关键缓存（如首页配置、活动开关）放弃 @Cacheable，改用 RedisTemplate 手动 setex，并嵌入 getRandomExpireMinutes() 工具方法
- 自定义 CacheManager，重写 put 方法，在存入前自动注入随机偏移，让注解也能“隐形生效”
- 配合 Caffeine 本地缓存做二级防护：即使 Redis 层雪崩，本地缓存还能扛住部分读请求
