缓存雪崩防控需三管齐下：打散过期时间防集中失效，构建多级缓存增强韧性，熔断降级与兜底数据守住最后一道闸门，并辅以预热、主动刷新和故障演练。

缓存雪崩导致高可用崩溃，核心在于“大量请求瞬间穿透缓存层，压垮数据库并引发服务级联失效”。这不是单点问题，而是系统性防线失守。要真正守住高可用，得从预防集中失效、增强缓存韧性、兜住下游压力三个层面协同发力。

打散过期时间，从源头避免集体失效

批量缓存设统一 TTL 是雪崩最常见诱因。比如凌晨2点所有商品缓存同时过期，流量高峰一来就全打库。 - 给基础过期时间叠加随机偏移量：比如原本设 30 分钟，改为 `30 * 60 + ThreadLocalRandom.current().nextInt(60, 300)` 秒（即 ±5 分钟内随机） - 对定时任务预热的缓存，按业务维度分批次加载+设置差异化过期时间，避免“一把梭” - 禁止在代码里硬编码 `setExpire(key, 1800)`，改用封装好的工具方法强制加扰动

构建多级缓存 + 高可用 Redis 架构

单层缓存等于把鸡蛋放一个篮子，Redis 宕机或网络分区时毫无缓冲。 - 本地缓存（如 Caffeine）作为 L1：拦截 70%+ 热点读请求，即使 Redis 全挂也能扛住短时流量 - Redis 集群作为 L2：启用 Redis Cluster 或哨兵模式，主从自动切换，节点故障不中断服务 - 关键数据加读写分离：查询走从节点，写操作走主节点，降低单点负载压力 - 监控 Redis 连通性与 key 命中率，命中率突降 20% 触发告警，提前干预

熔断降级 + 数据兜底，守住最后一道闸门

当缓存层已不可靠，必须限制对数据库的冲击，并保障用户可感知的服务连续性。 - 使用 Sentinel 或 Resilience4j 对 DB 查询接口做熔断：错误率超 50% 或响应超 1s，自动开启熔断，返回缓存旧值或默认文案 - 设置降级开关：运维后台一键开启“缓存只读模式”，禁止更新缓存，防止脏写放大故障 - 预置兜底数据：对核心接口（如首页商品列表、用户登录态），提前生成静态 JSON 文件或内存 Map，在极端情况下直接返回，不查任何后端

补充关键动作：预热 + 主动刷新 + 故障演练

- 大促前 2 小时执行缓存预热：通过离线任务将热点 key 提前加载进 Redis 和本地缓存 - 对永不过期的热点 key（如配置中心），采用“逻辑过期”：value 中嵌入 `expire_at` 字段，由后台线程异步刷新，客户端发现过期则触发懒加载 - 每季度做一次“模拟 Redis 宕机”演练：关闭 Redis 节点，验证本地缓存是否生效、降级是否触发、监控告警是否及时，闭环修复盲点

不复杂但容易忽略