缓存一致性、穿透击穿雪崩与两级缓存实战指南

做开发这几年，缓存大概是每个项目里都绕不开的“老朋友”了。第一篇里我聊了聊缓存到底解决了什么问题——本质就是拿空间换时间，以及它是怎么靠着局部性原理在CPU、操作系统和应用程序里协同配合的。这篇是系列的第二篇，我想把话题从“缓存是什么”拉到“缓存怎么用才不出问题”上。你会发现，缓存系统真正的难点从来不是“加个缓存”，而是加了缓存之后，数据库、缓存、业务逻辑三者之间的数据一致性和异常防护。这篇会聚焦在几个线上最容易踩坑的点：缓存更新策略、一致性问题、穿透击穿雪崩，以及一套能直接抄作业的两级缓存工程样例。

不管你是刚接触后端开发的学生，还是已经在维护线上接口的工程师，这篇文章都值得花二十分钟慢慢看。废话不多说，直接进正题。

1. 先把缓存的“世界观”理顺：从第一篇走到第二篇

第一篇的结论可以用一句话概括：缓存是利用局部性原理，把频繁访问的数据放到更快的存储介质里，用“空间换时间”来降低延迟、减轻下游压力。

但真正搞工程的人都知道，这句话说起来轻巧，做起来全是坑。缓存引入后，你不再只是面对数据库，而是面对一套多级存储架构。一个标准的三层读路径是：客户端请求 → 本地缓存（如进程内）→ 分布式缓存（如集中式缓存服务）→ 数据库。哪一层命中，哪一层压力就小，但每一层都有自己的脾气。

我见过太多同学把缓存当成“加了就能快”的万能药，结果上线后出现数据对不上、缓存雪崩、DB备用库被打爆等等问题，然后开始怀疑人生。所以第二篇我的目标很明确：先把缓存的访问模式梳理清楚，然后重点攻克一致性，最后用一套实战方案把前面所有知识串起来。

这篇的核心关键词是“一致性”和“异常防护”。如果你把这两个问题想清楚了，那缓存对你来说就不是玄学，而是基本功。

这里也给没看过第一篇的读者补充一个背景：我聊的缓存不局限于某一种技术组件，CPU缓存、本地内存缓存、分布式缓存服务，背后的思想都是同一套。只是本篇更偏向应用层，以日常业务开发里最常见的本地缓存和集中式缓存为例展开，原理同样适用。

2. 缓存的访问模式与写入策略：先搞清楚读写路径再谈优化

很多文章一上来就讲Redis命令、讲Caffeine参数，但我更建议你先想清楚一件事：你的业务到底适合哪种读写模式。模式没选对，后面的配置全是在错误的地基上盖楼。

2.1 旁路缓存（Cache Aside）：最主流的读写姿势

旁路缓存，也叫Cache Aside Pattern，是目前业务系统里最常用的模式。它的读路径是：

• 读请求先查缓存；
• 命中直接返回，叶子流程结束；
• 未命中则查询数据库；
• 把查询结果回填到缓存，设置过期时间，然后返回给调用方。

写路径则是：先更新数据库，再删除缓存。

很多同学第一次看会问：为什么写入时是删缓存，而不是更新缓存？原因有两个。第一，更新缓存意味着要计算最新的值，而缓存里的数据往往是多个字段组合、甚至经过序列化处理的，更新成本高；删除则是一次O(1)的操作，下次读请求自然会把新值重新回填。第二，更新缓存存在并发时序问题：两个线程同时写数据，先到的线程A更新缓存为值1，后到的线程B更新缓存为值2，如果数据库的更新顺序恰好是B先A后，缓存里最后留下的值2就对不上数据库的最终值1。删除缓存则天然规避了“缓存写值顺序错乱”的问题，因为下一次读一定会重新构建。

