凌晨两点十三分我被电话叫醒。商城主页的品类楼层像被推倒的积木一样一片空白监控大屏上数据库的QPS曲线从平时的800直线飙升到9000Redis连接数打满订单服务超时率冲上30%。后来排查结果让我哭笑不得根本不是代码发布或者数据库故障就是一次日常的定时任务批量重建缓存撞上了活动的开场秒杀。三个词——缓存穿透、缓存击穿、缓存雪崩——一次全占教科书都不敢这么演。如果你也是后端开发这几个词大概率在面试题里背过无数次但真正遇到的时候能立刻判断出“当前是哪种问题”并把手里的方案选对、参数调好、代码落稳的人并不多。这篇文章我不打算做概念堆砌而是把这三种故障形态的成因、判断方法、代码级别的解决方案以及我踩过的那些坑一次性讲透。1. 三者到底怎么区分别再看图鉴式科普了很多文章喜欢用“缓存雪崩是大量key同时过期、击穿是单个热点key过期、穿透是查了一个不存在的key”这种定义式描述听起来很清晰但落地的时候你会发现它们经常混在一起出现就像前面说的那次事故。所以我习惯用两个维度去区分请求目标是不是真实存在以及失效的范围是大还是小。1.1 穿透打到了一个不存在的key缓存穿透本质上是请求在“缓存层”和“存储层”都找不到答案。比如一个用户ID-100的请求、一个商品ID0的请求、或者是爬虫随机拼的IDRedis查不到数据库也没有这条记录。于是每次请求都穿过缓存直接打到数据库上。这里有个执行力很强的歪门邪道思路既然缓存里没有那就别让数据库也白挨打。在缓存和数据库之间加一道“校验层”或者把不可能存在的结果也缓存起来是穿透场景的核心解法。具体的代码和方案在第二章细讲。1.2 击穿单个热点key的“死而复生”瞬间缓存击穿是三者里最“阴”的。它针对的是一个被高并发访问的热点key比如首页的推荐位配置、秒杀商品的库存key。这个key平时能扛住99%的流量但缓存刚好在失效的那一瞬间同时来了几千个请求。它们发现缓存miss了于是一起去数据库重建缓存数据库瞬间被冲垮。这个名字特别形象一个key就像一面墙墙倒的那一秒所有压力瞬时穿透。它和穿透的根本区别在于——数据本身是真实存在的只是缓存恰好过期了。1.3 雪崩大批key一起失效引发连锁反应缓存雪崩就是击穿的“群殴版”。大量的key在同一时间段集体失效比如定时任务批量更新缓存把同一批数据全部写进缓存并设置了相同的过期时间或者Redis实例本身的物理故障导致缓存层全部不可用。我遇到过一个非常经典的雪崩场景运营人员把所有活动商品统一设置了“当日23:59:59过期”结果零点刚过所有商品缓存同时失效系统直接被压垮。本质上雪崩的核心在于失效时间的同步性以及缓存层整体可用性的丧失。1.4 一张表看懂三者的本质区别场景请求的数据是否真实存在影响范围主要矛盾缓存穿透不存在单次请求打穿缓存缓存与数据库都无法命中缓存击穿存在单个热点key失效期间热点key重建的高并发冲突缓存雪崩存在大量key同时失效/缓存层不可用失效时间的同步性与缓存整体可用性这段描述帮助我在线上排查的第一时间建立判断框架先看DB慢查询日志里有没有大量“查不到数据”的请求有就是穿透再看Redis的键空间统计里是否有某个key的访问频率异常高且正好miss有就是击穿如果观测到Redis连接异常或者大量key同时消失那就是雪崩。2. 缓存穿透实战解法双保险比单单一个方案更可靠穿透的解法市面上就两种主流返回空值缓存和布隆过滤器拦截。很多资料把它们作为“二选一”的选项但我的实际操作经验是两者各守一道关卡组合使用才最稳妥。2.1 空值缓存简单粗暴但要注意TTL当一个查询在数据库里没查到数据我不急着让它直接返回null而是把这个“null”也写进Redis设置一个较短的过期时间。这样后续同样的无效请求就能命中缓存不再打到数据库。// 查询用户信息时处理穿透 public UserInfo getUserInfo(Long userId) { String cacheKey user:info: userId; // 1. 先查缓存 String value redis.get(cacheKey); if (value ! null) { // 2. 缓存中存了空值标记直接返回null if (value.equals(EMPTY_MARK)) { return null; } return JSON.parseObject(value, UserInfo.class); } // 3. 缓存未命中查数据库 UserInfo userInfo userMapper.selectById(userId); if (userInfo null) { // 4. 数据库查不到缓存一个空值TTL设置为3分钟 redis.set(cacheKey, EMPTY_MARK, 180); return null; } // 5. 正常数据缓存10分钟 redis.set(cacheKey, JSON.toJSONString(userInfo), 600); return userInfo; }这里有几个实际操作中的关键细节空值的TTL绝对不能长。空值缓存的意义是挡住短期内的恶意请求或数据缺失但一旦数据真的被创建了空值缓存还挡着就会造成数据不一致。我一般把空值TTL设置在60-180秒之间最长不超过5分钟。要区分“真正的空”和“业务无关的默认值”。比如默认头像的URL、默认昵称这些本身是有效数据不应该走空值标记逻辑。空值缓存会消耗Redis内存如果恶意请求构造的随机ID过多比如几百万个不同的无效ID空值缓存方案会撑爆内存。这时候就必须依靠第二道防线。2.2 布隆过滤器拦截非法ID的“准入名单”布隆过滤器的原理本质上是一个位数组配合多个哈希函数。它用极小的空间代价判断一个元素是否“有可能存在于集合中”。注意是“有可能”而不是“一定”。它会误判“可能存在”某个元素但绝对不会漏判——如果一个ID判定为“不存在”那它就一定不在数据库中。我常用的方案是项目启动后把数据库里所有合法的用户ID、商品ID也就是会走查询逻辑的ID全部加载进布隆过滤器。之后每次查询前先过过滤器如果过滤器说“不存在”直接返回null根本不会去查Redis和DB。// 使用Redisson的RBloomFilter实现 Bean public RBloomFilterLong userIdBloomFilter(RedissonClient redissonClient) { RBloomFilterLong filter redissonClient.getBloomFilter(bloom:user:ids); filter.tryInit(1000000L, 0.01); // 预期元素数量100万误判率1% return filter; } // 查询时的拦截逻辑 public UserInfo getUserInfoWithBloomFilter(Long userId) { if (!userBloomFilter.contains(userId)) { // 布隆过滤器判定不存在直接返回拦截穿透 return null; } // 命中过滤器走正常缓存查询流程 return doGetUserInfo(userId); }2.3 布隆过滤器参数设计误判率和空间的计算这里必须提一下参数设置的算法很多人直接用默认值用得不明不白的。布隆过滤器的核心参数有三个预期元素数量n、误判率p、位数组长度m和哈希函数个数k。它们之间存在这样的关系位数组长度 m - (n * ln p) / (ln 2)^2哈希函数个数 k (m / n) * ln 2以100万ID、1%误判率为例m - (1000000 * ln 0.01) / (0.693)^2 ≈ 958万位约1.14MBk (9580000 / 1000000) * 0.693 ≈ 7也就是说只要1.14MB的内存就能容纳100万个ID且误判率控制在1%以内。这里有个工程上的经验判断误判率不要追求极致的0.01%因为内存占用会指数级上升1%-5%的误判率在绝大多数业务场景下完全够用——毕竟被误判放行的请求后续还有空值缓存兜底。如果你使用的是Guava的BloomFilter它内部已经封装好了最优参数计算只需要传入预期数量和误判率即可但了解底层算法有助于你在面试或排查问题时快速判断瓶颈。2.4 为什么不建议“只靠缓存空值”或“只靠布隆过滤器”只靠布隆过滤器的问题是它只能拦截数据库里“确定不存在”的数据但数据是动态的。如果今天用户注册了一个新ID它在布隆过滤器里是不存在的如果不做实时更新这个新用户会被拦截无法查询到自己的数据。只靠空值缓存的问题在前面也提过恶意构造随机ID时内存会爆炸。所以我的实现方案是布隆过滤器做第一道拦截挡住绝大多数恶意无效请求空值缓存做第二道拦截兜住那些“数据库里确实没有但布隆过滤器误判放行”的请求。两层一起才能把穿透率降到极致。提示布隆过滤器不支持删除操作。如果你有删除ID的需求比如注销用户、下架商品是需要重建过滤器或使用布谷鸟过滤器支持删除的。不要为了这个功能自己实现调Redisson或者Guava的现成实现最稳。3. 缓存击穿实战解法互斥锁与逻辑过期怎么选击穿的关键矛盾是“热点key失效瞬间的高并发重建”思路也很直接要么让同一时间只有一个线程去重建缓存要么让旧数据在key失效后的短暂时间内继续对外服务。市面上的成熟方案有四种但我在生产环境实际用过、并且推荐的是下面两种互斥锁Mutex Lock和逻辑过期Logical Expiry。3.1 方案一互斥锁重建缓存只允许一个线程访问DB核心思路是发现缓存miss后不直接查数据库而是先尝试获取一把分布式锁。拿到锁的线程去查数据库并重建缓存其他线程短暂自旋重试等待第一个线程把缓存重建好。public String getHotData(String cacheKey) { String value redis.get(cacheKey); if (value ! null) { return value; } // 缓存不存在尝试获取互斥锁 String lockKey lock: cacheKey; // SET NX EX只有key不存在时才能设置成功 if (redis.set(lockKey, 1, NX, EX, 5)) { try { // 拿到锁查数据库并重建缓存 String dbValue queryFromDb(); redis.set(cacheKey, dbValue, 600); return dbValue; } finally { // 释放锁 redis.delete(lockKey); } } else { // 没拿到锁的线程短暂休眠后重试 Thread.sleep(50); return getHotData(cacheKey); // 递归重试或使用循环重试 } }这段代码的关键点也是我实际踩过坑的地方锁的过期时间要短我一般设置5秒。如果DB查询时间较长锁到期自动释放可能导致并发问题。更稳妥的做法是使用Redisson的RLock实现“看门狗”自动续期避免锁过期但线程还没执行完的情况。递归重试有栈溢出风险高频场景下建议用for循环重试最多重试3-5次超过就返回兜底数据或直接抛异常。重建缓存时一定要用DB的最新数据不要基于旧缓存做修改——因为锁只保证DB查询这步不并发但无法保证数据源自身的一致性。3.2 方案二逻辑过期用旧数据撑住新流量逻辑过期是不设置Redis物理过期时间而是在value里加一个字段记录“业务过期时间”。当读取时发现逻辑时间已过期不是立刻删除key而是返回旧值给用户同时异步发起一个重建线程更新缓存。public String getHotDataByLogicalExpire(String key) { String value redis.get(key); if (value null) { // 缓存不存在可能是Redis重启直接查DB并返回 return queryFromDbAndSetCache(key); } // 反序列化读取逻辑过期时间 CacheObject cacheData JSON.parseObject(value, CacheObject.class); if (cacheData.getExpireTime() System.currentTimeMillis()) { // 未过期直接返回 return cacheData.getData(); } // 已过期尝试获取锁异步重建 String lockKey lock: key; if (redis.set(lockKey, 1, NX, EX, 5)) { try { // 获取锁后再检查一次逻辑时间 // 防止上一个重建线程刚更新完本线程又重建一次 Thread thread new Thread(() - { String newValue queryFromDb(); // 设置新的缓存值逻辑过期时间为当前时间600秒 redis.set(key, newCacheObject(newValue, 600)); redis.delete(lockKey); }); thread.start(); } finally { // 释放锁 redis.delete(lockKey); } } // 返回已过期的旧数据 return cacheData.getData(); }这个方案的优点是读取操作永远不阻塞即使缓存过期了用户拿到的还是旧数据体验几乎无感知。我主推它来应对秒杀场景下的热点商品——因为秒杀场景对“返回旧库存数据”的容忍度比“超时无响应”高得多。但它有一个代价容易出现短期数据不一致因为用户可能读取到过期的数据几秒甚至十几秒。所以对数据一致性极高的业务要慎重对读多写少且一致性容忍度较高的热点数据则非常合适。3.3 两种方案选型表格对比维度互斥锁重建逻辑过期用户体验缓存重建期间部分请求可能等待重试始终能拿到数据旧值数据一致性高读到的一定是重建后的新数据低可能读到过期数据对DB的压力只放行一个线程压力最小高并发时DB可能短暂承压实现复杂度中等需要处理锁的获取、释放、重试相对复杂需要维护逻辑过期时间和异步更新适用场景数据一致性要求高DB响应快读多写少对短时旧数据容忍度高3.4 一个容易被忽略的坑锁的粒度锁的粒度设计很重要。很多人直接对整个业务接口加锁导致所有key的缓存重建都串行化性能断崖式下降。正确的做法是按key粒度加锁也就是每个热点数据的cacheKey对应一把独立的lockKey。这样某个商品重建缓存时其他商品的查询完全不受影响。我在生产环境踩过这个坑后总结出来的规则是锁的粒度越细越好锁的过期时间要远小于业务可接受的等待时间。4. 缓存雪崩实战解法时间随机化与高可用架构双管齐下雪崩的成因可以分两类一是大量key同时过期二是Redis实例不可用。两种情况的解决思路完全不同。4.1 针对“大量key同一时间点过期”最朴素也最见效的做法就是给过期时间加一个随机偏移量。我记得当年为活动任务批量写缓存的时候业务方原本要求“所有商品缓存统一在十分钟后过期”。我直接在代码里把统一过期时间改成了“基础过期时间 随机数”这样就避免了一大波缓存同步失效。// 设置缓存时在原始过期时间基础上加上随机偏移 int baseExpire 600; // 10分钟 int randomExpire baseExpire new Random().nextInt(300); // 加上0~5分钟随机数 redis.setex(cacheKey, randomExpire, value);别看这个改动小实际效果却出奇的好。如果一万个key都在同一秒失效那么加了随机偏移后它们会在5分钟的时间窗口内分散失效DB压力从“瞬时峰值1万QPS”平摊成“持续平稳的几百QPS”。另一个实践是避免设置相同的逻辑过期时间点。比如定时任务更新缓存时很多工程师习惯为所有key设置“当天23:59:59过期”这就人为制造了第二天的雪崩时刻。我一般会让运营数据的过期时间基于“创建时间业务有效时长随机偏移”的逻辑而不是统一对齐到某个自然时间点。4.2 针对“Redis整体不可用”当Redis集群宕机、网络分区或连接池耗尽时所有请求都会绕过缓存直接打向DB这种雪崩更致命。我的方案是构建一个“缓存不可用时的降级链路”public String getDataWithFallback(String key) { try { String value redis.get(key); if (value ! null) { return value; } } catch (Exception e) { // Redis超时或者连接异常记录告警继续走降级逻辑 log.error(Redis异常降级, e); } // 本地缓存兜底Caffeine/Guava Cache String localValue localCache.get(key); if (localValue ! null) { return localValue; } // 本地缓存也没有查DB并更新本地缓存 String dbValue queryFromDb(); localCache.put(key, dbValue); return dbValue; }这个降级链路的精髓在于多级缓存兜底Redis挂了本地缓存顶上本地缓存也没有DB还能扛一阵。配合限流组件比如Sentinel或Hystrix把超出系统承载能力的请求直接快速失败返回提示或降级数据不让无休止的请求把DB打挂。4.3 Redis高可用的基础设施配置降级是兜底手段高可用才是主动防御。我强烈建议在主生产环境使用Redis Sentinel哨兵模式在数据量超过单机内存承载能力时使用Redis Cluster集群模式。哨兵模式至少部署一主两从三哨兵主节点故障时自动完成故障转移业务方无感知。Cluster模式则通过数据分片把key分散到多个主节点任何一个分片挂掉其他分片依然提供服务。另外由于Cluster模式下每个节点默认只负责部分slot单节点宕机导致的缓存不可用范围会被限制在1/总节点数的规模内。这里有个我实际遇到过的问题配置了哨兵但客户端没有配置多节点地址。有些框架的Redis客户端只配了一个主节点地址主节点故障时它依然连老的地址导致连接失败。正确做法是配置多个哨兵地址让客户端通过哨兵动态感知当前主节点。4.4 预防雪崩的几道闸门生产环境中我的雪崩防御体系是分层的网络层对可疑IP进行限流拦截恶意并发请求。网关层接入层配置总并发控制防止瞬时流量冲击。缓存层过期时间加随机偏移核心数据用逻辑过期Redis高可用架构。应用层互斥锁重建热点key多级本地缓存兜底限流熔断器。这套闸门体系在多次大促场景中验证过即使Redis真的出现问题数据库也不会直接被压垮。5. 线上故障排查一夜之间怎么从监控入手定位问题理论讲得再多不会排查等于零。我复盘一下自己是怎么在十分钟内定位到那场“三问题齐爆”的事故的。5.1 看监控指标找线索排查的第一步永远是看监控大盘重点看四个指标指标穿透的特征击穿的慢特征雪崩的特征Redis命中率短期不变或缓慢下降某个key刷新瞬间短暂下降后恢复整体断崖式暴跌后持续低位DB QPS超高且持续单个时间点尖峰高峰持续数秒甚至数分钟接口响应时间未命中时响应缓慢高并发下部分请求超时大面积超时甚至服务熔断Redis连接数正常正常或略高打满或异常那天的监控是Redis命中率一秒内从95%降到60%同时DB QPS暴增。这两个信号同时出现我第一反应是雪崩——因为击穿一般是命中率跌下去又快速涨回来穿透也不可能让命中率波动这么大。5.2 快慢日志定位具体key确认是雪崩方向之后通过Redis慢查询日志和DB慢查询日志很快锁定了命中率暴跌区间内访问量最大的几个key——全部集中在活动商品品类上。再结合Redis-keyspace-notifications检测键失效事件可以看到这些key几乎在同一秒内触发了expire时间和那次定时任务吻合。定位到一批key同时过期是问题根源之后马上把那条定时任务脚本里的“写缓存设置统一过期时间”逻辑揪了出来现场修改成带随机偏移的版本。因为Redis本身没挂所以降级链路没用上但如果你观察到的是Redis连接抛异常就要立刻激活降级代码先把流量从Redis切到本地缓存或限流。5.3 一次实战模拟用JMeter复现击穿建议你在测试环境提前演练一次。我之前用JMeter做过一次击穿压测先把某个热点key删除模拟缓存失效。然后开启200个并发线程循环请求这个key。观察监控DB QPS瞬间冲到200而缓存重建完成后降回0。接着应用互斥锁方案重复上述步骤发现DB QPS会降到1-2其他190多个请求都在等待重试。做过一次这种对比压测你就会对击穿的危害和方案效果有切身体感不至于上线后才手忙脚乱。5.4 线上排查的三大铁律我总结了几条排查时的操作纪律绝对不要在线上直接删除生产key来测试击穿除非你已经确认业务低峰期且方案已上。通过Redis的monitor命令观察实时请求模式注意只筛选关键的访问量大的key否则日志量会大到崩溃。先保命再定位如果DB眼看要被打挂优先执行限流熔断先把流量挡住再慢慢查根因。不要试图在系统挂掉时还保持“完整取证”。6. 综合落地实践一套方案同时防住三种问题前面分析了各自的解法但生产中这三种问题往往交替出现。我推荐一套组合拳你可以直接参考落地。6.1 整体架构分流图所有查询请求先经过布隆过滤器不存在的数据直接返回null这是第一道防线。通过过滤器的请求进入Redis查询命中直接返回未命中判断是否热点key。热点key走逻辑过期或互斥锁方案普通key走空值缓存方案。如果Redis异常启动本地缓存降级和DB限流兜底。这套链路在代码层面是一个标准的多级缓存Query流程public String queryProductDetail(Long productId) { // --- 第一层布隆过滤器拦截 --- if (!productBloomFilter.contains(productId)) { return null; } // --- 第二层Redis查询 --- String cacheKey product:detail: productId; String value redis.get(cacheKey); if (value ! null) { return value; } // --- 第三层本地缓存兜底 --- value localCache.get(cacheKey); if (value ! null) { return value; } // --- 第四层互斥锁重建DB查询 --- String ret getHotDataByMutex(cacheKey); return ret; }6.2 参数配置的心得总结我把自己常用的参数整理成一个速查建议表方便你copy设置时参考参数建议值说明空值缓存TTL60-180秒太短挡不住穿透太长容易数据不一致布隆过滤器误判率1%-5%越低越耗内存1%是均衡点互斥锁过期时间3-5秒要小于DB平均查询时间重建缓存时间互斥锁重试间隔50-200ms太短会空转消耗CPU太长影响请求响应时间逻辑过期预留时间基础TTL的20%-30%保证异步重建有足够时间窗口缓存随机偏移基础过期时间的10%-50%太大导致缓存不生效太小无法错峰本地缓存容量1000-5000个key按业务实际热点key数评估6.3 定时任务批量写缓存一个必改的坏习惯最后单独提一个高频雷区定时任务里用统一的setex批量写缓存。比如一个跑批系统每天凌晨把全量商品信息刷进Redis很多工程师图简单直接for循环set key所有key的过期时间一模一样。一旦某个定时任务延迟到业务高峰前才执行完就相当于给业务埋了一颗定时炸弹——统一过期时间到的那一刻雪崩就来了。我的标准做法是跑批写缓存时按每批或每个key随机分散过期时间如果业务确实需要统一在某个时间点失效那就再加一层懒加载重建即任务先把数据更新至DBCache由读取时逐步重建而不是依靠定时任务统一刷入。7. 写在最后这不想再被半夜叫醒的话那场凌晨三点的故障之后我把缓存相关的所有代码做了一次全面审查不仅修了跑批和过期时间还补上了空值缓存和布隆过滤器两道防线。后来类似的并发场景又来过好几次但监控上的DB曲线始终很平稳再没有人半夜打电话叫醒我。我的体会是缓存这三个问题真正难的地方不在“理解概念”而在于“把方案落到代码里时能不能提前想到边界条件”。锁过期了怎么办、空值会不会撑爆内存、布隆过滤器误判了后续靠谁兜底、Redis挂了业务能不能降级——这些问题每一个都是实操里能碰到的事情。如果你现在正准备重构自己系统的缓存层我建议顺序是先给Redis加高可用再给热点key做好互斥锁或逻辑过期然后在入口加上布隆过滤器和空值缓存最后定期做一次压测模拟一种或多种故障同时发生的情况。不要等到监控报警才去思考方案那会儿你和我一样只能手忙脚乱看日志了。这套组合拳运行稳定之后你会发现“缓存雪崩、缓存击穿、缓存穿透”这几个词在咨询记录里会渐渐消失。它们最终沉淀为你对系统容错能力的一种直觉而不是面试答题时的三个名词。