Redis缓存与MySQL数据一致性方案全解析

缓存和数据库一致性这个问题做后端的人迟早要面对。尤其是流量稍微上来一点Redis一上问题立刻浮出水面商品详情页缓存里还是旧价格用户已经下单付款了才发现金额不对库存扣减了页面上还显示有货改了用户名好几天之后评论里还是老昵称。这种“缓存里有数据、数据库里也有数据、两边还长得不一样”的局面轻则影响体验重则直接造成资损。这篇东西我不打算讲一堆花架子就围绕“Redis缓存和MySQL怎么保持一致”这个核心问题把业界常用的几种方案掰开揉碎聊一遍。适合谁看正在写业务系统、被缓存不一致问题折磨过的开发同学以及准备面试中间件原理、需要系统梳理一致性方案的朋友。我会讲清楚每种方案的原理、适用场景、能解决什么问题、又埋着什么坑最后分享一些我在实际项目里的取舍习惯。1. 问题到底出在哪缓存和数据库为什么会对不上1.1 同一个数据为什么要有两份先说一个本质问题Redis缓存和MySQL里存的是同一份业务数据的两个副本但它们的更新路径完全不同。MySQL是持久化存储所有写操作落盘事务保证ACID数据是“真身”Redis是内存存储读写快但数据随时可能因为淘汰策略、宕机、过期而消失本质上是“加速副本”。业务代码在读写时经常是先操作了其中一个再同步另一个同步的动作一旦出现时序问题、失败、并发交叉两份副本就对不上了。很多同学一开始会把这个问题想简单写操作同时更新MySQL和Redis不就行了两个都写能出什么问题实际上问题太大了。两个独立的存储系统之间没有事务保障你无法保证“MySQL写成功”和“Redis写成功”这两个动作在时间上是原子的。就算是同一个线程里顺序执行也可能第一步成功、第二步失败更不要说多线程并发时两个线程各自读到了旧值再按照不同的顺序去写Redis缓存里留下的那个值未必是新鲜的那个。1.2 四个典型场景拆解不一致的产生路径与其背理论不如直接看几个真实会发生的事故路径。场景一读回写覆盖新值。线程A读缓存未命中去数据库读到value1的旧数据此时线程B更新数据库把value改成2线程B删除缓存或者更新缓存成功线程A这才慢慢悠悠地把手里那个旧值1写回缓存。缓存里永久留下旧值直到过期。这个场景在缓存未命中的瞬间最危险因为“读DB→写缓存”不是原子的中间夹了一个窗口期。场景二并发更新乱序。两个线程同时修改同一条数据数据库层面有事务、有锁最终落库的值是后提交的那个没问题。但缓存要是也走“更新”逻辑A先写缓存为1B后写缓存为2网络抖动一下或者执行速度差异B可能先写完A反而后写完缓存里的值就变成了先提交的旧值1。数据库和缓存的最终状态恰好相反。场景三先删缓存再写库的窗口。很多同学知道写缓存不如删缓存但采用了“先删缓存、再更新DB”的顺序。问题在于删完缓存后、DB更新完成前的这段时间里任何一个读请求进来都会发现缓存没命中然后去DB把旧值读出来、写回缓存。缓存里就又有了旧值而且因为缓存已经有值了后续读请求全部命中旧值相当于把DB更新后的新值完全“屏蔽”了只能等缓存过期。场景四更新成功但缓存删除失败。数据库已经更新成新值了执行Redis DEL命令时网络超时、Redis重启、淘汰策略把数据提前清了等等总之缓存里的旧值还在。如果没有兜底重试这个旧值能一直活到过期时间。这四个场景基本覆盖了90%线上缓存不一致问题的根源。核心矛盾说白了就一句话两个存储系统各自独立变更中间缺少一个可靠的、有序的、可重试的同步机制。接下来讲的每种一致性方案本质上都是在解决这三个词可靠、有序、可重试。2. 最主流的方案Cache Aside旁路缓存模式2.1 核心思想读走缓存、写走库、失效靠删先讲业界使用率最高的方案Cache Aside模式。这个模式的核心思想是应用层自己管理缓存和数据库的读写读的时候先查缓存命中直接返回未命中则查数据库然后回填缓存。写的时候只更新数据库然后把缓存删掉。读流程读请求 → 查Redis ├── 命中 → 直接返回 └── 未命中 → 查MySQL → 回填Redis → 返回写流程写请求 → 更新MySQL → 删除Redis缓存很多人刚接触这个方案时会问为什么写的时候不直接更新缓存非要删掉删掉之后下次读还要重新查库岂不多一次IO这个问题的答案正好是整个方案的精髓所在我放到下一节专门讲。2.2 为什么写操作要删除缓存而不是更新缓存我见过不少新手同学包括我早年自己刚写缓存时都会下意识选择“更新缓存”逻辑很简单既然数据库更新了那同步把Redis里的值也改掉两边保持一致不是更直接吗但实际写业务代码多了就会发现“更新缓存”这个操作在几乎所有场景下都是坑。第一个问题写多读少的场景下更新缓存是纯浪费。假设一个商品SKU的库存字段大促期间每秒被写十次但用户端每秒可能只读一两次。如果每次写都更新Redis等于做了八九次无用功。而删除缓存的成本极低只有等真正有人读了缓存才重建这是典型的惰性加载思路用的时候才花钱。第二个问题并发更新下缓存顺序无法保证。前面场景二说过了两个线程同时更新DBDB靠事务保证了最终值是正确的那个但Redis的写操作没有版本控制两个线程并发SET谁都可能覆盖谁。缓存里的最终值完全取决于线程执行的先后而执行先后跟提交先后不是一回事。第三个问题更新缓存的计算成本可能很高。缓存里存的经常不是数据库单行记录的原始值而是一个聚合结果比如“用户信息用户最近订单数用户等级”。 如果走更新逻辑每次DB一变你得重新算一遍聚合结果再SET进去而删除缓存下次读的时候自然会把聚合结果重算一次。结论很简单更新缓存的优点是省一次读请求代价是牺牲了正确性和计算资源。而删除缓存等于把所有计算的主动权交还给下一次读请求天然避免了中间态的残留。所以在Cache Aside模式下写操作统一删除缓存这是这套方案最核心的一条原则。提示除非你明确知道某个字段的缓存value与DB record是简单的一一映射、且写并发极低否则不要走“更新缓存”这条路。默认选择删除。2.3 两种执行顺序的坑和延迟双删确定了“写库删缓存”的组合之后下一个问题就是顺序先删缓存再写库还是先写库再删缓存先删缓存再写库问题我在1.2节的场景三里已经讲过。删缓存后、写库前一个读请求进来了未命中缓存于是读旧库、回写旧值缓存里就“复活”了旧数据。这个窗口虽然只在“删缓存→写DB”之间但线上这几十毫秒到几百毫秒的间隔里读请求是随时会进来的概率并不低。先写库再删缓存同样存在问题。这个方案的问题不在窗口而在“删除失败怎么办”。如果DB写成功了Redis的DEL命令却因为网络异常、Redis主从切换等原因失败了缓存里的旧数据就会一直存活。在没有兜底机制的情况下只能等缓存自然过期而如果过期时间设置得很长比如一小时那这一小时内用户看到的都是旧数据。所以成熟团队在实际落地时普遍采用的做法是先写库、再删缓存、失败走重试同时对于极少数超高并发场景再加一个延迟双删的加强手段。延迟双删的核心思路很简单第一次删除放到写库之后立即执行然后等一小段时间比如500毫秒再执行第二次删除。第二次删除的目的就是清掉由于“删除后、写库前”那个窗口期间被读请求回写的旧值。操作步骤 1. 删除Redis缓存第一次删除先清理旧数据 2. 更新MySQL数据库 3. 休眠一小段时间一般是500ms左右按业务耗时调整 4. 再次删除Redis缓存第二次删除清理窗口期脏数据为什么要休眠因为只有等一个“窗口期”结束那些在删除后写库前读到旧值的读请求才会有足够的时间完成“读库→写缓存”的动作。第二次删除的目标正是这些刚刚回写完的旧值。延迟时间设得太短第二次删除跑得比脏数据回写还快删了个寂寞设得太长又白白拉高了写请求的响应时间。延迟双删的问题也很明显第一休眠时间很难精确因为业务系统的“读DB→回写缓存”耗时不是稳定的第二它只能降低概率不能根除极端情况下仍然可能有一小段不一致窗口。所以它只能作为加强手段不能作为全部的救赎。2.4 缓存删除失败后的兜底重试机制与消息补偿前面提到先写库再删缓存最大的隐患是删除失败。一个成熟的系统绝不能把“删除缓存”当成一个fire-and-forget的操作必须给它上保险。我在项目中比较常用的兜底方案是“消息队列异步重删”。核心流程是业务代码在更新完MySQL后发送一个包含缓存key的删除消息到MQ一个独立的消费者专门负责从MQ取消息、执行Redis删除。如果删除失败消费者捕获异常后重新投递到延迟队列每隔一段时间重试一次直到成功或超过最大重试次数。写请求 → 更新MySQL → 事务成功后发送删除消息到MQ MQ消费者 → 收到删除消息 → 执行Redis删除 ├── 成功 → 记录日志结束 └── 失败 → 投递到延迟重试队列 → 继续重试这套方案的好处是删除缓存这个动作从业务主链路里彻底剥离出去了主线程不用自己关心Redis是否删除成功只用保证消息投递成功即可。就算Redis短暂不可用消费者手里的消息也不会丢等Redis恢复后重试即可。当然重试不是万能的还有一层最基础的兜底就是给缓存设置合理的过期时间。不管前面的同步机制怎么失败只要过期时间到了缓存自动消失下一次读请求自然会回源数据库拿到最新数据重新建缓存。这层兜底保证了哪怕整个同步链路全部瘫痪一致性最多也只损坏一个过期周期。实操心得我在实际项目中对核心业务数据比如库存、金额的缓存过期时间设置得比较短一般不超过5分钟对非核心数据比如用户昵称、商品描述可以放宽到30分钟或1小时。这样既保证了缓存命中率又限制了不一致的最长存活时间。3. 其他同步思路Read Through、Write Through 和 Write Behind3.1 Read Through / Write Through让缓存成为唯一入口Cache Aside是应用层自己管理缓存和数据库的关系属于“手动挡”。还有一种思路是给应用层封装一个缓存Proxy应用读写都只跟缓存打交道由缓存组件自己负责和数据库同步。这种方案统称Read Through / Write Through模式。Read Through的意思是当应用读取缓存未命中时缓存组件自己负责从数据库加载数据、回填缓存然后返回给应用。应用只调一次接口不需要像Cache Aside那样自己写“读DB→回填缓存”的逻辑。Write Through的意思是应用写数据时直接写缓存由缓存组件同步把数据写入数据库。如果数据库写入成功缓存和数据库同时更新两者可以保持较强的同步性。这个模式和Cache Aside最大的区别在于一致性控制的逻辑从业务代码里转移到了中间件层。对业务方的友好度很高业务代码里不需要再关心缓存和数据库怎么配合只需要面向缓存编程。但Write Through在实际落地时有一个致命难点如何保证和数据库的一致性。如果先写缓存成功、写数据库失败那缓存里就多了一份数据库不存在的数据要么回滚缓存要么返回失败处理起来都很棘手。而且所有写操作都要同步穿透到数据库写延迟比直接写数据库还要高一截因为中间多了一层缓存转发。所以这个模式更常见于那些本身就构建在特定缓存中间件之上的场景比如某些支持持久化语义的缓存系统。在RedisMySQL这个组合里业务团队自己去实现一套完整的Read Through/Write Through代理成本非常高。3.2 Write Behind异步批量写回的性能代价Write Behind也称作Write Back是另一种思路也是业界在高写入吞吐场景下经常讨论的方案。核心逻辑是写请求只更新缓存然后立即返回成功数据库的写入被延迟到后台异步执行由后台任务把缓存中的变更批量合并后写入MySQL。这个方案的最大优势就是性能。所有的写操作只打内存不落库写入吞吐可以做到极高而且后台批量写库可以把多次重复的写合并成一次减少数据库压力。典型的应用场景是点赞数、浏览量、在线人数这类“计数器型”数据允许一定的误差甚至可以接受宕机丢一点数据。代价也很直接数据的一致性窗口更长缓存和数据库长时间处于不一致状态更危险的是如果缓存数据还没落库就发生宕机或者需要剔除那部分数据就直接丢了。所以Write Behind通常和持久化、告警恢复机制配合使用不能用于金额、库存等强准确数据的场景。3.3 取舍建议不同业务场景该选哪个这三种模式各有应用场景但想在RedisMySQL上做选型我的建议其实比较明确。业务数据对一致性要求高、且属于读多写少场景优先使用Cache Aside手动挡配合延迟双删和MQ重试兜底。这是绝大多数业务系统的默认选择。如果团队有人力和意愿封装统一的缓存代理层且业务方希望弱化缓存操作细节可以考虑Read Through/Write Through。但要做好心理准备这个代理层本身要实现复杂的失败补偿逻辑工程量不小。如果数据允许丢失、写入量大且高频比如各种计数统计可以设计为Write Behind核心库定期做数据核对和补偿。我把几个方案的核心维度整理成了一张对比表方便各位做技术方案评审时直接参考方案一致性强度读性能写性能实现复杂度典型场景Cache Aside先写库再删缓存最终一致依赖重试高命中缓存中删缓存成本低低通用业务后端默认选择Cache Aside 延迟双删最终一致窗口期缩短高中低多一次延迟低超高并发、对短暂不一致敏感Read Through / Write Through较强接近强一致高低需同步穿透高有统一缓存代理层的团队Write Behind弱一致有数据丢失风险高极高中计数统计、埋点、流量削峰4. 架构级方案订阅Binlog实现最终一致4.1 核心思路让数据库当“话事人”前面讲的所有方案都有一个共同特点业务代码里必须显式操作缓存。也就是说每次写完MySQL你还得记得把Redis里对应的key删掉。问题就来了如果哪天代码里漏写了删除操作或者某个老接口改来改去把删除那段给弄丢了缓存不一致的隐患又被种下了。架构级的解决方案是把“和缓存同步”这件事从业务代码里彻底剥离开交给一个独立的同步链路去完成。这种方案的思路可以让数据库自身来当“话事人”——只要数据库数据发生变化就产生一个变更事件然后由这个事件驱动缓存刷新。MySQL的变更事件就是BinlogBinary Log它是MySQL自己生成的二进制日志记录了所有会导致数据变更的操作。我们可以通过一个独立的中间件服务伪装成MySQL的从节点实时接收主库推送的Binlog解析出“哪张表、哪一行、发生了什么变更”然后把变更信息投递给下游去做缓存更新。这就是互联网大厂里非常常见的“订阅Binlog刷新缓存”架构。它的精髓在于无论你的业务代码怎么写、从哪个入口改了数据只要底层MySQL库发生了变化Binlog就一定会记录缓存一致性的问题在架构层面彻底闭环。4.2 具体落地链路Binlog监控、消息队列、消费刷新为了便于理解我把这条链路的搭建过程拆成四个环节来说明。第一步开启MySQL的Binlog并且确保格式为ROW模式。因为只有ROW模式才能记录每一行数据的具体变更前后值适合我们做精确的缓存刷新。用如下配置开启# mysql.cnf 配置示例 [mysqld] log-binmysql-bin binlog_formatrow server-id1001第二步部署Binlog订阅中间件。中间件协议和MySQL从库一致向主库发送复制请求主库就会把Binlog事件源源不断地推给它。为了保证高可用订阅组件一般会部署多个节点配合ZooKeeper或类似注册中心做选主和状态协调确保同一时刻只有一个节点在消费某个库的Binlog。第三步解析Binlog事件将结构化变更信息投递到消息队列。这一步看起来简单其实有一些细节容易踩坑。比如Binlog事件里包含的是数据库底层的数据类型表示需要转换成业务可读的形式再比如一条SQL可能对应多行变更那就会产生多条变更事件还有事务边界问题一个事务内的多个变更事件应当在一个批次里被处理完不能半路拆分导致下游看到中间态。第四步消费端收到变更消息后执行缓存刷新动作。刷新策略一般是两种删除对应缓存key或者直接更新缓存。我个人的建议是优先删除原因在2.2里已经讲过删除比更新的风险小。如果某些业务场景实时性要求确实很高必须立即让缓存新值可见也可以重启一条单独的低延迟链路去做直接更新但需要自己加版本号之类的并发控制。4.3 这套方案的优缺点和适用边界Binlog订阅方案之所以被很多高并发团队采用是因为它有几个很难替代的优势。它完成了业务解耦。业务方写DB就好不用再关心“这个表有没有对应的Redis缓存、缓存key是什么”。新增缓存需求只需要在同步链路上加一个消费配置不用改动任何业务代码。它天然有序。Binlog是按照事务提交顺序记录的消费端按顺序处理就避免了并发更新乱序的问题。这一点是前面手动方案很难做到的。它可以做数据对账的基础。既然能实时同步变更那也可以周期性用变更日志和Redis内的数据进行比对发现不一致就自动修正。但它同样有不少限制。链路变长引入了中间件、消息队列等额外组件运维复杂度上升排障路径也变长。延迟客观存在从数据库提交到缓存被刷新中间隔着解析、投递、消费至少是几十毫秒到秒级的延迟业务上必须接受这个“最终一致”的时间差。还有一点它依赖MySQL的Binlog特性如果用的是云数据库且没有开放Binlog订阅能力这套方案就用不了。说到适用边界我通常建议这么来判断如果你面临的是核心业务的数据一致性痛点并且团队已经有一定的基础设施能力可以承受引入MQ和消费服务的运维成本那就值得上Binlog方案如果只是一两个业务场景手动同步不过来那杀鸡用牛刀先把Cache Aside做扎实更实际。5. 实战中的坑与排查经验5.1 缓存击穿、穿透和雪崩对一致性的干扰很多人聊缓存一致性只盯着“写入后怎么同步”但实际线上缓存本身的各种异常也会直接导致数据库数据和缓存长期不一致。这里简单提几个和一致性强相关的坑。第一个是缓存穿透。查询一个绝对不存在的key缓存里没有数据库里也没有每次请求都直接打库。如果不做空值缓存在恶意攻击或者大量非预期请求下数据库压力会直线上升最终可能拖垮服务而服务的异常崩溃又会导致缓存里的数据全面过期进一步放大不一致。应对方案是把空结果也缓存起来给一个很短的过期时间同时在接口层做参数校验和布隆过滤器拦截非法key。第二个是缓存击穿。某一个热点key在过期瞬间大量请求同时发现缓存未命中全部涌向数据库。正常情况下一个key过期了第一个请求去数据库查、回填缓存后面的请求都能命中但并发太高时一堆请求同时穿透到DB不仅查询压力大还可能同时回写缓存导致并存多个版本的数据令下游消费逻辑混乱。应对方案是加互斥锁保证只有一个线程回源数据库其他线程等待锁释放后直接查缓存。第三个是缓存雪崩。大量缓存key集中在同一时间过期引发数据库瞬问高负载。在一致性这个问题上更关键的是key集中过期时相关业务数据的缓存会有一大段“空窗期”此时所有读请求都会去数据库捞数据回填如果数据库最近有更新回填的时机不同容易产生新旧数据交错的缓存。应对思路是给过期时间加随机因子避免集中失效。5.2 排查缓存不一致的常规手段说实话线上真的出现缓存不一致的时候第一反应往往是“肯定是缓存删除漏了”但到底漏在哪需要一些排查手段。我自己的排查路径一般是这样的。先确认不一致的具体字段和key去Redis看一眼当前value以及TTL剩余时间再去数据库确认同一主键的最新值对比一下如果两者不一致判断是“数据库新、缓存旧”的正常同步延迟还是“数据库新、缓存旧”且迟迟不更新的故障。同步延迟是可以容忍的但持续不更新就需要查链路了。排查方向有三个一是查业务代码写接口里到底有没有执行缓存删除动作二是看Redis的慢日志有没有删除操作被阻塞三是看MQ消费链路如果用了Binlog订阅方案就要查消息消费延迟、消费失败重试队列里有没有堆积。另一个很实用的排查技巧是利用Redis的过期策略做“最终校准”。如果你不确定缓存脏数据什么时候能恢复可以临时把该key的TTL改短到几秒甚至直接DEL强制触发下一次回源重建。这在紧急修复线上问题时特别管用相当于手工触发了一次“最终一致性”.5.3 一致性方案的选型速查表很多同学最后都纠结一个问题我到底该用哪种方案我根据自己的经验整理了这么一张速查表基本可以覆盖大多数业务场景的选型需求业务特征推荐方案补充说明通用业务CRUD读多写少团队规模小Cache Aside先写库再删缓存必须搭配MQ重试删除缓存过期兜底超高并发对秒级不一致敏感Cache Aside 延迟双删延迟建议设置500ms~1s并结合业务慢查询评估数据可能只允许丢失少许、写频极高Write Behind异步批量回写适用于点赞数、浏览计数做好丢失补偿核心业务、跨多个服务、多入口写入Binlog订阅刷新缓存需要配套消息队列和消费服务链路较长数据强一致、不能依赖异步不做缓存或使用分布式锁短TTL高一致和高性能本身是矛盾的必须取舍5.4 几条实在的避坑体会最后说几条我踩过坑之后的体会不写代码就说点实在的。第一不要在更新DB和操作Redis之间加复杂业务逻辑。我见过有同学在删除缓存前先做了一堆计算、调了外部接口结果压测时一抖动缓存删除被拖到超时后面全链路都开始读旧值。删除缓存这个动作应该尽量紧跟在事务提交成功之后越早越好。第二消息重试必须设置最大重试次数不然一个坏key会一直在MQ里翻滚既占消息队列资源又让告警永远不消停。我在项目里的做法是超过5次重试后转入人工确认的“死信队列”同时记录告警确保同步问题能被暴露出来而不是悄悄消失。第三别把所有数据都设同一个过期时间。我给团队定的线是缓存过期时间可以按数据类型区分变化频繁的短一点稳定数据长一点再随机加20%的偏移量防雪崩的同时也让“最终一致”的时间差可控。第四也是最重要的一次性把“读路径”和“写路径”想清楚再动手。很多人只关注写路径怎么删缓存却忽略了读路径上的回填逻辑是否安全。比如前面反复提到的“读DB回写缓存”会不会覆盖新值这是读路径上的漏洞。读路径和写路径必须放到一起做并发分析任何一个环节留了窗口前面设计得再精巧都白搭。我个人在实际项目里的习惯是默认走Cache Aside先更新DB再删缓存删除动作通过MQ异步执行并带重试对最核心的几条热点数据单独加一个Binlog订阅链路做兜底校准。线上偶尔还会有短暂的不一致但基本都能在秒级内恢复。踩过几次坑之后我最大的体会是缓存一致性方案没有银弹本质上都是在“一致性强度”和“系统复杂度”之间做权衡。想清楚你业务能接受的最大不一致时间是多久再反推选哪套方案方向就不会偏。