redis缓存的雪崩击穿穿透以及解决方案

2025年Java面试宝典：点击下载（提取码：9b3g）
最近帮团队做技术复盘时，发现很多同事对Redis缓存异常的解决方案理解不够系统。今天咱们就来盘一盘面试高频题——Redis缓存的雪崩、击穿、穿透，结合我在BAT的实战经验，说说怎么用最接地气的方式化解这些"缓存危机"。

🔥 缓存雪崩：集体阵亡怎么破？

去年双十一我们就遇到过这种情况：同一时间大量缓存集体失效，请求像洪水一样直接涌向数据库，差点把MySQL压垮。缓存雪崩的破坏力在于它的连锁反应——一个节点的失效可能引发整个系统的雪崩式崩溃。

解决方案三板斧：

1. 错峰失效：在设置缓存过期时间时加随机值（比如原定30分钟，实际设置25-35分钟随机），避免批量失效
2. 熔断降级：当数据库QPS超过阈值时，启动限流策略，比如使用Hystrix做服务熔断
3. 缓存预热：大促前通过离线任务提前加载热点数据，可以参考这张架构图：

🎯 缓存击穿：爆款商品引发的血案

某次秒杀活动中，某个SKU的缓存刚好失效，瞬间十万级请求直接把数据库打挂。这就是典型的缓存击穿——单个超高并发key失效引发的灾难。

破局关键点：

• 互斥锁排队：用Redis的setnx命令实现分布式锁，只有拿到锁的请求去查库
• 逻辑过期：不设置物理过期时间，而是在value里存过期时间戳，异步更新
• 二级缓存：本地缓存+Redis的二级缓存架构，像这样设计：

💣 缓存穿透：黑客的最爱

我们安全组曾拦截过这样的攻击：用随机生成的非法ID高频请求，导致缓存永远不命中。这种穿透攻击不仅消耗系统资源，更可能导致敏感数据泄露。

防御组合拳：

1. 布隆过滤器：在缓存前加一层过滤器，像这样判断key是否存在

   请求 -> 布隆过滤器 -> 存在才查缓存/DB
   

2. 空值缓存：对查询结果为null的key也做短时间缓存
3. 接口鉴权：对批量查询类接口做限流和权限校验

🛠️ 实战中的组合策略

在美团做外卖业务时，我们采用了分级防御策略：

• 第一层：布隆过滤器拦截非法请求
• 第二层：本地缓存+Redis多级缓存
• 第三层：数据库查询前必须获取分布式锁
• 第四层：失败请求降级到默认值

这样分层防御后，系统扛住了去年七夕节每分钟百万级的订单洪峰。如果你正在准备面试，可以重点掌握这种分层防御的思维。

🎁 特别福利

需要面试鸭会员的同学注意啦！通过面试鸭返利网购买可返现25元，相当于用75折的价格获取全年面试题库更新。最近帮团队批量采购时发现的这个羊毛，亲测返现秒到账。

最后提醒大家，缓存设计没有银弹，一定要根据业务场景选择合适的策略。比如金融场景要优先保证数据一致性，而社交feed流可能更关注高可用性。理解原理比死记方案更重要，祝各位面试顺利！