缓存和数据库的一致性，别停在 “延时双删”

关注

原创 2026-11-04 09:56:17 218 阅读 AI 写同款· GEO 优化 ›

图解数据库和Redis缓存的一致性（延时双删与延时后删的区别及重要性）图解数据库和Redis缓存的一致性 问题来源使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库：读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。不管是先写MySQL数据库，再删除Redis缓存，再更新缓存；还是先删除缓存，再写库，再更新缓存。都有可能出现数据不一致的情况。举一个例子： 1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓阅读详情

商品详情页是后端最典型的读写并发场景。一天几千万次请求，九成以上打在读上，价格、库存状态、促销标签全在 Redis 里躺着。写操作每天只占千分之几，却足以让缓存和数据库打架。

先说说延时双删（也有人叫延迟双删）是怎么回事。它是这样一套动作：

删除缓存 → 更新数据库 → 等待几百毫秒 → 再次删除缓存

第一删是为了让后续读请求不至于读到老值；第二删是清理等待窗口内被重新回填的旧数据。

这套方案本身没有大问题，最大误区是把它当成最终方案。真正上线后，故障远不止 “第二次删除失败” 这一种。

一、那些被忽略的空档

先看最朴素的执行顺序：先更新数据库、再删缓存。

读请求 A：

T1：缓存未命中
T2：查询数据库拿到旧值 100
T3：把旧值写回缓存

写请求 B 在 A 读库、写缓存的间隙里，完成了数据库更新并删除缓存。此时缓存本就是空的，这次删除毫无作用。等 A 把旧值写入缓存，缓存与数据库数据永久不一致，且没有自动修复机制。

于是业界改成：先删缓存，再更新数据库。只是把风险窗口从 “读回填” 挪到 “数据库事务未提交”。窗口变窄，但并未消失：如果读请求在第一次删缓存之后、数据库提交之前进入，依然会读到旧值并回填缓存。

真正闭环：CDC 订阅 binlog

用 Canal 订阅 MySQL 的 binlog，等数据库事务真正提交成功后，再触发缓存删除。

触发逻辑从 “业务代码手动调用” 变成 “数据真实变更才执行”，天然保证顺序；
解决正常业务路径下的数据不一致问题；
短板：无法处理消费失败、消息积压、消费者重启丢失位点。

二、删除失败与缓存回血

Canal 消费失败、Redis 删除失败，只靠 “同步重试 3 次” 远远不够。标准落地是两层兜底方案：

1）MQ 异步重试（第一层保障）

缓存删除请求投递到消息队列；
消费失败采用指数退避重试；
超过重试阈值，消息进入死信队列并触发告警；
前提：删除操作必须幂等，删除不存在的 key 不报错，多次执行结果一致，重试不会产生副作用。

重点：重试绝对不能放在业务线程同步执行。同步重试会拉长接口 RT，一旦 Redis 抖动，直接阻塞下单核心链路。删除操作必须异步入队，业务线程只负责发消息。

2）定时增量对账（第二层兜底）

只抓取一段时间内发生变更的商品 ID，批量对比缓存与数据库数据，发现不一致就主动修正。不用全表扫描，只核对变更数据集，对数据库压力可控。

旧值回血问题（并发读回填脏数据）

缓存被旧值覆盖，根源在读请求回填逻辑，单纯靠重试删缓存解决不了。两种治理方案：

版本号控制（治本） 缓存 value 带上版本号（更新时间戳也可），读请求回填前先比对版本；如果当前数据版本低于缓存已有版本，直接丢弃写入，慢半拍的旧数据永远覆盖不了新数据。
短 TTL + 对账兜底（保底） 给缓存设置几十秒过期时间，脏数据最多存活几十秒，等待定时任务自动修正。

通常两个方案一起使用。

衍生问题：主从同步延迟

写主库、读从库，binlog 同步存在几十～几百毫秒延迟。这段时间从库读到的依然是旧数据，回填缓存就会产生脏数据。

两种解法：

强一致性场景（秒杀价格、库存）：更新后的一小段时间，读请求强制路由主库；
低成本方案：把缓存删除延迟时间拉长，覆盖主从同步耗时，预留足够时间余量。

三、删太多和删太频：高并发下的性能问题

一致性方案必然带来性能损耗，在高并发场景下会被成倍放大。

场景 1：批量更新（大量 key 集中删除）

运营一次性批量修改 5 万个 SKU 价格，循环删除 5 万个 Redis key，瞬间击穿缓存，大量请求直接穿透到数据库，缓存整体失效。

优化手段：

分批执行：ID 拆分，每批几百个，批次之间增加时间间隔；
避免直接删除：只把版本号 + 1，依靠 TTL 让旧缓存自然失效；
大键删除使用 UNLINK，不要用 DEL，防止阻塞 Redis 主线程。

场景 2：热点 Key 击穿

爆款商品缓存一旦被删除，上万并发请求同时击穿到数据库，直接把 DB 打满。

优化方案：

热点 Key 不设置自动过期，由后台定时任务主动刷新；删除时加分布式锁，只放行一个请求重建缓存，其余请求等待；
逻辑过期（最优方案）：缓存里写入过期时间，读到过期数据时，先把旧值返回给用户，同时异步刷新缓存，用户完全无感知。

额外优化：多级缓存

读多写少场景增加本地缓存：Caffeine 一级本地缓存 + Redis 二级远程缓存，大幅减少跨网络调用。代价：多实例部署下本地缓存很难做到强一致，依靠广播失效 + 1~2 秒短 TTL 兜底即可。

四、先明确业务需要哪种一致性

不是所有业务都要上一整套强一致方案，按需选型才是最优解。

强一致（核心交易数据） 价格、库存、优惠券状态，一旦出错直接造成资金损失。方案：读请求强制走主库；缓存只做加速，不作为权威数据源；缓存删除失败直接阻塞或降级，宁可慢，不能错。
最终一致（普通商品信息） 商品标题、详情图、店铺公告，数据延迟几秒完全不影响用户体验。方案：Canal 异步删缓存 + 定时对账兜底，成本与收益匹配。
允许误差（计数类数据） 浏览量、点赞数、曝光计数，写入量大，允许少量误差。方案：先写缓存，异步刷入数据库，定期校准；没必要为这类数据搭建复杂的强一致架构。

选型标准：评估数据不一致的时长、误差范围，业务能否接受。把这个边界确认清楚，方案自然就定下来了。

五、落地代码的几条经验

所有缓存删除操作必须打印日志并埋点监控：删除失败次数、重试次数、死信队列堆积量，这三项指标比架构图更能反映链路健康度。
缓存 Key 命名要可以反向追溯数据表，方便定位脏数据，也便于对账任务按业务分片执行。
对账任务严禁全表扫描。采用增量时间窗比对，配合每日凌晨低峰期少量全量抽样校验。
数据库事务未提交前，绝对不能发送缓存删除消息。使用事务消息 / 本地消息表保证：事务提交成功才发消息。否则消息先到、数据库还没提交，删完缓存立刻被旧值回填。