redis延时双删，为什么第一次删除

Redis延时双删策略中第一次删除的作用

在缓存与数据库一致性方案中，"延时双删"（Delayed Double-Delete）是一种经典策略，其核心流程如下：

1. 第一次删除：更新数据库前，先删除缓存

2. 更新数据库：执行数据库写操作

3. 第二次删除：延迟一段时间后，再次删除缓存

---

第一次删除的核心作用

1. 防止旧缓存污染

• 场景：在并发写请求时，如果没有第一次删除：

  • 线程A更新数据库（新值）

  • 线程B在A更新数据库后但未删除缓存前，读取了旧缓存

  • 结果：缓存中残留旧数据，导致不一致

• 第一次删除确保更新数据库前，缓存已被清除，强制后续读请求回源到数据库获取最新值。

2. 降低“写后读”不一致窗口期

• 即使有并发读请求在第一次删除后、数据库更新前发生：

  • 由于缓存已被删除，读请求会从数据库加载即将更新的新值（而非旧值）。

  • 比不删除缓存直接更新数据库的窗口期更短。

3. 配合第二次删除形成“双保险”

• 第一次删除：主动清除可能的脏数据

• 第二次删除（延迟后）：清理并发读请求可能引入的旧缓存

• 两者结合可将不一致时间窗口压缩到毫秒级。

---

为什么需要第二次删除？

第一次删除无法完全避免以下场景：

1. 并发读请求在第一次删除后、数据库更新前发生：

   • 线程A删除缓存（第一次删除）

   • 线程B读缓存未命中，从数据库读取旧值并回填缓存

   • 线程A更新数据库为新值

   • 结果：缓存中是旧数据

2. 数据库主从延迟：

   • 从库未同步最新数据时，读请求可能读取到旧值并回填缓存。

第二次删除通过延迟清理（通常500ms-1s）确保：

• 主从数据库已完成同步

• 并发读请求的旧缓存已回填并被清理

---

完整流程示例

图表

代码

下载

DBCacheClientDBCacheClient延迟时间需覆盖：- 主从同步耗时- 并发读请求处理时间1. 第一次删除缓存（DEL key）2. 更新数据库（UPDATE）3. 延迟后第二次删除（DEL key）

---

适用场景

• 写多读少：频繁更新时减少缓存不一致风险

• 对一致性要求较高：如金融、订单状态等业务

• 无法使用订阅数据库日志（如Canal）的场景

---

注意事项

1. 延迟时间设置：

   • 通常500ms-1s，需根据主从同步时间和业务RT调整

   • 过长：影响实时性；过短：可能未覆盖脏数据回填

2. 删除失败处理：

   • 建议增加重试机制或异步消息队列保障删除成功

3. 替代方案：

   • 更强一致性方案：Redisson分布式锁 + 串行化读写

   • 最终一致性方案：订阅数据库Binlog（如Canal）自动更新缓存

第一次删除是延时双删的前置防御，第二次删除是后置补偿，两者结合才能最大化降低不一致风险。