Redis的缓存雪崩、缓存穿透、缓存击穿是什么？怎么解决？
目录
一、先分清：穿透、击穿、雪崩，到底差在哪？
二、缓存穿透：防的是 “不存在的请求”
1. 问题本质
2. 我的项目里是这么解决的
① 参数校验 + 拦截
② 缓存空值
③ 布隆过滤器（高风险场景用）
三、缓存击穿：防的是 “热点 key 瞬间过期”
1. 问题本质
2. 我的两种方案，各有适用场景
方案一：互斥锁（强一致性首选）
方案二：逻辑过期（高并发场景首选）
四、缓存雪崩：防的是 “大面积失效或 Redis 挂了”
1. 问题本质
2. 我在项目里的系统级防护
① 给 TTL 加随机值
② Redis 高可用
③ 多级缓存兜底
④ 限流熔断
五、我的总结：怎么根据场景选方案？
最后说句实在的
做 Java 后端开发，谁没被 Redis 缓存问题坑过？
高峰期一个请求进来，Redis 没查到，直接打穿到数据库，瞬间 CPU 飙满、连接池打满，接口直接雪崩。这背后，往往就是缓存穿透、击穿、雪崩这三个问题在搞鬼。今天我就用最直白的方式，把这三个问题掰开揉碎，讲清楚它们的本质区别、风险点，以及你在项目里可以直接抄的解决方案。
一、先分清：穿透、击穿、雪崩，到底差在哪？
很多人面试都分不清这三个，其实一句话就能说清楚：
- 穿透：查的东西，本来就不存在。
- 击穿：单个热点东西，刚好过期了。
- 雪崩：一堆东西，同时过期了，或者 Redis 直接挂了。
你可以想象成一个超市：
- 穿透：你要买一个店里根本不卖的东西，问一次服务员一次，问十次十次都得去仓库查，仓库迟早被你烦死。
- 击穿：店里最热门的可乐卖完了，成千上万的人同时问服务员，服务员都得去仓库拿，瞬间就挤爆了。
- 雪崩：店里所有的饮料同时卖完了，或者仓库直接炸了，所有人都挤向唯一的通道，整个店直接瘫痪。
问题 核心特征 典型场景 主要风险 常见方案 缓存穿透 查询的数据根本不存在 恶意请求、错误参数、爬虫 数据库被无效请求打满 参数校验、缓存空值、布隆过滤器 缓存击穿 单个热点 key 失效瞬间并发回源 热门商品、热点店铺、活动库存 数据库被热点流量冲垮 互斥锁、逻辑过期、热点预热 缓存雪崩 大量 key 同时失效或 Redis 故障 批量导入缓存、整点统一过期、节点宕机 请求成片压垮数据库和下游 随机 TTL、高可用、多级缓存、限流熔断
二、缓存穿透：防的是 “不存在的请求”
1. 问题本质
你请求的数据，Redis 里没有，数据库里也没有。每次请求都得打到数据库，数据库查不到，也没法回写缓存，结果就是数据库被一堆无效请求打满。
典型场景：恶意爬虫、参数校验不严，比如用户用id=-1疯狂请求你的接口。
2. 我的项目里是这么解决的
我一般用三层防护，成本低，效果好：
① 参数校验 + 拦截
先在入口把明显非法的请求挡掉，比如负数 ID、格式错误的手机号、空参数，不让它们进缓存层。
② 缓存空值
数据库查不到时，把空字符串也缓存起来，设置一个很短的 TTL，比如 2 分钟。这样下次再查同一个不存在的 ID，Redis 直接返回空，不会再打数据库。
// 伪代码 Shop shop = getById(id); if (shop == null) { // 把空值写入Redis，2分钟过期 stringRedisTemplate.opsForValue().set(key, "", 2, TimeUnit.MINUTES); return null; }③ 布隆过滤器（高风险场景用）
如果你的接口经常被攻击，请求量特别大，那就用布隆过滤器。把所有可能存在的 key 提前存进去，请求来时先判断，不存在的直接拒绝，连 Redis 都不碰。缺点是要提前规划数据量，有极微小的误判率。
三、缓存击穿：防的是 “热点 key 瞬间过期”
1. 问题本质
某个超级热门的 key，比如秒杀商品、爆款店铺，在高峰期刚好过期，成千上万的请求同时发现缓存失效，一起回源数据库，直接把数据库冲垮。
2. 我的两种方案，各有适用场景
方案一：互斥锁（强一致性首选）
只让一个请求去查库重建缓存，其他请求要么等待重试，要么直接返回旧数据。
// 伪代码 String lockKey = "lock:shop:" + id; boolean isLock = tryLock(lockKey); if (!isLock) { // 没拿到锁，休眠一下重试，或者直接返回旧数据 Thread.sleep(50); return queryWithMutex(id); } // 拿到锁了，去查库重建缓存 try { Shop shop = getById(id); stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30, TimeUnit.MINUTES); } finally { unLock(lockKey); }优点是数据一致性好，缺点是会有短暂等待，对用户体验有一点点影响。
方案二：逻辑过期（高并发场景首选）
不设物理 TTL，而是在缓存里存一个逻辑过期时间。请求来了，先看逻辑时间没过期，直接返回；如果过期了，先返回旧数据，再开个新线程去后台异步更新缓存。
优点是用户体验丝滑，完全无等待；缺点是会短暂返回过期数据，适合一致性要求不高的热点读场景。
四、缓存雪崩：防的是 “大面积失效或 Redis 挂了”
1. 问题本质
大量 key 同时过期，或者 Redis 集群整体宕机，导致所有请求瞬间打到数据库，形成级联故障。
2. 我在项目里的系统级防护
雪崩不能靠单一方案，必须多管齐下：
① 给 TTL 加随机值
把过期时间打散，避免所有 key 同时在整点失效。
// 伪代码 // 基础30分钟，加0-10分钟随机值 int random = new Random().nextInt(10); stringRedisTemplate.opsForValue().set(key, value, 30 + random, TimeUnit.MINUTES);② Redis 高可用
用主从、哨兵或者集群部署，避免单点故障导致整个缓存层挂掉。
③ 多级缓存兜底
在 Redis 前面再加一层本地缓存，比如 Caffeine。Redis 出问题时，热点数据还能靠本地缓存扛一波流量。
④ 限流熔断
给接口加上限流，比如每秒只允许 100 个请求回源数据库，超过的直接降级返回默认数据，保护数据库不被冲垮。
五、我的总结：怎么根据场景选方案？
- 普通业务 key：缓存空值 + 合理 TTL，解决穿透问题。
- 热点读 key：互斥锁或逻辑过期，解决击穿问题。
- 系统层面：随机 TTL + Redis 高可用 + 限流降级，预防雪崩。
记住，没有银弹，只有最合适的组合拳。
最后说句实在的
缓存这三个问题，本质上都是高并发下的 “木桶效应”—— 缓存层一旦出现短板，所有压力都会瞬间传导到数据库。所以写缓存代码的时候，别只想着怎么存进去，多想想它过期了怎么办、挂了怎么办、被恶意攻击了怎么办。