那为什么是“先更新数据库，再删缓存”，而不是“先删缓存，再更新数据库”？这里有个并发窗口问题：如果先删缓存，紧接着一个读请求发现缓存为空，就会去查数据库，而数据库此时还没完成更新，读到的还是旧值，回填到缓存后，后续一段时间内所有请求都会命中这个旧缓存。相比之下，“先更库再删缓存”的窗口小得多，只有在数据库更新完成、缓存尚未删除的极短时间内，老缓存才会被读到，但这个概率和影响都远小于前者。

实操结论：默认无脑选“先更新数据库，再删除缓存”。具体原因我下面会用一整个章节讲透。

2.2 读穿透与异步写：当应用层想“偷懒”时

除了旁路缓存，还有两种模式你会经常在框架和中间件里遇到。

一种是读穿透（Read Through）。在旁路缓存里，应用代码需要自己做“查缓存→查库→回填”的逻辑；而在读穿透模式下，缓存组件自己负责在未命中时回源加载。应用层只调一个接口，逻辑更简洁。代价是缓存组件得具备回源能力，要么用支持该语义的中间件，要么自己封装一层缓存代理。比如你封装一个CacheService，内部统一处理缓存逻辑，对调用方隐藏数据库交互，这就是一种轻量级的读穿透实现。

另一种是异步写（Write Behind），也叫Write Back。写入时只更新缓存，然后异步批量把数据写到数据库。这个模式性能极好，因为写操作不再同步阻塞在数据库上，适合高写入的场景，比如埋点采集、计数器累加。但代价是：如果缓存节点在数据落库之前宕机，数据就丢了。所以它只适合“丢一点可接受”的业务，绝不适合订单、余额这类强一致场景。

这三种模式我整理了一张对比表，方便你选型时快速决策：

换成人话：Cache Aside是你自己动手丰衣足食，Read Through是找个管家帮你买菜，Write Behind则相当于把账先记在小本本上、月底再统一报账——快是快，但小本本丢了就哭吧。

3. 缓存一致性：最坑的部分，没有之一

如果说缓存是给系统穿的一件防弹衣，那缓存一致性就是防弹衣上最容易脱线的那块布料。实测下来，线上缓存问题十有八九都能归结为“某个时刻数据库和缓存对不上”。

3.1 不一致是怎么发生的

根本原因在于：数据库和缓存是两套独立的存储系统，之间没有任何原生事务保证。你更新数据库和操作缓存，是两次独立的调用，中间任何一步失败、任何并发交错，都可能导致两边数据不一致。

我举个特别常见的场景：一个商品库存数据，初始值为100。管理员把库存改成50，代码执行了“先更新数据库为50，再删除缓存”。但就在数据库更新成功、缓存删除尚未执行的那几毫秒里，有个读请求来了，发现缓存还在（里面是旧值100），直接返回100给用户。用户看到的库存还是100，虽然数据库已经是50了。这种短暂的不一致在很多业务里可以接受，但如果窗口被拉长，比如删除缓存失败，那问题就大了——缓存会一直保留旧值100，直到过期，那可能是几分钟甚至几小时。

3.2 你会遇到的四种写顺序问题

我帮大家把所有组合捋一遍，你就明白为什么“先更库再删缓存”是五边形战士了。

第一种顺序：先更新数据库，再删除缓存。缺点上文说了，删除可能失败，导致缓存长期是旧数据。但它的并发风险最小，因为写操作完成后缓存直接被删掉，旧值暴露窗口极短。

第二种顺序：先更新数据库，再更新缓存。这个坑最隐蔽。两个写线程并发执行时，数据库的最终顺序和缓存的写入顺序未必一致。比如线程A把数据库改为1，线程B把数据库改为2，最终数据库是2；但两个线程更新缓存的顺序可能反过来：B先更新缓存为2，A后更新缓存为1，最终缓存是1，和数据库对不上，而且这个错值会一直缓存到过期。

第三种顺序：先删除缓存，再更新数据库。上文提到过，删除后读请求会带着旧值回填，造成长时间脏数据。如果这个过程中写请求延迟较高，脏数据窗口还会进一步拉长。

