缓存雪崩是大量key集中过期或Redis实例不可用导致请求直击数据库，引发数据库过载崩溃；需通过TTL随机偏移错峰过期、熔断降级、本地缓存兜底及禁用危险命令等手段防御。
缓存雪崩到底是什么，为什么它会压垮数据库
缓存雪崩不是单个 key 失效，而是大量 key 在同一时间点集中过期，或者 Redis 实例整体不可用（如重启、网络分区），导致所有请求瞬间穿透到后端数据库。数据库面对突发的、无缓冲的全量读请求，连接数、CPU、IO 迅速打满，进而拒绝服务甚至崩溃。
常见诱因包括：
-
expire时间设置过于整齐，比如批量写入时统一设为30 * 60秒 - 使用固定时间戳作为过期时间（如
System.currentTimeMillis() + 3600000），未加随机扰动 - Redis 主从切换或集群脑裂期间，客户端仍持续重试，最终降级直连 DB
如何让 key 过期时间“错峰”，避免集体失效
核心思路是打破过期时间的强一致性，给每个 key 的 TTL 加上合理范围内的随机偏移：
- 不要写死
SET key value EX 3600 - 改为
SET key value EX 3600+ 随机数，例如：ttl = 3600 + random.randint(0, 600) # ±10 分钟抖动
- 如果用 Spring Data Redis，可在封装的
set方法里统一注入偏移逻辑，而不是在业务层重复写 - 对于热点数据（如首页 banner、商品类目），建议 TTL 设置更长（如 2 小时），再配合主动刷新机制，而非依赖被动过期
注意：抖动范围不宜过大（比如 ±1 小时），否则可能造成部分 key 长期不更新，数据陈旧；也不宜过小（如 ±1 秒），起不到错峰效果。
Redis 宕机时，怎么不让流量直接冲垮数据库
Redis 挂了 ≠ 系统必须挂。关键在于提前设计降级路径和熔断策略：
- 所有缓存访问必须包裹超时与异常处理，不能让 Redis 超时阻塞主线程
- 使用
try-catch捕获JedisConnectionException、LettuceConnectionException等底层连接异常，而不是只捕获NullPointerException - 在 catch 块中启用本地缓存（如
Caffeine）或直接走 DB 查询，并记录告警（别静默失败） - 引入熔断器（如
Resilience4j或Hystrix），当 Redis 错误率 > 50% 持续 30 秒，自动开启熔断，后续请求直接降级，避免雪上加霜 - 预热脚本很重要：上线前用工具（如
redis-cli --scan+ttl）检查是否存在大批量同秒过期 key，及时修正
还有两个容易被忽略的细节
-
keys * 和 scan 类命令在大数据量下会阻塞 Redis 单线程，高并发时可能引发响应延迟 → 进而触发客户端重试 → 加剧雪崩。线上禁用 keys，scan 必须带 COUNT 参数且控制步长
- 缓存空值（
set key "" EX 60）能防缓存穿透，但若所有空值都设相同 TTL，它们也会“集体复活”并再次穿透 DB。空值也要加随机 TTL，哪怕只有 ±30 秒
keys * 和 scan 类命令在大数据量下会阻塞 Redis 单线程，高并发时可能引发响应延迟 → 进而触发客户端重试 → 加剧雪崩。线上禁用 keys，scan 必须带 COUNT 参数且控制步长set key "" EX 60）能防缓存穿透，但若所有空值都设相同 TTL，它们也会“集体复活”并再次穿透 DB。空值也要加随机 TTL，哪怕只有 ±30 秒Redis 本身不会雪崩，雪崩是人设计出来的。真正危险的不是过期时间设成 3600，而是没意识到 3600 后那一秒会发生什么。
