先更库还是先删缓存数据库与 Redis 双写一致性全对比这个问题几乎每个后端都踩过坑。答案看似简单实则藏着极端场景下的致命 bug。核心矛盾为什么需要双写因为数据库和 Redis 的角色不同角色职责MySQL最终数据源保证持久化和事务Redis热点缓存加速查询读多写少时数据同步路径是写 DB → 删/更缓存 → 下次读命中缓存。问题就出在这个箭头上顺序反了数据就脏了。方案一先更库后删缓存主流推荐 ✅这是大多数公司的默认选择。流程① 更新 MySQL ② 删除 Redis 缓存 ③ 下次读 → 缓存未命中 → 回源查 DB → 写入缓存为什么推荐因为删缓存比更新缓存安全。删缓存最坏结果是缓存短暂不存在读请求回源一次数据最终一致更新缓存如果更新失败缓存里存的是旧数据用户永远拿不到新值但有一个致命场景延时双删都救不了时间线 T1: 线程A 更新 DB新值 100 T2: 线程B 读缓存 → 命中旧值值 50 T3: 线程A 删缓存 T4: 线程B 旧值已读走返回 50 ❌问题本质更新 DB 和删缓存之间存在时间差这段窗口内旧读请求可能恰好命中缓存。这不是概率问题高并发下一定会发生。怎么解决三种手段手段原理效果延时双删更新 DB 后延迟 N ms 再删一次缓存兜底但 N 难设定串行化同一 key 的读写加分布式锁强一致但牺牲性能消息队列更新 DB 后发 MQ异步确保删缓存解耦但引入最终一致性其中消息队列方案是大厂最常用的更新 DB → 写 Binlog → Canal 订阅 → 发送 MQ → 消费删缓存Canal 把删缓存这个动作从业务代码中剥离即使删失败MQ 会重试保证最终一定删掉。方案二先删缓存后更库绝对不推荐 ❌流程① 删除 Redis 缓存 ② 更新 MySQL ③ 下次读 → 缓存未命中 → 回源查 DB → 写入缓存新值看起来也能保证最终一致看这个场景时间线 T1: 线程A 删缓存 T2: 线程B 读缓存 → 未命中 → 查 DB此时 DB 还是旧值 T3: 线程B 把旧值写入缓存 T4: 线程A 更新 DB新值 100 结果缓存 旧值DB 新值数据永久不一致 ❌❌❌这个 bug 比方案一严重得多对比项先更库后删缓存先删缓存后更库脏数据持续时间短暂下一次读就修复永久直到缓存过期或手动清理发生概率高并发下必现较低但一旦发生就是脏数据修复成本自动修复需要人工介入或等待过期先删缓存的最大风险是在 DB 更新完成前旧值已经被写回缓存了。一旦发生缓存里的旧值会一直存在直到 TTL 过期。如果 TTL 设得很长比如 1 小时这 1 小时内所有读请求都拿到脏数据。两种方案终极对比维度先更库后删缓存 ✅先删缓存后更库 ❌脏数据窗口极短μs~ms 级可能很长直到 TTL 过期脏数据能否自愈✅ 能下次读自动修复❌ 不能旧值已写入缓存实现复杂度中等需处理延时双删或 MQ简单但风险极高大厂实践✅ 主流方案❌ 基本不用推荐指数⭐⭐⭐⭐⭐⭐真正的最优解不要自己写双写逻辑最高效的做法是让基础设施替你完成方案工具原理Binlog 异步删除Canal MQ监听 DB 变更异步删缓存失败重试订阅 Binlog 直写Otter / Maxwell变更直接同步到 Redis不经过业务代码缓存中间件JetCache / Cache Aside 框架封装双写逻辑内置重试和补偿核心思想一致把删缓存从业务主流程中剥离用异步 重试保证最终一致性。一句话总结先更库后删缓存。不是因为它完美而是因为它的最坏情况只是短暂不一致而反过来的最坏情况是永久脏数据。能用 MQ 异步删就别在主链路上同步删。能让 Canal 干的活就别让业务代码扛。双写一致性的本质不是选顺序而是承认一定会不一致然后设计一个能自愈的机制。