缓存与数据库一致性：过期数据、脏数据与最终一致实践

1. 缓存一致性问题的核心过期数据和脏数据是两回事1.1 一个最普通的读流程不一致窗口是怎么出现的不管你在哪个公司做后端只要画过缓存架构图大概率都画过这样一条链路请求先查 Redis没命中就回源数据库再把结果写回 Redis下一次读就命中缓存了。这个流程本身没毛病它保证了读多写少场景下绝大部分请求不会打到数据库。关键问题出在更新这一步当数据库里的数据变了Redis 里那份旧副本并不会自己跟着变它会静静地躺在那里继续被当成新鲜的返回给用户。不一致窗口就是从这一刻开始的数据库更新完成的那个瞬间到 Redis 里旧值被清除或刷新成功之前所有的读请求都有可能拿到旧值。窗口的最小长度取决于缓存删除动作的执行速度最大长度则取决于你给缓存设置了多长的过期时间或者干脆没设过期时间。很多刚开始接触缓存的人会觉得解决思路很简单更新数据库的同时把 Redis 删掉不就行了但实际操作时会发现一个很现实的问题——同时这两个字是做不到的。两个操作一定有一个先后顺序先做哪个、后做哪个直接决定了不一致窗口的长度和性质。如果顺序选错了窗口不仅不会缩小甚至会扩大还可能造出比过期数据更难清理的脏数据。后面我会专门把两条经典路径掰开揉碎讲清楚。1.2 过期数据和脏数据处理难度完全不在一个量级先定义好两个关键概念后面所有方案其实都是在跟这两种东西做斗争。过期数据数据库已经是新值缓存还保留着旧值。这种情况通常有 TTL 兜底或者下一次写操作会覆盖它只要时间足够它自己会消失。脏数据某个请求把错误的值写进了缓存比如把回源读到的旧值回填进去了这个值可能会长期驻留在缓存里甚至覆盖掉后来正确写入的新值。这种情况不会自动消失必须显式清理。我见过不少线上事故都属于后者。经典的案例就是先删缓存、再更新数据库在并发场景下翻车一个请求删了缓存后还没写完数据库另一个请求回源读到了旧值并回填到 Redis数据库最终变成新值缓存却永远留着旧值。这类问题已经不是时间窗口能解释的了它是状态污染只能靠补偿机制去清理。理解了这两个概念的区别你再看各种一致性方案就不会觉得它们是在故弄玄虚。所有方案本质上都在做同一个博弈尽量缩小缓存和数据库的不一致窗口同时保证在这个窗口内出现的数据偏差可接受、可补偿、能自动收敛。1.3 为什么最终一致才是这个领域的主流目标每个团队在做技术选型时都面临一个尴尬的现实如果要实现缓存和数据库的强完全一致最简单粗暴的做法是让读请求不读缓存或者让写请求阻塞到所有副本同步完成。但这等于把缓存带来的性能优势全部丢掉那还引入缓存干什么所以业界的主流做法基本不是追求强一致而是追求最终一致并叠加一个业务可接受的误差窗口。我观察到一个很普遍的现象不少开发同学刚接触缓存时执着于不一致就是系统有 bug总觉得凡是出现旧数据就不能接受。实际上绝大多数用户业务场景并没有那么苛刻用户不关心数据在某一瞬间是否完全同步他们真正在意的是数据最终是对的旧数据不会长时间滞留在界面上。这个认知其实很重要。它决定了你不会把大量精力花在追求一个不存在的绝对一致上而是愿意花时间去设计一个可控的有界不一致系统。这也是为什么所有成熟方案的讨论都绕不开 TTL、重试、异步补偿这几个关键词——它们不是附加功能而是达成最终收敛的核心手段。2. 两条经典写入路径的对比先删缓存还是先更数据库2.1 方案A先删除缓存再更新数据库先删缓存这个思路非常符合直觉把缓存里可能存在的旧值清掉下一次读一定会回源数据库只要数据库写成功了新值自然会被回填。这可以避免缓存里同时出现更新中的中间状态理论上听上去很合理。但在并发场景里它会立刻翻车。假设数据库里某个商品价格的初始值是 0现在请求 A 要把价格改成 1于是先删掉了 Redis 里对应的 key。就在这之后、请求 A 还没更新数据库之前请求 B 来读这个商品价格Redis 未命中B 回源数据库读到旧值 0然后 B 把 0 写回 Redis。紧接着 A 才执行数据库更新把价格从 0 改成 1。数据库现在是 1Redis 里却是 B 回填的 0。A 已经执行过删除缓存这一步不会再删第二次了于是这条脏数据就在 Redis 里安家落户直到下次有人主动清理它或者 TTL 到期。回源的时机只要落在缓存已删除、数据库未更新这个缺口里读到的必然是旧值而这个旧值会被当成最新鲜的结果回填到缓存里。生产环境中这种现象不只存在于纸面推演。应用拆成多实例以后请求之间的处理时间各不相同这种交叉很容易发生。尤其当中间隔了微服务调用回源操作的完成时间更不可控。所以方案 A 在单请求下没问题在并发条件下就是一颗定时炸弹。2.2 方案B先更新数据库再删除缓存先更新数据库再删除缓存是当前应用最广泛的主流方案。它的基本逻辑是数据库是唯一事实来源先把新值写进事实源提交成功后再把缓存里的旧值清掉下一次读自然就会回源拿到新值。这个方案的不一致窗口在于数据库更新成功之后、Redis 删除操作生效之前可能有一个读请求正好命中缓存读到旧值。这个窗口通常短到只有一次网络往返的时间在大多数业务场景下几乎感知不到。但方案 B 也有一个致命弱点如果 Redis 删除操作失败了怎么办比如网络瞬时超时、缓存服务重启、连接池打满等等旧值会一直留在 Redis 里不会再有人触发删除动作后续所有读请求都会持续命中旧值。只要没有 TTL这个不一致就是永久性的。所以在这个方案里删除动作的可靠性是整个设计的关键。它不是一次网络调用那么简单而是必须能重试、能补偿、能监控的一条完整链路。两个方案放在一起对比会更清楚方案主要不一致窗口风险特性推荐程度先删缓存再更新数据库缓存删除与DB更新之间的间隙可能被并发读回填旧值容易产生脏数据且难以察觉不推荐作为主方案先更新数据库再删除缓存DB更新完成与缓存删除生效之间的瞬间窗口短但删除失败会导致长时间不一致推荐需配套可靠删除这里还得补充一个很多新手容易忽略的细节这两个方案都没有考虑数据库更新失败的情况。如果数据库没写成功方案 A 缓存被删了下一次读回源还是旧值缓存和数据库其实还是一致的方案 B 缓存是旧值数据库也没变成新值双方也保持旧值的一致。真正要命的只有两种——数据库更新成功但缓存删除失败以及数据库还没更新完成、旧值就已经被回填进了缓存。2.3 为什么不考虑先更新缓存再更新数据库选择策略时经常有新人会问既然最终都会一致那能不能先把 Redis 更新成新值再回头改数据库如果数据库更新成功了两边不都是新值了吗这个思路在逻辑上是错的。因为缓存只是数据库的副本它没有资格当数据的所有者。一旦数据库更新失败缓存已经向用户返回了新值持久层却还是旧值这是全局性的数据灾难。之后的每一次读都是基于错误新值做业务判断影响面完全不可控。就算数据库更新成功了这两步之间也会出现一个很长的不一致窗口比方案 A、B 的窗口都大。更麻烦的是很多业务写入需要依赖数据库的返回值。比如你插入一条记录需要用数据库生成的自增主键去拼缓存 key 或者缓存内容那你根本没有办法在写数据库之前拿到最终结果自然也就无法先把缓存更新成正确的新值。所以先写缓存这条路基本走不通工程上几乎没有正经方案会把它当作主路径最多是在非常特定、边界条件很严格的情况下作为写后更新缓存的优化手段出现。3. 把不一致窗口压缩到毫秒级的组合招延迟双删与重试队列3.1 延迟双删到底在防什么延迟双删是我在不少团队里见过的一类经典方案专门用来对付前面说的并发读回填旧值问题。所谓延迟双删就是执行两次删除操作请求 A 先删除 Redis 缓存。请求 A 更新数据库把值从 0 改成 1。等待一段时间比如 1 秒。请求 A 再次删除 Redis 缓存。第二次删除为什么要延迟因为第一次删除和数据库更新之间有一个缺口在这个缺口里可能已经有并发读请求回源并回填了旧值。给这个缺口留出时间等回填操作完成然后第二次删除正好把这些旧值清掉。如果第二次删除太快旧值可能还没来得及回填删除动作根本起不到清理作用。这个方案的优点是简单直接不需要额外引入中间件在当前请求的线程里就能完成。但它的缺陷也很明显等待时长不好选择。如果延迟太短旧值还没回填就被删了如果延迟太长一个写接口要白白等待一秒甚至更久在高并发场景下性能损失非常大。延迟长短通常需要参考慢查询时间、应用调用链路的平均耗时就慢时间再留一点余量常见取值在 500ms 到 1s 之间但每个系统的最优值都不一样。有一个细节值得注意延迟双删解决的是并发读回填旧值的脏数据问题但它没有办法保证第二次删除一定成功。如果第二次删除也失败了整个方案就会退回到先删缓存再更新数据库的不安全状态只能依赖 TTL 兜底。所以在成熟的架构里延迟双删通常不是孤立存在的它往往跟下面的异步补偿队列一起用。3.2 一个可落地的异步补偿队列设计在真实生产系统中删除 Redis 的操作经常会因为各种各样的原因失败Redis 连接超时、服务端 OOM、网络分区、客户端异常退出等等。你不可能保证每一次 DEL 都成功所以必须把删除失败后怎么办提前设计好。我在几个项目里实践过一套相对可靠的补偿方案把删除操作做成一条消息扔进一个持久化的队列里由专门的消费者去执行删除执行失败的按指数退避策略重试重试达到上限的消息进入告警池。具体流程如下业务更新数据库成功后不直接在代码里删 Redis而是写入一条缓存失效任务记录 key 和失效时间。一个定时任务或者消息队列消费者按照频率读取任务执行 Redis 删除。删除成功就从任务表中移除或标记完成删除失败则重新投递按 1s、5s、30s 的间隔递增重试。超过最大重试次数后任务转入一个异常监控表同时给值班同学发送告警。这套方案的收益很直接业务线程不需要关心 Redis 删没删只负责把该删这个事实记录下来。Redis 短暂抖动不会把业务链路拖垮删除动作的可靠性从一次网络调用提升到消息系统的消费链路任何一个环节出问题都有日志可以回溯。代价则是消息队列本身有延迟。从任务写入到消费者真正拿到任务并发起删除中间隔了少则几十毫秒、多则几百毫秒。这个间隔同样构成了不一致窗口对大多数站内业务来说可以接受但如果你的业务对延迟极其敏感还是要在代码层做一个立即删除失败异步重试的组合。让正常的删除走最快的路径失败场景才退到重试表。3.3 我在一个订单服务上的一次真实调整经历之前我经手过一个订单服务商品列表页的数据走 Redis 缓存更新任务发生在管理后台。后台编辑商品后需要让列表页缓存失效。当时团队上线的就是先更新数据库再删除缓存方案看起来没什么问题。上线后出现了很典型的症状在后台改完商品标题用户打开商品详情页偶尔还是能看到旧标题刷新一两次才变过来。这个现象不是每次都出现频率也不高但足够让人头疼。排查了很久我们发现根因恰好出在异步工作流上。管理后台的编辑操作不是同步更新数据库而是先投递一个更新任务任务在后台执行。数据库实际提交更新的时刻往往比业务代码里触发删除缓存的动作晚了几百毫秒。在这几百毫秒里已经有不少读请求回源数据库读到了旧值并把旧值回填进了 Redis。后来我们把缓存失效动作从业务代码里抽了出来改成走一张本地补偿表数据库事务提交之后写入一条待删除 key的记录定时任务以 500ms 的间隔轮询每条记录最多重试 5 次全部失败就告警。同时给列表缓存设置了一个 10 分钟的 TTL 作为终极兜底。这样一来数据库提交和缓存删除之间的时序错乱问题就自然解决了旧数据滞留的投诉基本消失。4. 把删缓存从业务代码里摘出去基于日志变更的订阅方案4.1 核心思路数据库日志才是真正的事件源在微服务架构里到底是谁改了这张表这个问题经常变得很复杂。用户前端改一次、运维脚本改一次、数据补偿任务再改一次每个数据修改入口都可能绕过业务代码里的缓存删除逻辑。如果你只在业务代码里维护缓存失效那漏删除几乎是必然的。在这种情况下基于数据库变更日志的订阅方案就是更好的解。核心思想是不依赖任何业务代码主动删除缓存而是让一个独立组件订阅数据库的变更日志。数据库发生插入、更新、删除时日志会产生对应事件订阅方拿到事件后解析出表名和主键拼出对应的 Redis key再主动发送删除指令。这套方案落地之后业务代码只需要负责写数据库这一件事。缓存一致性完全交给日志同步链路来处理。不管是谁修改了数据改了多少次只要数据库真实发生了变化日志事件就会产生缓存失效就不会漏。数据持久层成为唯一可信赖的事实来源所有下游副本都是它的跟随者。这也是为什么中大型团队会放弃代码里的显式删除宁愿多养一套日志订阅基础设施。当谁改数据这个问题没有明确答案时日志订阅几乎是唯一可靠的办法。4.2 落地时要注意的几个坑日志订阅看着优雅落地的坑非常多挑几个最容易踩的说消费延迟。从数据库提交到订阅方拿到事件中间隔着日志生成、网络传输、消费解析几个环节通常有几十到几百毫秒的延迟。缓存的不一致窗口会跟着这个延迟走所以它不适合对实时性要求极其严格的功能。重复消费。日志同步经常因为网络抖动或位点回退导致同一条事件被消费两次如果消费方做了删除操作第二次删除没命中 key不影响正确性但如果消费逻辑里还改了其他状态就必须做幂等设计。主从切换。主库切到新节点之后日志位点可能会对应不同的记录订阅方如果没能重新对齐进度事件就会丢失。这点需要在架构上特别注意。不是所有表都适合订阅。有的业务表变更极其频繁比如埋点日志、操作流水如果它们也被当成缓存失效源消费速度会跟不上生成速度反而把 Redis 连接和内网带宽打满。这里得控制好订阅范围只订阅确实需要缓存失效的核心业务表其他表一律过滤掉。4.3 这套方案的边界在哪里日志订阅方案最适合读多写少、数据条目多、缓存命中率要求高的场景比如商品详情、用户资料、配置项查询。这类数据更新频率不高但每次更新都必须让下游尽快感知日志订阅把感知动作从代码中移除稳定性和覆盖率都很理想。它不擅长库存这类热点数据的实时同步。库存的更新频率极高日志事件每秒可能成千上万条消费速度跟不上缓存被删了又立刻被下一轮读请求回填反而出现缓存抖动。对这类场景直接在业务代码里做更新数据库后主动删缓存反而更可控。所以判断要不要上日志订阅可以先问自己一个问题这张表的修改者究竟有哪些如果答案只有一个明确的服务正常方案就够用如果答案是很多服务、脚本、运维都可能改那日志订阅几乎是唯一靠谱的选择。5. 多节点、多级缓存下的放大挑战5.1 Redis 集群里删一个 Key 没那么简单很多一致性方案分析默认系统只有一个 Redis 实例、一个键空间真实生产完全不是这样。Redis Cluster 环境下key 会根据槽位分布到不同节点删除某个 key 必须路由到正确的数据分片。如果客户端分片逻辑跟缓存 key 规则不一致或者代理层把请求路由到了错误的节点删除命令就会漏掉真正的旧值节点。集群模式下还经常出现部分节点成功、部分节点失败的情况。比如节点正在做主从切换或者重新分片DEL 命令可能在某个节点上被丢弃网络分区导致删除命令没有到达所有副本。这种局部失败很隐蔽因为从客户端接口返回值看删除命令总体是成功的。我的建议是在多节点环境下给缓存删除统一配上确认加补偿机制。删除前确认 key 在哪个节点删除后检查返回值失败项进入重试队列并纳入监控。缓存已经分散到多台机器上任何单点删除的我已经发出去都不能被当作已完成。5.2 本地缓存进程内缓存其实是另一个坑有些应用为了追求极致性能会在业务进程里再放一层本地缓存查询时先查本地再查 Redis。引入这一层之后一致性问题的复杂程度立刻上升一个数量级。本地缓存没有中心化管理应用 A 删除的是它自己进程里的 key应用 B 进程里的本地缓存可能还残留旧值。如果通过消息广播去通知所有节点清缓存广播量跟节点数成正比节点一多性能就会崩溃。不少团队试过这种方式最后基本都放弃了。我在实际系统里见过比较务实的做法本地缓存一律不设置无限期常驻把 TTL 设成几秒到几十秒。就算广播删除没生效本地缓存也会在极短时间内自动过期下一次读写就会回源到 Redis 或数据库。牺牲一部分命中率换来最坏情况下的最终一致性在多实例部署中非常划算。5.3 多级缓存整体的一致窗口是叠加的更扎心的现实是如果系统同时存在本地缓存 Redis 数据库查询结果缓存处理一致性不能只看一层。每一层都有自己的回源时间和过期机制如果上游服务返回结果时又套了一层自己的缓存全链路的不一致窗口就是每一层窗口的叠加。举个例子。服务 A 从库里取数据后缓存到 Redis服务 B 调用 A 时又把结果缓存了一份服务 C 再调 B 时又缓存了一次。这种情况下即使每一层都严格执行更新后删除缓存全链路的不一致窗口依然是每层窗口的总和并且很难精确估算边界。做多级缓存的关键原则是每一层都要有短 TTL 兜底并且明确每一层的更新线路不能指望一条链路全部同步到最新值。我自己的习惯是越靠用户侧的缓存TTL 设得越短因为用户直接感知旧数据越靠数据库侧的缓存TTL 可以适当放长一些因为它的数据准确性会影响下游所有层但回源成本也高。6. 工程上的务实取舍一致性等级与兜底 TTL6.1 强一致需求本来就不该交给缓存层很多技术和面试里都会质疑一个问题怎么保证 Redis 和数据库强一致其实这个问题的前提就有问题。强一致意味着任意时刻读取到的值必须是最新的那读取路径上就不能存在任何带延迟的副本。直接查数据库主库才是最简单可靠的方案。如果业务确实需要强一致正确做法是不要把缓存当作数据语义的一部分只能把它当成可选的性能加速器。更新时加锁读取时也配合版本号机制保证读取到的缓存副本一定来自当前版本。这已经不是保证缓存与数据库一致的范畴了而是在设计一个分布式事务协议成本和复杂度都非常高。所以在做架构选型时我第一步永远是确认业务到底接不接受最终一致。大部分查询类业务是接受的不能接受的是长时间不一致少部分强约束业务才需要硬性强一致而这些场景通常不应该依赖普通缓存返回业务数据要么走专门的强一致存储要么直接读主库。6.2 TTL 不是偷懒是收敛兜底很多团队给 Redis 设置 TTL 时有个根深蒂固的误区担心 TTL 太短会拉低命中率于是干脆不设置 TTL让 key 永久存活。如果删除动作一直可靠这样确实能保证高命中率。问题在于删除动作根本不可能做到百分之百可靠。一次网络抖动、一个代码 bug、一次运维失误都可能导致一次删除悄悄失败。这种场景下TTL 是唯一不需要人工介入的兜底机制。哪怕前面提到的补偿队列、消息订阅全部失效只要 key 带了 TTL它最终会过期读请求就会重新回源数据库拿到最新值实现最终收敛。站在这个角度看TTL 不是可有可无的锦上添花而是整个一致性体系的最后一道防线。我设置 TTL 时有个简单原则TTL 的时长应该等于业务能容忍的最大不一致时长而不是希望缓存多存一会儿。比如商品价格可以接受 1 分钟内的显示偏差TTL 就设 1 到 2 分钟用户昵称可以接受更久就设 5 到 10 分钟。这样哪怕真出现了删除失败旧数据最多保留 TTL 这么长不会变成永久污点。6.3 我做方案取舍时的几个判断准则总结了多年实战经验我遇到缓存与数据库一致性问题时会按下面这套思路问下去读写比例是多少如果读多写少缓存收益很大值得投入方案成本如果写多读少缓存的收益本来就有限一致性成本反而会拖累整体性能。业务能容忍的不一致时间是多少几毫秒、几秒、还是几分钟容忍度越低方案越重成本越高。明确容忍度可以帮你快速排除掉绝大多数过度设计。谁在改数据源如果只有一个明确服务能改业务代码里主动删缓存就够了如果存在多个入口脚本、补偿任务、后台都可能改那就要上日志订阅或者集中补偿。删除失败后会发生什么有没有兜底 TTL有没有监控告警如果都没有无论你选哪种方案都可能在下一次缓存服务抖动时埋下雷。这套判断标准覆盖了我在大多数项目里遇到的核心问题。技术方案没有唯一正确答案只有在特定约束下最合适的选择。7. 最后聊聊实战体会写了这么多技术路径最后分享几点一线实操下来的体会。不追求面面俱到但都是踩坑之后沉淀下来的。第一不要把重担全压在删除这一条路径上。删除命令再可靠也只是整条链路里的一环更好的做法是给系统多留几个兜底TTL 兜底、补偿表兜底、监控告警兜底。删除失败不可怕可怕的是删失败了没人知道也没有自动恢复机制。第二日志订阅方案虽然优雅但引入成本不低运维复杂度也不小。如果团队规模不大、数据量也就一般先用先更新数据库加可靠删除加短 TTL足够撑住绝大多数场景。等到真出现了数据源被多个入口修改这种信号再考虑日志订阅别为了追求最前沿的方案做过度设计。第三一致性问题是排查难度极高的脏活你看到的偶尔旧数据往往不是简单的时序错误而是缓存、数据库、异步任务、多实例同时作用的结果。排查这类问题时最好给每次删除操作加上日志和 trace 关联把数据库变更时刻、缓存删除时刻、读请求回源时刻完整串成时间线。只要能把时间线拉出来定位是哪个环节慢了一步就很快了。最后始终记住这句话数据库是事实源缓存是加速器两者之间天然存在时间差。我们做的所有方案都是在有限成本内把这个时间差压缩到业务可接受并且保证它最终收敛。脑子想清楚这一点再复杂的问题都能拆成一个个普通的小决策。