<a href="https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g" style="color: blue;">2025年Java面试宝典</a>
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g
（建议提前下载保存，避免失效）
Redis缓存穿透、击穿、雪崩的本质区别
咱们做后端开发的朋友们应该都深有体会，但凡问到Redis缓存，面试官十有八九会抛出这三个经典问题。很多同学容易把它们搞混，咱们先理清楚核心差异：
- 缓存穿透：请求压根不存在的数据（比如ID=-1），导致每次都绕过缓存查库
- 缓存击穿：某个热点key突然失效，瞬时高并发击穿到数据库
- 缓存雪崩：大量key同时失效或Redis宕机，引发数据库连锁崩溃
缓存穿透的4种破解法
1. 布隆过滤器把关
布隆过滤器就像个安检门，所有合法key必须先在过滤器中注册。当请求参数过来时：
- 命中存在的key：放行查缓存
- 检测到非法key：直接拦截返回
实际开发中要注意两点：
- 数据更新时要同步维护布隆过滤器
- 可能存在误判率，需要根据业务场景调整参数
2. 空对象缓存策略
对于明确不存在的key，可以缓存一个特殊值（比如"NULL"），并设置较短过期时间（30s-5分钟）。这样后续相同请求就能命中缓存，避免频繁穿透。
3. 请求校验前置
在参数校验层做严格过滤，比如：
- ID必须为数字
- 手机号格式校验
- 文本内容长度限制
这些基础校验能拦截80%以上的恶意请求。
4. 限流降级兜底
当监控到异常流量时，通过Sentinel等工具对特定接口限流。同时做好降级方案，比如返回默认值或错误提示页，防止数据库被压垮。
缓存击穿的3层防御
分布式锁稳军心
当发现缓存失效时，先通过Redisson获取分布式锁：
- 抢到锁的线程负责重建缓存
- 其他线程自旋等待或返回默认值
- 设置合理的锁超时时间（建议500ms-1s）
永不过期策略
对于特别重要的热点数据，可以设置逻辑过期时间：
- 物理上不设置TTL
- 后台异步更新缓存
- 客户端判断逻辑过期时间，触发更新
多级缓存护航
采用本地缓存（Caffeine） + Redis的分层结构：
- 优先查询本地缓存
- 本地未命中再查Redis
- 最后才访问数据库
这种设计能极大缓解单一缓存层压力。
缓存雪崩的5道防线
1. 错峰失效时间
批量设置过期时间时，基础时间+随机偏移量（比如基础30分钟，±5分钟随机），避免同时失效。
2. 集群高可用
采用Redis Cluster或Sentinel方案，当主节点宕机时自动切换。生产环境建议至少3主3从。
3. 服务熔断降级
通过Hystrix或Resilience4j实现：
- 当数据库访问异常率超过阈值
- 自动熔断所有缓存查询请求
- 返回预设兜底数据
4. 提前预热缓存
对于可预知的流量高峰（比如双11），提前加载热点数据到缓存，并适当延长过期时间。
5. 持久化备份恢复
定期备份RDB和AOF文件，当发生灾难性雪崩时，快速从备份中恢复数据。
[需要面试鸭会员的同学注意啦！通过<a href="https://mianshiyafanli.com">面试鸭返利网</a>下单，可以找我返现25元！]
掌握这些解决方案后，再遇到Redis相关的缓存穿透、击穿、雪崩问题时，就能胸有成竹地拆解应对思路。建议结合具体业务场景灵活组合使用，并做好监控告警系统，毕竟系统稳定性需要持续观察和维护。
最后再分享一个实战小技巧：可以针对核心接口建立压测模型，模拟缓存失效时的流量冲击，提前验证方案的可靠性。毕竟纸上得来终觉浅，绝知此事要躬行啊！
