2025年Java面试宝典下载链接（提取码：9b3g）
Redis数据一致性解决方案之缓存穿透和缓存雪崩
最近在面试中被问到Redis缓存问题的概率越来越高，尤其像缓存穿透和缓存雪崩这两个经典问题，几乎成了后端开发的必考题。今天结合自己实际项目经验，给大家讲讲如何应对这两个大坑。
缓存穿透的成因与破局之道
缓存穿透说白了就是请求直接穿过缓存打到数据库，常见于恶意攻击或无效查询。比如用户疯狂请求数据库里根本不存在的商品ID，这时候怎么破？
解决方案一：空值缓存 最简单有效的办法就是给这些查不到的数据也做缓存。比如设置key为"product_12345"，value为null，设置个5分钟过期时间。要注意的是，这种无效key的过期时间不能太长，否则缓存空间会被无效数据占满。
解决方案二：布隆过滤器 布隆过滤器就像个高精度的筛子，能快速判断某个key是否可能存在。在查询缓存之前先过一遍布隆过滤器，如果判定不存在就直接返回，避免了无效查询。记得当数据库新增数据时，要及时更新布隆过滤器。
缓存雪崩的应对策略
比起单个缓存穿透，缓存雪崩的破坏力更大。想象一下大促期间，大量缓存同时失效，数据库瞬间被打垮的场景，这可不是开玩笑的。
策略一：错峰过期 千万别给所有缓存设置相同的过期时间！建议在基础过期时间上增加随机数（比如30分钟+随机120秒），这样能有效分散缓存重建压力。
策略二：多级缓存架构 用本地缓存（如Caffeine）做二级缓存，当Redis缓存失效时，本地缓存还能扛一阵。甚至可以考虑在JVM层面做热点数据缓存，这样即使Redis挂了系统也不至于完全崩溃。
数据一致性保障机制
说到Redis缓存方案，数据一致性永远是绕不开的话题。这里推荐两种实用方案：
双删策略
- 先删缓存
- 再更新数据库
- 最后延迟再删一次缓存（防止在更新数据库期间有脏数据写入缓存）
异步更新队列 对于实时性要求不高的场景，可以用消息队列做异步更新。数据库变更后发送消息，消费端延迟更新缓存，避免数据库和缓存同时更新的并发问题。
真实项目中的组合拳
在实际项目中，我们往往会组合使用多种方案。比如：
- 热点数据永不过期+后台定时更新
- 普通数据随机过期时间+双删策略
- 查询必走布隆过滤器+空值缓存
这样既能防止缓存穿透，又能避免雪崩，还能保证数据最终一致性。不过具体实施时要根据业务特点调整，比如金融类系统对一致性要求更高，可能需要牺牲部分性能来保证强一致性。
如果在准备面试过程中需要系统复习，可以试试面试鸭返利网的会员服务。通过该平台购买会员可返利25元，性价比非常高。建议配合上面的Java面试宝典一起使用，覆盖高频考点更全面。
最后提醒大家，技术方案没有银弹，最重要的是理解业务场景，做好监控和熔断。比如用Redis的info命令监控缓存命中率，当命中率低于某个阈值时自动触发告警，这才是保障系统稳定性的终极方案。