第四种顺序：先更新缓存，再更新数据库。风险最大，缓存先成功、数据库失败，那缓存里的新值和数据库的旧值无法对齐，而且缓存没有天然回滚机制。

综合下来，你应该明白了：先更库后删缓存，虽然不够完美，但是四种顺序里风险最低、最好兜底的。

3.3 延迟双删与最终一致兜底

那删除缓存失败怎么办？业界有一个很经典的补救策略：延迟双删。

所谓延迟双删，核心操作是：更新数据库后，删除缓存；等待一小段时间；再删除一次缓存。第二次删除的作用，是清掉“第一次删除之后、等待窗口内可能被读请求回填的旧缓存”。

可能有人会问：既然第二次也是删，第一次删完后还是可能被回填，那等待多久合适？答案是：等待时间要大于“一个读请求从发现缓存miss到查库并回填缓存”的耗时。把这个窗口覆盖住，第二次删除基本能清干净。实际项目中，我会先用默认值500毫秒到1秒，然后根据监控数据里的缓存回填耗时去调整。注意，这个时间不是越长越好，你等待越久，不一致窗口就越长。

配合延时双删，我还会给所有缓存设置一个合理的过期时间（TTL）。这才是终极兜底：哪怕前面所有手段都失效了，缓存也总会在某个时间点过期，触发重新加载，让数据回到最终一致。没有TTL的缓存，就像没有刹车还上了高速的车，出事只是时间问题。

提示：延迟双删不能完全解决一致性，它只是把不一致窗口压缩到可接受范围。如果业务对一致性要求极高（比如金融类），建议直接放弃缓存，或者引入分布式事务、数据库变更订阅等更重的手段。

4. 穿透、击穿、雪崩：缓存三劫到底怎么防

如果说一致性是缓存系统的内伤，那穿透、击穿、雪崩就是缓存系统的急性病。三者听起来像，但成因完全不同，对应的药方千差万别。我分别拆开讲。

4.1 缓存穿透：查不存在的Key，也要防

穿透指的是：查询一个缓存和数据库里都不存在的key。因为缓存没有这个key，每次请求都会直接打到数据库，如果攻击者或前端bug持续生成随机key，数据库直接被拖垮。

我见过一个后台系统，前端下拉框在某些异常情况下会把未初始化的ID发给后端，后端拿这个随机ID去查缓存、查库，每次都Miss，数据库瞬间多了几十万次无效查询。

解决方案有两个最常用。

第一个是缓存空值。当数据库查询结果为空时，也把这个“空结果”缓存起来，设置一个较短的TTL，比如60秒。这样后续同样的key会命中空缓存，不再落到数据库。这个方法简单粗暴，但要注意空值缓存的时间不能太长，否则业务上新增了合法数据后，用户要等缓存过期才能看到。

第二个是布隆过滤器（Bloom Filter）。它的原理是：预先把所有可能存在的主键（比如用户ID、商品ID）放入一个bitmap结构，查询前先判断key在不在过滤器里。如果过滤器说“不在”，那一定是真的不在，直接返回空；如果说过“在”，有可能是误判，还需要去缓存和数据库里确认。

布隆过滤器最大的好处是空间占用极小且查询效率极高，缺点是标准实现不支持删除（因为多个key的哈希会映射到同一个bit位，你不能确定某一位是不是被其他key占用）。如果业务需要频繁删除key，可以用Counting Bloom Filter，或者直接用支持类似语义的Redis模块。

我用Guava的BloomFilter给你一段最小示例：

import com.google.common.hash.BloomFilter; import com.google.common.hash.Funnels; // 预估10000个元素，误判率设为0.01 BloomFilter<Long> bloomFilter = BloomFilter.create( Funnels.longFunnel(), 10000, 0.01); // 初始化：把系统中所有合法ID放进去 for (Long id : loadAllValidIds()) { bloomFilter.put(id); } // 查询拦截 public Object getById(Long id) { if (!bloomFilter.mightContain(id)) { return null; // 一定不存在，直接返回 } return cacheAndDbQuery(id); }

