做后端开发这些年线上最让我头皮发麻的问题往往不是数据库慢查询也不是接口高延迟而是“数据看起来怪怪的”——用户买A商品详情页显示的价格却是两个小时的旧值。你把数据库翻了个底朝天全是正确的Redis里一查旧值还静静躺在那里。Redis缓存和MySQL数据一致性这四个词基本是后端工程师绕不过去的坎。这篇文章不打算翻来覆去复述官网文档里的概念我想结合自己实际项目里踩过的坑从一个真实电商场景出发把不一致是怎么产生的、有哪些主流修复方案、哪些细节最容易被忽略一件件拆开讲。适合正在用Redis做缓存、但还没系统性梳理过一致性问题的开发者也适合需要排查线上缓存事故的读者。1. 追根溯源为什么缓存和数据库天生就会不一致1.1 同一个数据两处存放天然不是原子操作先从最底层的原因说。缓存系统能带来性能提升本质是“把一份数据复制到更快的存储上让高频读请求不落库”。但复制的同时也产生了最致命的副作用同一份数据现在存在两个地方。更新的时候我们希望数据库写成功、缓存也跟着变可数据库更新和缓存更新是两个独立操作没有任何数据库或缓存中间件能站在两边同时提交一个分布式事务。除非你自己做二阶段提交那套复杂方案否则Redis和MySQL之间没有事务联动能力。于是只要有两个以上线程交错执行读和写的顺序就会被打乱系统就有可能在某一时刻让“读者看到旧缓存”或者“缓存被旧数据覆盖”。这个问题的本质其实很像一个脑筋急转弯一份数据有两个形态所有并发操作都在两个形态之间切换每个操作生效的先后顺序稍有不同最终看到的形态就不一样。这就是所谓的一致性窗口。1.2 强一致不现实我们追求的是最终一致很多刚接触缓存的同学会有一种执念能不能让缓存和数据库永远一致我的回答很直接在高性能分布式系统里做不到也不建议做。如果每次读取都必须在数据库和缓存之间做强一致校验Redis最核心的“命中即返回”优势就没了退化成了一个带网络开销的查询转发器。所以行业普遍做法是追求最终一致——允许在一段短暂的时间窗口内出现不一致但最终必须收敛到最新值。因此后面所有一致性方案的核心工作不是“消灭不一致窗口”而是“把窗口缩到尽可能小并且保证窗口不可能被无限制拉长”。1.3 不一致的三种典型形态从线上实际表现来看缓存与数据库不一致基本可以归为三类缓存有新值数据库还是旧值。这种情况多见于“先更新缓存、再更新数据库”的写法和一些定时任务刷缓存导致的错序。缓存是旧值数据库已经更新。这是最常见的一类比如并发读把旧数据回写缓存、删除缓存失败、主从延迟导致的回源读到旧值等。缓存和数据库都有值但不属于同一条数据版本。这类是Key映射错乱、序列化错误导致的“脏读”属于另一类规范问题。能理解这三类形态后面看解决方案就不会雾里看花。你去看网上那些“缓存一致性神器”仔细拆开本质上都是在尽力消除第二种和第三种。2. 一次商品详情页事故并发场景下不一致是怎么发生的2.1 业务背景我早先做过一个电商项目有个非常典型的线上反馈运营在后台把商品价格从100元改成80元自己刷新商品详情页很快就看到了新价格但部分用户看到的价格还是100元刷新两三次之后又变回80元过一会儿又回跳。这种现象持续几分钟后会自己消失但客服已经被问得焦头烂额。商品详情页的典型读取流程是这样的请求进来先查Redis命中直接返回未命中则查询MySQL把结果写回Redis设置过期时间下次请求直接命中缓存。当时更新价格的流程写得很简单先更新MySQL里的价格字段再更新Redis缓存如果Redis更新失败打一条日志然后不管了。2.2 问题定位的过程第一次排查时我盯着数据库日志看了好几个小时确认MySQL里所有记录都是最新的没有任何问题。缓存的过期时间当时设的是10分钟也就是说如果缓存写入了一个旧值最长10分钟后才能被自然过期清掉——这正好解释了用户为什么看到旧价格几分钟后突然“自己恢复”。其实那不是系统自我修复只是缓存过期后下一个请求从DB里拉到了最新值并重建了缓存。继续追查复现事故后发现原因并不复杂问题集中在改价后的头几分钟。我把时序还原给大家看。这里用线程A代表运营改价请求线程B、线程C代表普通用户查询请求时间线程A改价线程B查询线程C查询结果T1修改数据库price80读取缓存未命中T2查询数据库读到旧值100查询数据库读到旧值100T3写回缓存price100缓存被旧值覆盖T4更新Redis缓存price80写回缓存price100缓存最终被更晚的旧写回覆盖这个例子能清楚说明“先更新数据库、再更新缓存”为什么危险如果线程B和线程C查询数据库发生在事务提交之前读到的就是旧值100它们随后写回缓存的动作只要发生在线程A写缓存之后旧值100就会把线程A刚写入的80覆盖掉。最终结果是缓存100、数据库80业务数据长期处于“错乱”状态。2.3 后来我们怎么改的在很多架构文章里都提过一个结论写请求采用“更新DB 删除缓存”读请求采用“未命中则更新缓存”。也就是说缓存不主动更新而是删除让下一次读请求自己去拉取最新数据。这样做的好处非常明显——删除一个Key是无状态的不会因为两个并发删除顺序不同导致旧值残留而更新缓存则可能发生新值被旧值覆盖的问题。这个方案就是标准的Cache Aside旁路缓存模式。它的流程是读先查缓存命中直接返回不命中则查询DB把结果回写缓存并设置TTL。写先更新DB成功后删除缓存让缓存失效。这是最简单、也最普适的一致性基线方案。后面的延迟双删、消息队列、Canal订阅等本质上都是在这个基线方案上打补丁。提示我把“更新缓存”彻底改成“删除缓存”是排查完这次线上问题后做的第一个决定。如果你的代码里还保留着“更新缓存”这个动作在并发场景下出现不一致是迟早的事。3. 一致性方案的家族谱Cache Aside、延迟双删、MQ与Canal3.1 Cache Aside是最底线但要用对Cache Aside看起来简单实际使用中有几个前置条件容易被忽略删除缓存不能失败。一旦删除失败旧缓存会一直存活到过期时间系统在过期前就处于“长时间不一致”状态。删除操作要放到业务事务提交之后。如果事务还没提交就删除缓存而事务随后回滚缓存就被白白删掉了下一次读请求会穿透到DB白白增加压力。删除缓存要具备重试能力。既可以用本地队列加定时任务也可以把删除失败的Key扔进MQ由消费端再删一次。我给团队定的规矩是缓存删除失败必须被监控到不能只在日志里瞥一眼。日志在高峰期很容易刷屏肉眼根本看不过来。连续多次删除失败就该触发告警因为用户已经开始被旧数据影响晚一分钟处理就多一分钟的口碑损耗。3.2 延迟双删用时间补偿换取更小窗口Cache Aside虽然基础但有一种并发场景依然会出问题删除缓存后一个并发读请求恰好未命中缓存接着去DB读到了旧值因为DB更新还没提交或者主从延迟导致读到旧值然后把这个旧值写回了缓存。等DB更新完成缓存里已经留下旧值需要很长一段时间才能被TTL清掉。为了覆盖这个窗口业界有延迟双删的做法。核心逻辑是更新数据库第一次删除缓存等待一个短暂时间比如500ms第二次删除缓存。第二次删除的目的就是清掉在第一次删除之后、DB更新生效之前被并发读者写回缓存的旧值。这里有三个关键细节等待时间怎么定理论上要大于“从缓存删除到所有可能读到旧值的请求都完成回写”的最长时间。但实际很难精确分布式环境还要考虑主从延迟。延迟双删没法100%保证一致只能尽量压缩窗口。第二次删除同样可能失败所以仍然要配合重试。在高并发场景下延迟双删的sleep会让缓存多一段时间处于“空窗期”数据库请求会短暂增加。QPS很高时要评估这个代价。我给中等规模业务单机数据库、QPS几千左右的建议是Cache Aside是底线延迟双删可以作为加强手段。但别迷信它它省掉了引入MQ和Canal的架构复杂度同时也把一致性收敛建立在“sleep”这种不太精确的手段上。3.3 消息队列异步删除把双写变成串行延迟双删本质是用“sleep”硬等并发窗口过去而消息队列方案是把“缓存删除”这个动作异步化并且天然支持重试。具体实现思路业务代码先更新数据库事务提交后发送一条消息到MQ消息内容包含缓存Key消费者收到消息后执行缓存删除或重建删除失败则重回队列或者记录到失败表由补偿任务定期扫描。这个方案有非常实在的好处第一缓存删除从业务线程里剥离出来主链路更短不会因为Redis抖动把数据库更新也拖垮。第二MQ自带重试机制。Redis偶发故障时消息可以延后重试不用干等TTL到期。第三可以利用MQ的顺序性。对同一个缓存Key的消息指定同一个分区键就能保证它们按发送顺序被消费不会因为并发导致“后更新先删、先更新后删”的乱序。但注意MQ不等于强一致。消息发送和消费都有延迟这期间依然存在不一致窗口。只是它最大的优点是窗口可控、可追踪失败时还有明确的重试路径。这个方案适合缓存更新比较频繁、但删除失败又不可接受的业务。3.4 Canal订阅binlog任何来源的数据库变更都逃不掉在更复杂的系统里更新数据库的入口可能不止业务代码一处。定时任务、管理后台直连、数据订正脚本、其他团队的系统都可能直接改库。只要漏了一条路径就会把缓存更新逻辑漏掉造成长期不一致。这时最通用的做法是把一致性建立在对MySQL binlog的订阅上而不是业务代码上。方案结构大致是MySQL开启binlog推荐使用row格式便于解析变更前后的值Canal伪装成MySQL从库订阅binlog变更事件收到变更后解析出表名、主键、变更前后的值再根据业务规则删除或重建对应的Redis缓存。这样做的好处是极强的解耦数据库里任何一次增删改只要落库就会被捕获不再依赖上层应用是否记得“要删缓存”。尤其是后台订正、批量刷数这几种特别容易漏删缓存的场景用binlog订阅可以一劳永逸。缺点是架构复杂度明显上升Canal服务本身要维护binlog日志量大的时候解析会有延迟主从复制架构下还要考虑位点是否丢失的问题。我在实际项目里一般只针对“核心表”开启这套同步非核心表还是走Cache Aside兜底。3.5 读穿透、写穿透与写背后别被名字迷惑除了上面几种缓存中间件本身也支持一些模式比如Read-Through读穿透、Write-Through写穿透、Write-Behind写背后。它们和前面讲的手动方案有区别Read-Through读未命中时由缓存服务自己从数据库加载业务无感和Cache Aside的读侧很像只是实现位置从业务代码挪到了缓存层。Write-Through写请求先更新缓存缓存同步更新数据库一致性较好但写入路径变长性能有损耗。Write-Behind写请求只更新缓存异步批量写回数据库性能最好但服务突然宕机可能丢数据。从“Redis MySQL双存储”的角度看这些模式通常不是默认开箱可用仍需要自己封装。所以普通业务还是重点关注Cache Aside、延迟双删、MQ和Canal这批方案不要被概念名词迷惑以为名称高级就一定更好。4. 细节才是魔鬼这些坑我几乎都踩过4.1 过期时间不是摆设但不能只靠它很多人设置Redis Key的TTL都非常随缘。实际上过期时间在一致性方案里是最后的兜底条件设置了合理TTL就算主动删除缓存失败数据也最多在TTL时间内不一致时间一到自动消失。不设置TTL一旦删除失败旧值就是“永久驻留”这比任何并发问题都严重。TTL太短也不行热点Key频繁过期会导致大量请求穿透到DB缓存层相当于形同虚设TTL太长不一致窗口又会拉大。我在实践里的做法是核心隔离数据商品价格、库存、订单状态给5到10分钟对不敏感的数据列表页聚合信息、非实时配置给30分钟到数小时。核心数据靠主动更新保证及时性TTL只是保底它的作用是“就算主动更新方案全挂了系统也能在有限时间内自愈”而不是让TTL成为唯一的修复手段。4.2 缓存穿透、击穿、雪崩三个打爆数据库的兄弟这三个词大家应该很熟了但它们和一致性是强关联关系也容易被混为一谈穿透查询一个不存在的Key缓存没有DB也没有。如果不处理每次请求都打DB。处理方式可以缓存空值TTL短一点或者用布隆过滤器在缓存层拦截。击穿一个热点Key过期瞬间大量请求同时穿过缓存查DB。处理方式是用分布式锁或“单飞”机制让同一时刻只有一个请求真正回源其余请求等待或快速失败。雪崩大量Key在同一时间过期瞬时请求全部打到DB。处理方式是给过期时间加随机偏移量避免同一秒集体失效也可以做二级缓存。很多人只把这三兄弟当性能问题处理但在一致性场景里它们同样会放大旧值回写的概率。因为一旦发生穿透回源并发读者极容易在一个不好的时序窗口内把旧值写回缓存。所以修复缓存性能和修复一致性问题本质上是同一个系统设计动作不能割裂看待。4.3 事务与缓存的顺序Spring注解管不了RedisSpring项目里最常见的一个误操作是把缓存删除写在一个被Transactional标记的方法里。伪代码如下Transactional public void updatePrice(Long id, BigDecimal price) { productDao.updatePrice(id, price); redisTemplate.delete(product: id); }这个写法有两个问题如果SQL执行成功、Redis删除成功但事务提交时失败回滚缓存已经被删掉了。缓存缺失导致的直接后果是后续请求全部回源到DB数据库压力瞬间增加。如果事务还没提交Redis已经删除此时一个并发读请求跑到DB读取读到的还是事务未提交前的旧值然后回写缓存。事务提交后缓存里反而留下旧值。正确做法是等事务真正提交之后再做缓存删除。Spring里可以用TransactionSynchronizationManager注册回调在afterCommit里执行删除Transactional public void updatePrice(Long id, BigDecimal price) { productDao.updatePrice(id, price); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { redisTemplate.delete(product: id); } }); }这个细节看着不起眼但我在多个项目里都遇到过事务里的缓存操作和数据库操作没有对齐一上线就出现偶发的“缓存回跳”。建议团队把“所有缓存删除必须afterCommit”直接写进代码评审规范避免新人反复踩坑。4.4 缓存Key设计命名、序列化、大小都影响一致性严格来说缓存Key的命名看起来是“规范问题”但实际会直接影响一致性判断。举例同一个业务数据有人用“product:1:price”有人用“productPrice:1”两套Key并存改价只删了一条Key另一条Key仍然带着旧值。用户页面数据一会新一会旧排查起来让人抓狂。这类问题在多人协作的项目里特别常见。序列化方式混乱有的缓存用JDK序列化有的用Jackson有的是StringRedisTemplate存的字符串。写入时是BigDecimal序列化成字符串后精度可能变化读取时发现价格变成了“100.0”而不是“100.00”前端一看就以为数据错乱。我给的团队规范很简单Key格式统一为“业务域:实体id:字段”比如product:123:price值统一用JSON字符串存储读取时反序列化成专门DTO。这样和Redis Desktop Manager等工具配合时出现问题可以一眼看出缓存内容是什么不用把排查时间浪费在反序列化报错上。4.5 分布式锁不要为了拿锁而拿锁在缓存击穿场景里让回源请求只放一个大家自然而然会想到分布式锁。分布式锁确实能降低并发回源对DB的冲击但用得不对坑也不少锁没设置过期时间业务线程GC卡顿或网络延迟锁迟迟不释放其他线程全部阻塞接口超时。锁过期时间太短业务还没执行完锁就过期了下一个线程又拿到锁两个线程同时回源锁等于白加。释放锁时没有校验唯一性线程A释放锁时把线程B刚获取的锁也给删了。锁粒度放得太大比如给整个商品表加锁所有商品查询全部串行化Redis缓存带来的并发优势被锁抵消。一个稳妥的写法是用Redisson这类成熟库它自带看门狗续期机制和“锁value等于客户端唯一标识”的判断逻辑。如果项目不想引第三方依赖至少也要用“SET key value NX EX 10”这种原子命令设置锁释放锁时用Lua脚本先比较value再删除避免误删别人的锁。4.6 别忽略数据库主从复制的延迟一致性方案里主从复制延迟也会悄悄影响结果。典型场景是业务写主库成功后删除缓存但一个读请求此刻落到了从库从库还没同步到最新数据读到旧值后把旧值写回Redis缓存。这种现象在采用“先删缓存再更新DB”或者读库压力比较大的时候尤为常见。处理上没有完美解但有几个有效思路核心高一致性链路尽量读写都走主库用延迟双删把主从延迟也覆盖进去对极端敏感的数据订单金额、余额直接走DB查询不走缓存。不要为了追求缓存命中率把每一个字段都塞进Redis有些高一致场景本身就适合直连DB。5. 实测后的落地组合按业务规模选方案5.1 中小业务团队人力有限我的建议是别把架构搞得过度复杂读写流程采用标准Cache Aside写库成功后删缓存读未命中再重建。删除缓存设置重试本地维护一个“待删除Key”队列失败后延迟重试重试次数过多就告警。TTL一律要设置核心数据给5分钟非核心数据给1小时。事务内确保afterCommit之后才删除缓存。给热点Key的TTL加随机偏移避免缓存雪崩。这套组合不需要额外引入MQ和Canal一致性窗口控制在秒级左右对绝大多数中小业务足够了。5.2 中大型业务更新频繁且删除失败不能容忍这时候推荐引入MQ异步删除或者采用Canal订阅binlog。二选一的关键问题是是否还存在不少“非业务代码入口”在写核心表如果所有写路径都收口在应用层直接用MQ异步删除就够了链路简单。如果存在后台订正、批量导入、多系统直连等入口更推荐Canal订阅binlog把缓存失效逻辑和写入口完全解耦。无论选哪种都建议保留一个兜底定时任务每10分钟扫一次核心数据表比较DB数据和缓存的内容。这里不建议全表扫描可以维护一张“最近变更ID表”只对比真正变更过的行避免造成额外数据库压力。5.3 高并发加高一致场景版本号机制如果业务到了秒杀、抢购这个量级连“一瞬间看到旧价格”都无法忍受我建议在缓存里增加版本控制。具体做法是每个缓存Key的值自带一个version字段更新数据库时把version自增1每次回写缓存时先比较缓存里的version和DB返回结果携带的version如果缓存version大于等于DB version说明本次回写是旧数据直接丢弃如果缓存version小于DB version说明本次回写是最新数据允许覆盖。这个机制的本质是把“旧值不能覆盖新值”从代码约定变成数据本身的决定性判断。配合分布式锁和MQ重试几乎能覆盖绝大多数并发写回场景。缺点是每次读取要多一个版本判断业务代码复杂度略有提升。5.4 一致性验证与监控怎么做一致性方案上线后必须配合验证手段不能等出事故才后悔。我分享一套实测过的方法并发脚本准备一套测试环境写脚本同时发起多个修改请求和查询请求跑几分钟后抽样对比DB和缓存的最终值检查是否有旧值残留。故障演练通过代理层做故障注入让Redis delete命令随机失败观察系统的重试补偿是否生效。如果删不掉的Key能稳定被第二次重试清掉说明兜底逻辑是可靠的。命中率监控Redis命中率突然下跌往往意味着TTL被大量调短或缓存被误删需要结合应用日志分析。数据库慢日志当缓存频繁失效导致大量回源时数据库慢查询会明显增多这也是发现缓存同步链路故障的信号。版本差异报表如果加了版本号机制可以定期从业务日志抽样输出“缓存version vs DB version”对比报告用数据说话。最后分享一个我感触最深的经验一致性方案永远没有银弹。你可以把业界所有方案都背得滚瓜烂熟但落到具体业务一定要先想清楚三个问题——不一致窗口能接受多长、数据错了后果有多严重、团队有多少精力维护额外组件。想清楚这三个问题再决定是留在Cache Aside还是上MQ、上Canal选择就会顺手很多。如果非要我给出最实际的起步方案我建议任何团队先把Cache Aside做扎实写库后记得删缓存、删除务必重试、TTL别设成永久、事务提交后再删、Key命名统一。把这些细节做到位线上90%的“缓存回跳”问题都会消失。剩下10%的极端高频场景再针对性引入更重的手段也不迟。