为什么需要延迟双删，两次删除的原因是什么

https://chat.deepseek.com/share/b6mrk1inagre33j6r3

面试记录 2026-10-15

题目：为什么需要延迟双删，两次删除的原因是什么？

难度：medium

评分：⭐⭐⭐⭐☆☆（3/5）

我的回答

延迟双删是为了保证多线程下,并行进行对数据进行更新时缓存的准确性的;因为多线程同时进行操作的情况下,A 线程更新了数据库,然后删除缓存,这个阶段如果 B 线程读取数据库,数据,由于 A 数据库的事务未执行完或者主从数据库的主从延迟导致 B 读取到了老的数据,并写回到缓存中,导致缓存错误,这时候延迟进行二次删除可以有效规避这种问题;另外可以通过 mq 监控数据库的 binlog 变更来对缓存进行删除处理,不过需要对应依赖和实现

点评

优点：

并发场景抓到了- A/B 线程时序问题描述清楚- Binlog+MQ 备选方案提到

不足：

❌ 遗漏延迟时间如何确定（覆盖主从同步+事务提交时间）- ❌ 遗漏延迟双删的本质是 Cache Aside + 二次删除- ❌ 遗漏先更DB vs 先删缓存的决策- ⚠️ "主从延迟"表述不精准，应是"并发读请求读到未提交或旧数据"

完整讲解

第一部分：知识重点剖析

核心考点：考察对缓存一致性策略的理解，区分"延迟双删"和"Cache Aside"的层次关系。

知识点拆解：

1. Cache Aside 模式：读时先读缓存，缓存未命中则读 DB 并写回缓存；写时先更 DB，再删缓存（不是更新缓存，避免并发写导致缓存不一致）。
2. 延迟双删的本质：Cache Aside + 二次删除，解决并发读写时序问题。
3. 并发时序问题：

• T1：A 线程更新 DB（事务未提交）
• T2：B 线程读 DB（读到旧数据）
• T3：A 线程删除缓存
• T4：B 线程把旧数据写回缓存 → 缓存错误

1. 延迟双删方案：更新 DB → 删除缓存 → 延迟 N ms → 再删除缓存。第二次删除清掉 B 线程写回的旧数据。
2. 延迟时间确定：覆盖"事务提交时间 + 主从同步时间 + 读请求耗时"，一般 500ms-2s。
3. 其他方案：

• Binlog + MQ（Canal）：监控 DB binlog，异步删缓存，彻底解耦
• 订阅 DB 变更：类似 Canal，但 DB 原生支持
• 先删缓存再更 DB：风险更大（删缓存后 DB 更新失败，缓存永久缺失）

局限性：延迟双删无法解决所有并发问题，仍需最终一致性；延迟时间不好精确确定；网络抖动可能放大问题。

第二部分：考察方向与延伸递进

1. 先更 DB 还是先删缓存？

• 解答：Cache Aside 推荐先更 DB 再删缓存。先删缓存再更 DB 风险更大（删缓存后 DB 更新失败，缓存永久缺失）。

1. 延迟双删和 Canal 怎么选？

• 解答：简单场景用延迟双删，复杂/高一致性要求场景用 Canal（解耦、可靠、可追溯）。

1. 延迟双删的延迟时间怎么定？

• 解答：覆盖事务提交时间 + 主从同步时间 + 读请求耗时，一般 500ms-2s。可通过压测确定。

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，延迟双删的本质是 Cache Aside + 二次删除，解决并发读写时序问题。

Cache Aside 模式下，写时先更 DB 再删缓存。但并发时序会导致缓存不一致：A 线程更新 DB（事务未提交），B 线程读 DB 读到旧数据，A 线程删除缓存，B 线程把旧数据写回缓存——缓存就错了。

延迟双删方案：更新 DB → 删除缓存 → 延迟 N ms → 再删除缓存。第二次删除清掉 B 线程写回的旧数据。

延迟时间需要覆盖"事务提交时间 + 主从同步时间 + 读请求耗时"，一般 500ms-2s。可通过压测确定具体值。

更彻底的方案是 Canal：监控 DB binlog，异步删缓存。Canal 解耦、可靠、可追溯，适合高一致性要求的场景。

延迟双删有局限：无法解决所有并发问题，仍需最终一致性；延迟时间不好精确确定；网络抖动可能放大问题。生产环境建议用 Canal，简单场景用延迟双删。