缓存雪崩会导致系统在数秒内崩溃，因其引发数据库cpu飙升、连接池耗尽、线程阻塞等不可恢复的资源枯竭；典型表现为qps骤增、主从延迟超30秒、服务完全不可用，需通过随机过期时间、多级缓存、熔断降级（如sentinel）、本地缓存（caffeine）及穿透率监控等组合策略防控。

会，而且崩溃速度极快——缓存雪崩不是“可能”导致系统崩溃，而是大概率在数秒内压垮数据库，引发级联故障。关键不在于 Redis 是否挂了，而在于大量请求同时穿透到数据库时，连接池耗尽、慢查询堆积、线程阻塞，整个服务链路迅速卡死。

Redis宕机或批量过期时，请求直接打穿到DB

典型现象是数据库 CPU 瞬间飙到 100%、连接数超限、TimeoutException 或 Connection refused 大量抛出。这不是“压力大”，而是“不可恢复的资源枯竭”。比如某电商大促场景中，商品缓存统一设为凌晨 2:00 过期，2:00:03 开始 DB QPS 从 2 万冲到 50 万，3 分钟后主库只读副本全部延迟超 30 秒，订单服务完全不可用。

• 不要依赖“Redis 恢复后自动回填”——重建缓存本身就会再压一次 DB
• 单靠增加数据库连接数没用，连接池撑不住并发查询 + 事务锁竞争
• Spring Boot 的 @Cacheable 默认不带降级逻辑，缓存失效就直连 DB，毫无缓冲

用熔断器做服务级隔离：Hystrix/Sentinel 必须启用 fallback

熔断不是锦上添花，是保命开关。重点不是“什么时候熔断”，而是“熔断后返回什么”。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 触发条件必须包含数据库响应时间（如 rt > 1000ms）和失败率（如 failureRate > 50%），不能只看异常数
• fallback 方法里禁止调用 DB 或远程服务，只能返回静态兜底值、本地缓存旧数据，或空对象（如 new Product().setPrice(0)）
• Hystrix 已停更，新项目优先用 Sentinel，配置项要显式打开：blockWhenServiceDegrade=true，否则降级不生效

本地缓存 + 异步刷新：Caffeine 不是备胎，是第一道防线

Caffeine 不是用来“加速”的，是用来“扛住 Redis 宕机”的。它必须能独立支撑核心读场景至少 5–10 分钟。

• 初始化时加载热点数据（如首页 banner、用户基础信息），避免冷启动穿透
• expireAfterWrite 设为 10 分钟，maximumSize 控制内存占用，别无脑设 10000
• 更新策略用 refreshAfterWrite 而非 expireAfterWrite，保证缓存永不失效，后台异步刷新
• Redis 写失败时，必须同步写入 Caffeine（哪怕只存 2 分钟），否则隔离失效

双写+互斥锁不能解决雪崩，但能防止击穿放大雪崩

雪崩是“面”问题，击穿是“点”问题。但如果一个热点 key（如秒杀商品）在雪崩期间被反复击穿，会把 DB 压得更死。

• SETNX lock:key 1 EX 30 是底线，锁超时必须短于业务最大耗时，否则死锁卡住所有请求
• 不要用 Thread.sleep() 等待锁，改用 tryLock(1, 30, TimeUnit.SECONDS) 防止线程堆积
• 重建缓存失败时，必须删除锁并记录告警，否则后续请求全被挡在外面

最易被忽略的一点：监控指标不是“缓存命中率”，而是“缓存穿透率”——即每分钟有多少请求最终落到 DB 上。这个数字一旦突破阈值（比如 > 5%），说明隔离机制已开始失效，得立刻人工介入，而不是等告警邮件。