Redis与MySQL数据一致性：告别延时双删，构建高可靠缓存方案

前几天一个朋友从大厂二面出来复盘时第一句话就是还是那道“如何保证 Redis 和 MySQL 的数据一致性”。他说自己把背熟的“延时双删”完整背了一遍结果面试官反手三连问Sleep 定多少毫秒第二次删失败怎么办并发读线程把旧值写回缓存怎么办当场卡住。这道题在一线互联网面试里几乎是缓存链路必考题。算法题你可以靠运气但 Redis 和 MySQL 双写一致性基本是每个写业务的开发都得面对的实战题。网上资料很多翻来覆去就是延时双删但真正在线上跑过的人都知道靠一段 sleep 根本兜不住一致性。这篇文章我想把这道题的本质、延时双删的缺陷、高性能高可靠的方案设计、可落地的代码实现以及实际排障经验完整捋一遍。给准备面试的朋友一条能复述、有细节、经得起追问的回答路径也给正在写缓存层代码的同学一套能直接上线的思路。1. 这个问题到底在问什么先看清一致性窗口长在哪1.1 不一致是怎么产生的一段代码引发的旧值回写我们先用一个最典型的缓存旁路模式Cache Aside来分析。读路径一般是读 Redis 缓存未命中就去查 MySQL查到后把结果写回缓存。写路径一般是先更新 MySQL再把缓存删掉等下次读再回填。看起来没问题但“先读再回写”和“先写再删”一旦并发就会出现经典时序线程 A 读缓存未命中去 MySQL 查数据得到旧值比如库存10。线程 B 更新 MySQL把库存改成 8之后删除了缓存中的 key。线程 A 此时才把旧值 10 写回缓存。后续所有读请求都命中缓存读到库存10脏数据持续存在。很多人以为只有更新缓存才会造成覆盖其实“删除缓存”也会被读线程的“写回动作”反向覆盖。这就是一致性问题最容易出事的窗口读线程拿着旧值写回缓存的一瞬间。除了并发旧值回写还有另一个常见故障来源删除缓存本身会失败。比如更新 MySQL 成功了但 Redis 删除 key 时恰好超时、网络抖动甚至 Redis 实例不可用那缓存里旧值就会一直存在。两种问题叠加才是这道题真正要解决的完整画面。1.2 面试官到底想考什么强一致 vs 最终一致很多候选人一上来就背方案但没有意识到面试官真正想考察的是你对“一致性等级”的判断力。缓存和数据库之间能不能做到强一致理论上可以比如引入分布式事务、2PC、TCC或者让所有读写都走数据库缓存只做加速。问题是这些方案在性能、可用性、改造成本上都很难接受。打个比方强一致像是在两栋楼之间修一座随时锁死的桥人走时必须两边同步确认一旦一边故障整座桥瘫痪。最终一致则是允许桥上市民走快走慢但保证一段时间后所有人都到达正确位置。业务上大多数读多写少场景根本不需要实时强一致只需要最终一致并且把不一致窗口压到可接受范围。所以面试官要的答案通常不是“有没有万能方案”而是你能不能讲清楚三个点哪些环节会产生不一致窗口用什么机制收敛这个窗口代价是什么。理解了这一层后面所有方案才不是死记硬背。1.3 为什么“先删缓存再更新 DB”也不可靠网上有些文章会建议先删缓存、再更新 DB理由是缓存清掉后读请求不会命中旧值。但实际操作中问题很多如果 DB 更新失败缓存已经被删了原本还能命中的 key 变成空窗此时并发请求全部穿透到 MySQL数据库压力瞬间飙高。更关键的是更新 DB 需要时间期间其他读线程完全可能查旧值再把旧值回写缓存删除动作等于白做。反向来看“先更新 DB 再删除缓存”在失败态下更可控DB 更新失败时缓存没有被动过数据库和缓存都是旧值仍然一致DB 更新成功后哪怕缓存删除失败也只是产生了一段脏窗口后续还能通过补偿机制收敛。这也是后面所有方案的主路径都选择“先写库再删缓存”的根本原因。2. 延时双删为什么是玄学三个致命缺陷延时双删的做法是先删缓存再更新 DB然后 sleep 一段时间最后再删一次缓存。设计初衷是覆盖“第一次删除后、DB 更新完成前读线程把旧值写回缓存”的窗口。看起来挺合理可真到了线上它有三个绕不过去的问题。2.1 Sleep 窗口根本算不准延时双删最核心的参数是 sleep 时间。要说清这个时间怎么定你得回答读线程从 Redis 未命中到查完 MySQL 并写回缓存需要多少毫秒这个时间受接口链路影响比如底层 SQL 是否走了索引、网络 RT 是多少、GC 有没有停顿、应用服务器线程调度是否被拖慢。不同业务、不同峰值流量下这个值完全是波动的。我在网上看到过太多文章直接说“sleep 500ms 就行”也有说“1 秒保底”。这种固定值在本地单测可能没问题一上生产就露馅。并发高的时候一次 CPU 饥饿或 Full GC 就能让读线程的写回动作拖到几秒之后sleep 时间设短了旧值照样写回缓存设长了缓存空窗时间被拉得很长大量请求直接打到 MySQL缓存的意义被削弱。2.2 第二次删除仍然可能失败延时双删的“双”字容易给人安全感但第二次删除本质上还是一次普通 Redis 操作。如果第二次删除执行时 Redis 连接池已满、网络超时或者 Redis 实例发生主从切换删除命令照样失败。双删并没有为重试留出空间Del 失败之后没有任何后续动作缓存会一直保留旧值直到 TTL 到达。我在线上排过类似问题一个订单服务用了延时双删某天 Redis 主节点抖动写库成功、缓存删除超时结果用户在前端看到的订单状态直到缓存过期才被纠正。根本原因就是第二次删除没有重试也没有失败告警。所以“双删”只是增加了概率上的多一次机会不等于可靠机制。2.3 多了一次删除缓存压力跟着翻倍延时双删让每次写操作至少执行两次缓存删除这中间缓存 key 处于“缺失状态”。在读写比为 10:1 的业务里第二次删除后的空窗期会有大量请求回源 MySQL。如果刚好赶上热点数据缓存击穿概率明显上升数据库很可能被突如其来的流量打垮。这也是延时双删最尴尬的地方要想覆盖并发窗口就得把 sleep 调大但 sleep 越大缓存空窗越大数据库压力越大要想保护数据库就得把 sleep 调小但又压不住旧值回写。这本质上是一个靠拍脑袋参数来赌并发时序的方案和“高性能 高可靠”两个目标背道而驰。2.4 面试时该怎么看待延时双删不是说延时双删完全不能用。如果业务对一致性窗口容忍度很高、key 的写并发极低用它顶一阵子也行。但面试时主动说“我用延时双删解决”说明你对失败补偿缺少意识。更好的表达方式是延时双删的本质是用人为 sleep 代替机制补偿它只能降低概率不能保证删除成功也不能阻止极端并发下的旧值回写。所以我会选择更工程化的组合方案。3. 高性能 高可靠方案把一致性做成闭环我一直认为可靠的一致性方案不是找一个“完美算法”而是把每一个可能出错的环节都设计出兜底路径。主线思路是三条主路径尽快让缓存失效失败路径能自动补偿极端并发有版本或过期时间兜底。三者合起来一致性窗口才能从“玄学”变成“可控”。3.1 主路径先更新 DB事务提交后再删除缓存先更新 DB 再删除缓存已经说过这里重点说“事务提交后再删”这个细节。很多人写代码时把“更新 DB”和“删除缓存”放在同一个事务里事务还没提交就去删缓存。问题在于如果事务最后回滚了缓存已经被删除其他请求全部打穿到 DB如果事务提交后缓存在删除过程中失败还得靠外部补偿。正确的做法是更新 DB 成功后、事务提交后再触发缓存删除。在 Spring 工程里我常用 TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT) 来监听事务提交事件或者直接在业务代码里用 TransactionSynchronizationManager.registerSynchronization 注册提交后回调。这样能保证“DB 数据已生效”和“缓存删除动作”的顺序避免无意义的缓存空窗。至于为什么是删除缓存而不是更新缓存道理也不复杂并发写场景下线程 A 和线程 B 同时更新同一个缓存 key谁后写谁就覆盖先写的中间值而删除缓存则和具体值无关相当于声明“这个 key 失效了请重新加载”。删除天然具备幂等性重复删不会出错也更适合放进异步重试机制。3.2 删除失败有兜底本地消息表 指数退避重试单纯在事务提交后调一次 Redis 删除并不够——删除如果失败就需要一个可靠的保存机制把“待删除任务”留下来。这里最实用、最容易落地的是本地消息表。思路是在更新 DB 的同一事务里把业务数据更新和一条“待删除缓存”记录写进同一个 MySQL 数据库。事务提交后一个后台任务反复扫描这张表把所有状态为待处理的任务捞出来执行 Redis 删除删除成功就把任务状态置为完成删除失败就累加重试次数并按指数退避策略计算下次执行时间。因为删除动作是幂等的重复执行也不会有副作用。这个方案的本质是把“两个系统之间的最终一致性问题”转换成“单库事务内的一致性问题”只要业务记录和删除任务同事务提交任务就不会丢。重试表相当于给 Redis 删除动作加了持久化日志不再依赖 sleep 来赌时序。3.3 更彻底地兜底订阅 Binlog 再删一次本地消息表虽然可靠但需要侵入业务代码每个写方法都要记得写一条任务。有没有办法连这块代码都省掉有就是订阅 MySQL 的 Binlog。常见做法是部署 Canal。Canal 会把自己伪装成一个 MySQL 从库拿到主库 Binlog 中的变更事件再推送给消费端。消费端拿到变更事件后解析出表名、主键、操作类型按业务规则拼出 Redis key执行删除。这样做的好处非常明显只要主库更新成功Binlog 就一定会记录变更漏事件的概率极低业务代码只需要关心核心逻辑不用额外维护重试表。但它也有代价从 DB 更新提交到 Binlog 被 Canal 捕获再到消费者执行 Redis 删除中间有一段网络和组件传输延迟通常在几十毫秒到秒级。单独靠它做一致性脏窗口会比本地消息表更长。所以我的建议是把它作为最终兜底主路径尽力删除Binlog 路径负责把主路径漏删的 key 补一次删除。两条路径互为备份可靠性明显提升。3.4 版本号与过期时间兜底防止旧值回写有了加法路径和补偿路径是不是就完美了还差最后一层并发读线程把旧值写回缓存的问题。如果你的并发窗口极窄靠 TTL 兜底就够了但想压得更稳可以引入版本号机制。思路是数据库表中增加 version 字段或 update_time 字段缓存 value 里同时保存版本号。读线程回写缓存时带上这个版本号写线程更新 DB 后删除缓存时顺手记下新的版本号。后面读请求发现缓存里的版本号明显旧于期望值就不会信任缓存直接回源 DB。删除缓存失败后旧缓存虽然还在但版本号已被标记为过期读请求会绕过它。如果不想大动干戈另一个轻量做法是给缓存设置较短的过期时间比如 5 到 10 分钟。哪怕极端情况下删除失败、旧值回写最坏也能在 TTL 时间后自动收敛。用工程上的话讲这叫把“最大不一致时间”约束到 TTL 以内。4. 实操演示一套可直接复用的组合方案方案聊再多最后还得落代码。下面是我在项目里实际用过的组合事务内写任务 事务提交后删缓存 失败重试表 可选 Canal 兜底。这套组合不依赖 sleep性能和可靠性都远比延时双删好。4.1 整体架构与模块划分先看模块清单模块职责关键组件失败处理写操作主流程更新 MySQL同一事务写缓存删除任务MySQL 事务事务回滚则不产生任务缓存删除执行器事务提交后立即删除 Redis keyRedisTemplate / Jedis失败则标记重试重试补偿任务扫描未完成任务按退避策略重试XXL-Job / Spring Scheduled超过次数进入告警Binlog 兜底消费可选监听变更事件补删缓存 keyCanal RocketMQ/Kafka消费失败持久化重试监控告警统计删除失败次数、缓存不一致 key 数Prometheus Alertmanager告警人工介入主链路是请求到达服务更新 MySQL事务提交后删除 Redis key。删除失败就把任务表状态更新为“重试中”由后台任务继续处理。如果有 Canal则无论主链路删除是否成功Binlog 消费者都会再删一次确保最终收敛。4.2 核心代码更新 DB 与写删除任务同事务先看主流程代码使用 Spring Boot 和 MyBatis 实现Transactional public void updateOrder(OrderUpdateDTO dto) { // 1. 更新 MySQL 订单表 orderMapper.updateById(dto.toOrder()); // 2. 同一事务内写入待删除缓存任务 CacheDeleteTaskEntity task CacheDeleteTaskEntity.builder() .bizType(ORDER) .cacheKey(CacheKeyBuilder.orderDetailKey(dto.getOrderId())) .status(CacheTaskStatus.PENDING.getCode()) .nextRetryTime(LocalDateTime.now()) .retryCount(0) .build(); cacheDeleteTaskMapper.insert(task); } // 事务提交后执行缓存删除 TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT) public void onOrderUpdated(OrderUpdatedEvent event) { String cacheKey CacheKeyBuilder.orderDetailKey(event.getOrderId()); boolean deleted cacheService.deleteWithShortTimeout(cacheKey); if (!deleted) { cacheDeleteTaskMapper.markPendingToRetry(event.getTaskId()); } }这里有两个关键点。第一任务表和业务表必须在同一个事务里写入否则事务回滚会留下“业务没更新但任务已存在”的脏状态。第二删除缓存要放在事务提交后的监听器里而不是业务方法内。我在代码里用 deleteWithShortTimeout 而不是直接 delete是给 Redis 操作设置一个较短的超时时间比如 300ms避免删除动作拖慢主链路。4.3 重试表结构与补偿任务设计配套表结构可以这样建CREATE TABLE cache_delete_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型, cache_key VARCHAR(255) NOT NULL COMMENT 缓存 key, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待处理 1-已完成 2-重试中 3-最终失败, retry_count INT NOT NULL DEFAULT 0 COMMENT 已重试次数, next_retry_time DATETIME NOT NULL COMMENT 下次执行时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_retry (status, next_retry_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT缓存删除任务表;后台补偿任务的核心逻辑是每分钟扫描一次捞出 next_retry_time 小于当前时间且状态为待处理或重试中的任务限制每次处理 100 条逐条执行 Redis 删除。删除成功后把状态置为已完成删除失败则 retry_count 加一按“1s、2s、4s、8s、16s、不超 5 次”的退避策略更新 next_retry_time。超过最大重试次数就把状态置为最终失败并接入告警。扫描逻辑千万不要一次捞全表否则历史数据堆积后会把任务表拖垮。我的习惯是先查 100 条处理完再查下一批同时对已完成记录每天定时清理只保留最近 7 天。这样任务表数据量始终可控备份和恢复成本也低。4.4 Binlog 兜底消费的实现要点如果你已经引入 Canal消费端处理流程大致是这样的public void onBinlogEvent(BinlogMessage msg) { if (!order.equalsIgnoreCase(msg.getTableName())) { return; } if (msg.getEventType() ! UPDATE msg.getEventType() ! INSERT) { return; } String orderId msg.getAfterRow().get(id); String cacheKey CacheKeyBuilder.orderDetailKey(orderId); cacheService.deleteWithShortTimeout(cacheKey); }这里要注意三点解析 Binlog 后拼出的缓存 key 必须与业务代码里的 key 规则完全一致消费端必须保证幂等重复删除没有问题但不要把 event 丢失Canal 消费延迟会影响兜底时效所以最好把它放在补偿层而不是主链路。只要主链路和 Binlog 兜底都能正常跑即使某一条删除在业务层失败也会在 Canal 消费后补上。4.5 关键参数建议清单参数推荐值说明缓存 TTL5-10 分钟兜底最大不一致时间删除超时时间200-500ms避免阻塞主链路重试初始间隔1s不宜过小防抖退避倍数2指数退避最大重试次数5超过就告警任务扫描频率1 次/分钟覆盖秒级到分钟级恢复单批扫描量100防止大事务Canal 消费并发3-5按业务量调整大 key 删除命令UNLINK避免 DEL 阻塞这组参数来自我的线上调优经验。缓存 TTL 不要选太长否则兜底太久太短又会频繁回源 DB。删除超时控制在 500ms 以内宁可让任务多走一次重试也不能让写请求普遍变慢。5. 常见问题与排查技巧实录方案落地后真正考验人的是所有边界场景。下面几个问题我基本都在生产环境遇到过逐个说下我的处理方式。5.1 删除缓存时 Redis 阻塞怎么办一次 Redis 删除操作如果遇到大 keyDEL 可能阻塞 Redis 主线程上百毫秒严重时整实例响应变慢。正确做法是用 UNLINK 命令它是异步释放内存即使 key 大小达到几 GB也不会长时间阻塞实例。在重试任务里也要避免一次性并发删除大量 key批量任务建议控制并发在 3 到 5 个以内防止把 Redis 打到超时。5.2 缓存删了还被旧值回写怎么解决这个问题的根源是读线程在删除前已经查出旧值删除后它才把结果写回。我的处理思路是双层防御给缓存 key 设置较短 TTL 兜底对特别核心的数据在读路径增加版本号校验写回前先比较缓存中是否有更新版本有就放弃回写。如果不想引入版本号也可以退一步接受短时间脏读但要明确它的最大窗口就是 TTL。5.3 分布式锁要不要用有些文章推荐在缓存更新前后加重试锁认为可以完全消除窗口。实际工程里分布式锁只能让并发读写变成串行对性能影响很大而且锁的粒度、超时时间、公平性都是一堆新问题。我更建议只在热点写冲突极其严重的 key 上针对性地加锁不要全局无脑上锁。缓存一致性方案的重心应该放在“失败可重试、数据可收敛”而不是把所有并发都串起来。5.4 缓存与 DB 不一致如何快速定位如果业务反馈数据有延迟我一般会写一个对账脚本扫描缓存里的核心 key读取 DB 最新值比较数据内容或版本号把不一致的 key 输出到日志。接下来看 cache_delete_task 表里有没有状态为最终失败的任务如果有大概率就是某个删除操作一直没成功。再看 Canal 消费的 lag 指标确认 Binlog 消费者是否积压。三个步骤下来不一致的范围和原因基本能锁定。5.5 面试作答顺序建议面试官如果让你“说说怎么保证一致性”不要上来就讲代码。我建议这样组织答案先说“缓存一致性本质是最终一致强一致不是缓存场景的常规选择”再说主路径是更新 DB 后事务提交删除缓存接着说删除失败如何兜底比如本地消息表重试或订阅 Binlog 补偿最后提防旧值回写的方式是 TTL 和版本号。结尾主动指出这套方案仍存在毫秒级窗口说明你对自己的方案边界有清醒认知。我个人在实际项目中踩过很多次坑之后最大的体会是一致性方案的关键不是某个单一技巧而是让每一个可能失败的动作都有重试、有监控、有收敛路径。延时双删的 sleep 之所以不靠谱就是因为它把“希望”寄托在不确定的时间窗口上。真正上线后我会优先选择“先更新 DB 事务提交后删缓存 失败任务表 Binlog 兜底”的组合。这套方案不花哨也能在保证高性能的同时让脏数据窗口处于可控状态。如果你也在准备面试或者正在设计缓存架构不妨从这套组合开始把每一步的失败场景都列出来你会发现一致性问题的答案并不是背出来的而是推演出来的。