注意，布隆过滤器如果部署在应用内存里，重启后会丢失，需要持久化或用外部存储重建。

4.2 缓存击穿：热点Key瞬间失效

击穿和穿透的本质区别是：这个key在缓存里是存在的，只是在某个瞬间突然过期了，而偏偏这个key是热点key，比如大促时的商品详情、秒杀活动的库存。过期的那一瞬间，成千上万个请求同时发现缓存miss，一起冲向数据库，数据库瞬间被打满。

解决击穿的思路很简单：让“重建缓存”的过程只被一个线程执行。

第一种方式是互斥锁。当缓存miss时，只有拿到锁的线程才允许去查数据库并回填缓存，其他线程等待锁释放后重新查缓存。需要注意的是，分布式环境下要用分布式锁（比如基于集中式缓存服务的SET NX命令），单机环境下用进程内锁即可。

这里是伪代码示例：

public Object getProduct(String productId) { Object value = cache.get(productId); if (value != null) return value; String lockKey = "lock:product:" + productId; boolean locked = tryLock(lockKey, 3_000); if (!locked) { // 没抢到锁，短暂等待后重新查缓存 sleep(50); return cache.get(productId); } try { // 二次检查，防止上一个持锁线程已经回填 value = cache.get(productId); if (value == null) { value = database.query(productId); cache.set(productId, value, 300); } return value; } finally { unlock(lockKey); } }

这里有两个关键细节：一是抢不到锁的线程不要直接去查数据库，而是短暂自旋后重新查缓存，否则锁就失去意义了；二是锁一定要设置过期时间，避免持锁线程宕机导致死锁。

第二种方式是逻辑过期。缓存不设置物理过期时间，而是在value里额外存一个逻辑过期时间戳。查询时发现逻辑过期，不阻塞地返回旧值，同时异步发起一个线程去更新缓存。这个方案适用于对短暂旧值不敏感的业务，而且性能最好，因为读请求永远不会被阻塞。

第三种方式是热点key永不过期 + 后台主动刷新。比如把商品详情缓存设置为不过期，由定时任务在低峰期批量预热更新。这个方案最简单，但需要自己管理刷新调度，不适合更新频繁的数据。

4.3 缓存雪崩：大面积同时失效

雪崩和击穿的区别在于“范围”：击穿是单个热点key失效，雪崩是大量key同时失效，或整层缓存不可用。典型场景：你在代码里给所有商品缓存设置了同样的过期时间，比如统一在凌晨零点过期，那零点一到，海量请求同时Miss，数据库请求量瞬间暴涨。

防雪崩第一板斧：过期时间加随机值。比如统一TTL是300秒，实际设置时再加一个0到60秒的随机偏移，这样不同key的过期时间错开，“集体阵亡”的概率大大降低。

防雪崩第二板斧：引入多级缓存。本地缓存（进程内）作为第一层，集中式缓存作为第二层，数据库作为第三层。即使集中式缓存节点宕机，本地缓存依然能扛住一部分请求，留给系统缓冲时间。虽然本地缓存存在多实例不一致问题，但配合短TTL和广播刷新，是可以接受的折衷。

防雪崩第三板斧：限流、熔断、降级。缓存Miss时，如果数据库压力已超过阈值，可以返回降级数据（比如旧缓存快照、默认值），或者直接拒绝一部分请求。没有系统能在所有组件全部故障时还完全正常，关键是要保证“缓慢失败”而不是“瞬间死亡”。

我把三个问题的区别和应对整理在下面，方便你面试或复盘时快速对照：

5. 工程落地：搭一个可复用的两级缓存示例

到这里，你会发现前面所有方案单独看都明白，但组合起来用就不是一回事了。我给你一个我在实际项目中多次使用的两级缓存框架，你可以照着抄，再结合自己的业务做调整。

5.1 为什么需要两级缓存：本地缓存与集中式缓存的分工

日常业务一般不会只用一层缓存，至少是“本地缓存 + 集中式缓存”的组合。

本地缓存（比如Caffeine）的优点有三个：一是快，纯内存访问，耗时通常在微秒级别；二是不依赖网络，集中式缓存挂了它还能撑一会儿；三是适合存放“几乎不变”的配置数据。缺点也很明显：每个应用实例都有自己的本地缓存，数据更新后无法实时同步到所有实例，所以它不适合一致性要求高的数据。

集中式缓存（比如常规的分布式缓存服务）作为共享存储，解决的是跨实例一致性问题。所有实例读写同一个缓存，数据天然全局一致（或者说只要更新它，各实例读到的就是新值）。代价是每次访问都有一次网络IO，性能比本地缓存低一个量级，而且它一旦不可用，影响范围更大。

合理的分工是：把变化频率低、读量大的数据放本地缓存；把一致性要求较高、需要跨节点共享的数据放集中式缓存。业务里常说的“配置项”“基础数据字典”“商品基础信息”，适合本地缓存；“库存实时数”“用户最新状态”，则更适合集中式缓存。

5.2 关键配置与代码骨架（Caffeine + 集中式缓存）

核心类可以这么设计：一个CacheManager，内部封装Caffeine和Redis，对外提供get/put/delete三个方法，并暴露缓存统计。

public class CacheManager { private final Cache<String, Object> localCache; private final RedisTemplate<String, Object> redisTemplate; public CacheManager(RedisTemplate<String, Object> redisTemplate) { this.redisTemplate = redisTemplate; this.localCache = Caffeine.newBuilder() .maximumSize(10_000) // 最多缓存10000条 .expireAfterWrite(60, TimeUnit.SECONDS) // 本地缓存60秒过期 .recordStats() // 开启统计 .build(); } public Object get(String key) { Object localValue = localCache.getIfPresent(key); if (localValue != null) return localValue; Object remoteValue = redisTemplate.opsForValue().get(key); if (remoteValue != null) { localCache.put(key, remoteValue); return remoteValue; } return null; } public void put(String key, Object value, long ttlSeconds) { redisTemplate.opsForValue().set(key, value, ttlSeconds, TimeUnit.SECONDS); localCache.put(key, value); } public void delete(String key) { redisTemplate.delete(key); localCache.invalidate(key); } }

两个非常关键的配置项是本地缓存的maximumSize和expireAfterWrite。maximumSize要根据实例内存和业务量评估，设置得太大容易OOM，太小命中率又不好看；过期时间也要结合业务容忍度来调，一般是30秒到几分钟。我这里给的是相对稳妥的默认值：10000条、60秒，实际用的时候按业务做压测调整。

读流程上，当应用要读一个数据时，优先本地缓存，miss再查集中式缓存，再miss才查数据库，命中后逐级回填。这样做的收益是：大量热点请求被本地缓存拦住，集中式缓存压力大幅降低，数据库只在真正没有缓存的情况下被访问。

写流程上，更新数据库成功后，需要同时删除集中式缓存和本地缓存。本地缓存删除要注意一个细节：因为本地缓存是每个实例独立的，你在这个实例删了，其他实例的本地缓存还在，所以要用广播机制通知其他实例失效，常见方案是借助消息队列发布一个“缓存失效”事件，各实例订阅后清理自己的本地缓存。如果业务对一致性的容忍度较高，也可以不做广播，靠本地缓存短TTL自然过期，减少复杂度。

5.3 热点数据更新的广播思路

广播失效的具体实现，我建议用发布订阅模型。数据变更后，应用发送一条包含key的信息到消息队列，所有在线实例消费到这条消息后，统一执行本地缓存删除和集中式缓存删除。这样做的好处是，除了更新数据库的实例之外，其他实例也能第一时间清掉脏数据，而不是等到TTL自然过期。

在这个模型里，还有一个细节值得注意：发布出去的key最好是原始的业务key，消费端拿到后先对key做规范化处理，再执行删除。否则因为key拼接规则不一致，可能出现“公告删A，实例删B”的尴尬结果。

6. 实战踩坑记录：三个让我改了三版代码的问题

理论说多了，来点真实的。下面的三个问题都是我在实际系统中真实遇到、也真实“掉坑”后重构的，每个都很有代表性。

6.1 缓存不新鲜：一定时间后数据对不上

背景是某后台管理系统的配置数据。运营人员在管理端修改了系统配置，但前台页面一直显示旧值，重启服务才恢复。

排查过程：我先看前台代码，发现读取走的是两级缓存：本地缓存 + 集中式缓存。管理端更新时，只更新了数据库，删除了集中式缓存，但本地缓存没有同步失效。由于本地缓存的TTL设置得比较长（当时是30分钟），所以前台在TTL过期前永远读到本地旧值。这听起来不复杂，但当时排查了很久，因为本地缓存是隐性的，日志里根本看不到命中情况。

修正方案：把本地缓存TTL缩短到60秒，并引入消息队列广播失效事件。管理端更新数据库后，不仅删集中式缓存，还发一条失效消息，各实例消费后删除本地缓存。这样修改后，“改配置马上生效”变成常态，而不是偶尔的成功。

这个问题的教训是：加了本地缓存却不设计它的失效机制，等于给自己埋雷。

6.2 缓存穿透导致数据库压力飙升：布隆过滤器救场

背景是一个提供用户维度的查询接口。某段时间数据库的QPS突然涨了十倍，慢查询日志里全是类似WHERE user_id = 某个不存在的ID的SQL。看了下调用来源，是前端在某个异常逻辑下把未初始化的ID传给了后端。

当时缓存里不存在这些user_id，数据库也没有，但每个请求都检查了缓存和数据库两遍，数据库压力自然上来了。修复分三个阶段：先在业务入口加参数校验，拦截明显不合法的ID；然后加了一层布隆过滤器，把所有有效user_id预先放进去；最后对数据库空结果做了短TTL缓存，达到真正的“一劳永逸”。

踩坑在于：布隆过滤器要随用户数据的增删及时更新，否则新注册用户的ID可能被判为“不存在”，导致新用户数据永远进不了缓存。所以每次新增用户，都要记得把新ID同步加入过滤器。

6.3 热点Key导致的服务抖动：互斥锁和逻辑过期之争

背景是某商品详情接口。大促流量进来后，这个商品变成超级热点，缓存过期的那一瞬间，所有请求同时穿透到数据库，导致数据库CPU飙升到90%以上，接口响应时间从20毫秒恶化到3秒。

当时第一版修复是引入分布式锁，让只有一个线程去重建缓存。上线后击穿问题解决了，但新的问题又冒出来：大促场景下，抢不到锁的请求全部进入等待重试，导致部分请求超时。后来把方案改成逻辑过期，缓存不设置物理过期，而用value里的时间戳判断数据是否过期，过期后立即返回旧值，同时异步更新缓存。这样大多数请求不再阻塞，接口延迟恢复到了30毫秒左右。

这个案例最有价值的体会是：互斥锁适合并发量可控的场景，而像秒杀、大促这样极端流量的场景，逻辑过期明显更合适。很多缓存方案没有绝对优劣，只有阈值不同。

6.4 排查缓存问题的速查清单

最后整理一个我在线上排查缓存问题时常用的速查表：

写到这里，我最大的感受是：缓存技术不是背概念背出来的，而是在一次次事故中沉淀出来的。延迟双删、布隆过滤器、逻辑过期，这些方案本身都不复杂，难的是你在面对具体业务时，能判断出该用哪一味药、药量多少。希望这篇“浅学（二）”能帮你把缓存从“听说过”变成“能上手”，也值得你回头看看自己项目里的缓存代码，多问自己一句：“如果这里缓存失败，会发生什么？”能回答上这个问题，你就已经超过很多只停留在“会用Redis”层面的开发者了。