缓存这个事，但凡做过后端的人，几乎没人敢说自己没踩过坑。尤其是“旁路缓存模式（Cache-Aside Pattern）如何保证一致性的问题”，这标题既是面试官手里百问不厌的经典题，也是线上事故复盘里反复出现的“背锅侠”。我见过不少团队，Redis 性能指标漂亮得不行，结果数据库里改了一条数据，前端页面却要等缓存过期才更新，用户直接开骂。
这篇文章我不打算给你念教科书，而是把 Cache-Aside 这套东西从原理到实践彻底拆开：它到底怎么工作、一致性窗口从哪来、生产环境里用什么手段把窗口压到最小、踩过的坑长什么样。适合正在做缓存设计、打算优化缓存一致性方案，或者纯粹想把这套面试题答出深度的人。看完你至少能搞明白一件事——Cache-Aside 不是用来“保证强一致”的，它是用来在性能和一致性之间找一个工程上可接受的平衡点。
1. Cache-Aside 到底是什么，为什么它能成为主流
先说个最容易被忽略的事实：Cache-Aside 不是什么高深理论，它就是一套读写缓存的固定姿势。以 Redis + MySQL 为例，这套姿势可以总结成四条操作规则：
- 读请求：先查缓存，命中就直接返回；没命中就去查数据库，把结果回填到缓存，再返回给调用方。
- 写请求：先更新数据库，然后删除缓存。
- 缓存里的数据如果没有被删除，就始终保持“最近一次读请求写入的值”。
- 缓存必须设置过期时间，作为兜底，防止某条数据因为异常情况一直驻留在缓存里。
很多人会问，就这？对，就这。但千万别小看这套朴素流程，它能在这么多缓存模式里杀出重围，靠的是两个核心优势。
第一个优势是“懒加载”带来的成本节省。缓存里没有的数据，不管是真没有还是被删掉了,反正只有发生读请求时才会写回去。这意味着热门数据自然会被保留，冷门数据不会白白占用内存。相比之下，写操作同步更新缓存的模式，每写一次就要多一次写缓存的开销，如果某个 key 写入频繁但读得少，那纯粹是在浪费资源。
第二个优势是删除缓存天然避开了“并发覆盖顺序不一致”的问题。你想想，如果两个线程同时写同一个 key，线程 A 先把数据库更新成 value1，线程 B 又把数据库更新成 value2，此时缓存里如果也走更新操作，最后的缓存值取决于两个线程谁后执行，而数据库的值取决于谁后提交，这两个“后”不一定一致，缓存就很容易和数据库对不上。删除缓存就没有这个烦恼，反正下次读的时候会重新回填。
1.1 先搞清读写流程，再谈一致性
把读写流程落成更细的步骤，你会看得更清楚。读请求的伪代码大概是这样的：
value = cache.get(key) if value == null: lock.lock() try: // 双重检查，防止并发穿透 value = cache.get(key) if value == null: value = db.query(key) cache.set(key, value, ttl) finally: lock.unlock() return value写请求的伪代码则简单得有点“不真实”：
db.update(key, newValue) cache.delete(key)这个不对称的设计——读的时候费劲回填，写的时候一删了之——恰恰是整个模式的灵魂。读请求承担了“数据预热”的任务，写请求则负责把可能过期的旧数据“作废”，让下一次读请求重新从数据库拉最新值。对称性被打破，换来的是逻辑简单、并发安全边界清晰。
1.2 写操作为什么不更新缓存，偏要删除缓存
我面试别人的时候，特别喜欢追问这个问题。很多人能背出结论，但说不出背后的判断依据。更新缓存还是删除缓存，看起来只是一字之差，实际上是对“写放大”和“并发一致性”的取舍。
如果你选择更新缓存，那么问题来了：每次写数据库都要额外更新一次缓存，哪怕这个 key 根本没人读。一个写多读少的场景，比如订单状态频繁流转但用户很少刷新订单详情页，更新缓存就是在做无用功。而且，更新缓存需要额外考虑缓存值怎么构造。数据库里存的是结构化数据，缓存里可能是经过序列化、加工过的视图，你更新数据库字段后，还得重新组装缓存值，繁琐且容易漏字段。
更要命的是并发覆盖。刚才说过的场景再展开一点：线程 A 和线程 B 同时写同一个 key，数据库层面最终状态是后提交者的值，但缓存更新操作可能因为网络抖动、线程调度原因先更新了 value2 再更新 value1，最后缓存留下旧值。删除缓存则完全规避了这个问题——不写入新值就不会有顺序错乱，删除操作本身是幂等的，删多少次结果都一样。
1.3 先丑话说在前面：Cache-Aside 只能做到最终一致
这个认知必须拔高到第一优先级：Cache-Aside 模式在分布式、高并发场景下，不能保证强一致，只能做到最终一致。所谓最终一致，就是说在一段时间窗口内，读请求可能读到旧数据（比如刚更新完数据库还没删缓存的那几十毫秒），但经过删除、过期、重试等机制后，缓存最终会收敛到最新值。
如果你的业务是账户余额、库存扣减这种“一毫秒都不能出错”的场景，那根本不应该让缓存承担读服务，或者需要设计更复杂的版本校验机制。Cache-Aside 适合的是读多写少、对短暂延迟不敏感的业务，比如商品详情、用户资料、文章内容这类信息，用户晚几十毫秒看到更新，完全无感。但你要是拿它做库存扣减的实时计数，那是用错了工具，不是模式的问题。
2. 一致性问题的根源：两个存储之间的“时间差”
所有缓存一致性问题，归根结底一句话：数据库和缓存是两个独立的存储系统，它们之间没有事务，无法做到原子性更新。你在一个事务里更新了数据库，但这个事务不会自动帮你删缓存，哪怕是同一个事务里的两步操作，也可能因为进程崩溃、网络超时而只成功一半。这个“一半”就是问题所在。
可以拿记手账来打比方。数据库是正式的账本，每一笔都记得清清楚楚；缓存是一张小便签，用来快速查看常用数字。你更新账本很及时，但便签上的旧数字没来得及擦掉或擦失败了，别人来看账本数字是对的，看便签数字就是错的。Cache-Aside 的一切设计，都是在围绕“如何靠谱地把便签上的旧数字擦掉”这回事做文章。
2.1 缓存和数据库为什么没法做到“原子同步”
理想状态下，我们当然想用一个“缓存更新事务”把数据库更新和缓存删除包在一起，要么都成功要么都失败。但现实是，MySQL 和 Redis 是两台完全独立的服务，跨系统的分布式事务成本极高。市面上不是没有 XA 分布式事务、TCC 这类方案，但为了一个缓存操作引入分布式事务，整个系统的复杂度和性能损耗会翻好几倍，收益完全不成正比。
退一步说，就算你能把两个操作包在同一个本地事务里（比如先删缓存再更新数据库，事务失败回滚也不影响缓存），也解决不了跨服务的网络问题。事务提交成功和删除缓存成功之间，隔着一次网络 RPC，网络随时可能超时、断开，你怎么也保证不了它们“同时”发生。这就是分布式系统的宿命——不存在完美的原子性，只能追求快速的最终一致。
2.2 “先删缓存再更新 DB”的姿势错在哪
网上很多文章会提到两种顺序的对比，我直接说结论：先删缓存再更新数据库，是坑更多的那一种。为什么？因为删缓存和更新数据库之间，存在一个明显的空窗期。
假设缓存原本有旧值，线程 A 先删除缓存，然后开始更新数据库。在数据库还没更新完成的这段时间里，线程 B 读取同一个 key，发现缓存为空，只能去查数据库——但它查到的是还没被 A 更新的旧值，于是把这个旧值回填进缓存。等 A 的数据库更新完成，缓存里躺着的已经是 B 写入的旧值了，而且不会被自动删除，只能等过期时间熬过去。
更极端的情况是，如果 A 更新数据库失败，缓存已经被删掉了，下一次读只能打数据库，影响有限；但如果 A 更新成功而 B 在 A 更新之前回填了旧值，一致性窗口就不是几十毫秒，而是“缓存剩余过期时间”这么长。这种事故我在线上见过不止一次，最后都是靠人工删 key 才解决的。
2.3 “先更新 DB 再删缓存”为什么也会翻车
既然先删缓存不行，那严格按 Cache-Aside 规范来——先更新 DB，成功后再删缓存。这个顺序确实把主要风险转移了，但它依然有自己的软肋。
软肋一：删除缓存失败。数据库更新成功了，但删缓存时 Redis 刚好超时，或者网络闪断，删除请求没送达。此时缓存里的旧值不会被触碰，只能等 TTL 过期。这是最普遍的一类缓存不一致事故。
软肋二：并发读请求的“迟到写回”。注意这个时序：线程 A 更新数据库，把值从 old 改成 new；线程 B 在 A 更新之前发起读请求，缓存没命中，于是去查询数据库；但 B 的数据库查询走的是隔离级别比较低的事务，或者因为某种延迟，读到的还是 old；线程 A 完成数据库更新后，执行删除缓存，此时 B 的写回操作因为网络慢还没执行完；紧接着 B 把 old 写回缓存。结果是，缓存删除操作已经生效，但随后又被一个迟到的旧值写回覆盖了。这种情况发生的概率不高，但确实存在，越是在高并发、长时间查询的场景下越可能冒出来。
理解了这两个软肋，你就知道后文所有工程手段都是在补这两个洞：一个洞是“删除动作本身不可靠”，另一个洞是“并发读可能覆盖删除结果”。
3. 生产环境怎么把一致性窗口压到最小
说完了理论和坑，来看实操。生产环境里没有人能追求“零窗口”，我们做的是把窗口压到足够小，同时准备好兜底手段，让偶发的不一致能自动恢复、快速恢复。
3.1 顺序、TTL、和 key 设计这几个基本功先做到位
第一件事，顺序必须是“先更新 DB，后删除缓存”。这条规则应该写进团队的开发规范，并且通过代码 review 和监控工具来约束。任何反着写的代码，一旦上线就是定时炸弹。我知道有大厂内部做过统计，Cache-Aside 相关的事故里，约八成是顺序写反导致的，剩下两成才是删除失败。
第二件事，给每个缓存 key 设置合理的过期时间。这里的“合理”指的是和业务容忍度匹配。比如商品基础信息，可以设 30 分钟；用户个人信息，设 5 分钟；想做到秒级感知更新的数据，可以考虑 30 秒或者干脆不缓存。TTL 是兜底中的兜底，哪怕删除失败、重试失败，TTL 一到，缓存自动失效，至少能保证最终一致。
第三件事，key 的设计要带上业务版本号或特征码。举个例子，你缓存一个商品详情，key 里最好包含商品状态、价格版本等信息，或者至少用 key 的命名规范约定好。这样当某个字段更新后，你可以精确地删除对应的整体缓存，而不是删一个笼统的 key 导致其它字段也被误删，白白造成缓存穿透。
3.2 删除失败怎么办：重试、消息队列、本地消息表一套组合拳
删除失败不能靠运维手动删 key，一定要自动化兜底。我见过最朴素的方案是定时任务扫描对比，定期从数据库抽取数据，和缓存里的值做 diff，发现不一致就删除缓存或者直接更新。这个方案思路简单，但两边的数据量一大，扫描成本高，而且发现问题的周期长，不适合对时效有要求的场景。
更好的方案是引入消息队列做异步重试。具体来说：业务代码在更新数据库之后，把“需要删除缓存的 key”发一条消息到 MQ；有个独立的消费者去执行删除缓存，如果删除失败，MQ 本身的重试机制会重新投递，直到成功。这个方案的优点是把删除操作从业务主链路里剥离出来，主链路不需要关心 Redis 是否可用。
不过，直接在主流程里发 MQ 消息也是有讲究的。一种更稳的做法是“本地消息表”：在同一个数据库事务里，既更新业务数据，又往一张消息表里插入一条“待删除缓存”记录。事务提交后，由后台任务扫描这张表，把记录发到 MQ 或者直接执行删除，执行成功后把记录标记为完成。这样做的好处是，数据库事务和消息投递之间有了原子性保障——业务数据提交成功，消息记录一定存在；反之业务数据没提交，消息也不会发出去。
下面做一个对比表，方便你选型：
| 方案 | 原子性保障 | 实时性 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 先更新DB再删缓存 | 无，依赖网络 | 高 | 低 | 对一致性要求一般的默认方案 |
| 定时任务扫描对比 | 无 | 低，分钟级 | 中 | 非核心数据、批量修复 |
| 主流程发MQ异步删 | 业务DB提交和MQ投递之间无原子性 | 高 | 中 | 大多数生产场景够用 |
| 本地消息表+后台任务 | 业务DB提交与消息记录同事务 | 中，秒级 | 高 | 对一致性要求较高、需要可靠删除的场景 |
| binlog订阅异步删 | 依赖binlog，天然可靠 | 高 | 高 | 大型系统、不愿侵入业务代码的场景 |
我个人的经验是：如果你所在的团队规模不大，先不要一上来就搞本地消息表或者 binlog 订阅，复杂度会拖垮你。先保证顺序正确、做好重试和监控，大部分问题就能被挡住；等业务量真的上去了，再逐步演进到更重的方案。
3.3 延迟双删的真实效果与使用边界
很多文章会提到“延迟双删”，我这里也专门评价一下。具体做法是：先删缓存，再更新数据库，然后休眠几百毫秒到一秒，再次删除缓存。这个方案的动机，就是之前说的“迟到写回”问题——第一次删除把旧值清掉，第二次删除把并发读请求写回的旧值再清一遍。
听起来很美好，但实操里有两个硬伤。第一个硬伤是休眠时间怎么定。延迟时间必须大于“并发读请求把旧值写回缓存的最长时间”，但这个时间受网络、线程调度、数据库慢查询影响，波动很大。你设 500ms，可能大部分场景够用，但遇到某个慢查询要 2 秒，照样翻车。第二个硬伤是第二次删除依然可能失败，还是需要重试机制。换句话说，延迟双删不能替代重试，只是在重试之外多了一层概率性的补偿。
我的观点是：延迟双删适合那种“并发读老数据写回概率较高、但集群规模不大、方便简单实现”的场景，但不要把它当作银弹。更靠谱的路径是拥抱异步化：把缓存删除这个动作，从同步调用变成事件驱动，配合可靠投递和重试，最终一致性会有更好的保障。
4. 高并发场景下的缓存一致性治理
聊完了基础的读写流程和删除兜底，再往深走一步。在高并发场景下，缓存一致性问题会变得格外刺眼，因为并发量越大，读请求写回缓存、删除失败、数据覆盖的概率就越高。这一节我们把几个常见的高并发问题串起来看。
4.1 缓存击穿、穿透、雪崩和一致性有什么关系
几个概念先理清楚。缓存击穿：某个热点 key 在过期瞬间，大量请求同时打到数据库；缓存穿透：查询一个一定不存在的数据，缓存永远不可能命中，大量请求直接打到数据库；缓存雪崩：大量 key 在同一时间点过期，数据库瞬间被压垮。
这三个问题表面上是性能和可用性问题，但它们会加剧一致性问题。举个例子，热点 key 过期后发生击穿，大量线程同时查询数据库，如果其中有线程查到了旧版本数据并回填缓存，而数据库此时已经被另一个线程更新过，旧值就会重新污染缓存。同样的，雪崩导致大量缓存同时失效时，回填操作并发度极高，出现“旧值写回、新值被覆盖”的概率也会明显上升。
所以要治理一致性，不能只盯着删除逻辑，还要同时治理击穿、穿透和雪崩。这就像是你想保持房间干净，光会扔垃圾不够，还得防止垃圾桶被踢翻。
4.2 回填缓存时的锁控制
针对缓存击穿，最常用的方案是互斥锁。核心逻辑是：当缓存 miss 时，不是所有线程都冲去查数据库，而是先获取锁，只有拿到锁的线程能查数据库并回填缓存，其余线程要么自旋等待，要么直接降级返回旧值。这就是我在第一节伪代码里写的双重检查锁。
在实际代码里，锁的粒度很重要。你应该用“业务 key”作为加锁维度，而不是一把全局锁锁住所有缓存操作。否则一个热点 key 过期，所有其他 key 的读写都被堵住，代价太高。另外锁一定要设置超时时间，防止某个线程在查询数据库时异常卡住，导致其他线程一直等待。
回填缓存时还有一个容易被忽视的细节：缓存值要尽量和数据库查询的完整结果保持一致。不要在一个事务还没提交时就去回填缓存，更不要把一个半成品的数据结构塞进缓存，不然你删掉的旧值被新值替换后，新值本身可能是不完整的。
4.3 通过 binlog 异步同步，彻底解耦一致性操作
如果你不想在业务代码里写“删除缓存”的逻辑，或者系统有多个上游同时写数据库、不好统一拦截，那可以采用 binlog 订阅的方式。思路是部署一个类似 Canal 的组件，伪装成 MySQL 的从库，监听 binlog 变更事件，解析出哪个表、哪个主键发生了更新，然后异步触发缓存删除。
这样一来，业务代码彻底和缓存操作解耦了。你只管更新数据库，缓存的一致性由旁路的 binlog 消费者负责。而且 binlog 是 MySQL 主从复制的基础能力，解析它是比较可靠的，不容易丢事件。这个方案的代价是要额外维护一套中间件，而且缓存删除会有一定的延迟，通常在秒级以内，适合对实时性要求不是极致、但非常在意代码侵入性的团队。
我在实际项目里采用过 binlog 方案，配合 MQ 重试和 TTL 兜底，线上缓存一致性的监控指标非常干净。但我也要提醒，这个方案部署和运维成本都不低，如果团队没有专门的人维护 Canal 或者类似的组件，慎用。
5. 常见问题速查、排查技巧与几条红线
最后这部分，我把线上最常见的故障和面试里最容易被追问的问题整理出来，权当一份速查表。
5.1 线上缓存与数据库不一致的排查步骤
假如你接到告警，说某个页面显示的数据和数据库不一致，你会怎么排查？千万不要直接去摸 Redis 和 MySQL 的值，那样效率太低。我建议按下面这个顺序来：
- 先确认缓存 key 的 TTL 还剩多久。如果马上就要过期了，那大概率是删除失败或未删除成功，等过期后自动恢复即可。
- 看这个 key 对应的写链路代码，确认操作顺序是“先更新 DB 后删缓存”，还是写反了。写反了就要立即改代码。
- 查 Redis 的慢日志和删除操作的返回结果。如果删除操作超时、返回异常，那就要检查网络和 Redis 负载。
- 看消息队列或本地消息表里，是否有积压的“删除缓存”任务没消费掉。
- 如果以上都没有问题，那要考虑“迟到写回”场景——是不是某个读请求查到了旧值，并且在删除完成后写回了缓存。这种情况通常要靠延迟双删或者版本号机制来解决。
排查的核心思路是：先看 TTL 能不能兜底，再看删除动作有没有成功，最后才怀疑并发时序。
5.2 面试高频追问：Cache-Aside 能保证强一致吗
这个问题我在面试里问过很多次，也看候选人翻车过很多次。标准回答思路分三层：第一层，明确回答“不能保证强一致，只能保证最终一致”。第二层，解释为什么——数据库和缓存是独立系统，删除操作无法和更新数据库构成原子事务，网络、并发都会破坏一致性。第三层，也是最能拉开差距的，是展开讲你会如何把不一致窗口压到最小：先更新 DB 后删缓存、TLL 兜底、删除失败重试、并发回填时加锁、必要时 binlog 异步同步。
有些人会脱口而出“可以用分布式锁保证强一致”，我建议不要这么说。分布式锁也只能缩小窗口，锁的持有时间、网络分区、锁过期，任何一个环节都能让你前功尽弃。真正的强一致场景不应该依赖缓存，这个问题回答得越诚实，越容易获得认可。
5.3 使用 Cache-Aside 必须记住的几条红线
最后给大家划几条底线，都是我拿线上事故换来的教训：
- 红线一：不要用 Cache-Aside 承接对账、库存、支付余额这类强一致业务。缓存只负责加速读，不负责当事实来源。
- 红线二：写操作顺序绝不能写成“先删缓存，后更新 DB”，除非你有延迟双删等补偿措施且经过了严格的并发演练。
- 红线三：所有缓存 key 必须设置过期时间。不设置 TTL 的缓存，一旦删除失败，就是永久脏数据，只能人工干预。
- 红线四：删除缓存失败不能静默吞掉。哪怕只是打一条 error 日志、接一个告警，也比无声失败好。
- 红线五：缓存回填和数据库事务之间不要有偏差。事务未提交就回填、事务回滚后仍保留缓存值，都属于低级错误，但线上非常常见。
老实说，Cache-Aside 这套模式能流行这么多年，不是因为它完美，而是因为它简单、直观、足够好用。它用“最终一致”换来了大多数读多写少场景下的性能提升，工程上完全划算。我在实际项目中踩过最深的坑，不是这个模式不行，而是团队把简单的事情做得太随意——顺序不统一、没有 TTL、删除失败没重试、并发击穿没防护。等这些问题一个个补齐了，一致性指标体系才算真正立起来。希望这篇文章能帮你少走一段弯路，哪怕只是避开其中一个坑，也算值得了。
