延迟双删-EW帮帮网

“延迟双删”是一种 在使用缓存（如 Redis）时保证缓存与数据库一致性 的策略，主要用于解决缓存与数据库之间可能出现的数据不一致问题。

一、为什么需要延迟双删？

背景：

在使用缓存时，典型的写流程是：

更新数据库 → 删除缓存

但高并发下可能会出现脏数据。例如下面这个顺序：

线程1 读取缓存（此时缓存存在旧数据）
线程2 更新数据库 + 删除缓存
线程1 把旧数据重新写入缓存（造成脏数据）

最终缓存中保存的仍然是旧数据，数据库是新数据，导致缓存与数据库不一致。

二、延迟双删的核心思想

在第一次删除缓存后，等待一段时间，再删除一次缓存。

流程图：

1. 更新数据库
2. 删除缓存（第一次）
3. 休眠一段时间（例如500ms）
4. 再次删除缓存（第二次）

三、延迟双删的流程图示例：

用户发起更新请求
        ↓
数据库更新成功
        ↓
第一次删除缓存（此时其他线程如果读到了旧缓存会写回）
        ↓
休眠（等待潜在的写回）
        ↓
第二次删除缓存（把前面写回的旧数据再删掉）

四、代码示例（Java伪代码）

public void updateData(String key, Object newData) {
    // 1. 更新数据库
    db.update(key, newData);
    
    // 2. 删除缓存
    redis.del(key);

    // 3. 延迟双删（异步线程中执行）
    new Thread(() -> {
        try {
            Thread.sleep(500); // 500ms 视情况可调
            redis.del(key);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();
}

五、延迟双删适用场景

高并发更新数据 且数据一致性要求高。
热点数据存在并发读写的风险。
系统已经在使用 Redis 做缓存，但未引入复杂的缓存一致性机制（如消息队列等）。

六、延迟双删优缺点

✅ 优点：

实现简单
能显著降低缓存脏读的概率
无需引入额外中间件（如MQ）

❌ 缺点：

延迟时间不好设置，可能因业务不同而有偏差
不能百分百解决一致性（极端情况下仍然可能失败）
存在一定的资源浪费（多次删除缓存）

七、与其他方案对比

方案	特点	一致性保障	实现复杂度
先删缓存再更新数据库	不推荐，会有并发写丢失问题	差	简单
更新数据库后删缓存	普通方案，但有并发问题	中	简单
延迟双删	在前者基础上改进，容错更强	较好	简单
消息队列同步删除	通过MQ异步删除缓存	更好	中等
缓存一致性中间件（如 Canal + MQ）	高一致性保证	最好	复杂

八、总结

延迟双删是一种简单有效的缓存与数据库一致性保护手段，适用于多数读多写少、并发不是极端高的业务系统。对于大规模分布式场景，可结合 Canal、Binlog、消息队列等更强一致性方案。

延迟双删