延迟双删是什么意思？

咱就是说你懂的，这个“延迟双删”，听起来有点儿复杂，但其实它解决的问题挺实际的。想象一下你有一个缓存系统，数据一会儿在内存里一会儿在数据库里。当用户请求数据的时候，先kankan缓存里有没有，Ru果没，就去数据库找。这就是所谓的 Cache-Aside 架构。

但是呀，问题来了！Ru果同时有写请求和读请求，那可Neng会出现一个“并发回填”的情况。也就是读请求读取到了旧的数据，然后又把旧的数据写回缓存，导致缓存里的数据不一致。

这就像你删好友和踢群一样，有时候删好友时勾选将我从TA的列表里删除。这里的“删除”其实也包含着“延迟”的意思。咱们要用“等一等”来覆盖并发读回填旧值的时间窗口。

你kan啊，单单一个“删除缓存”的操作容易出现问题。Ru果同时有写和读操作，那么读操作可Neng会读取到旧的数据，然后把这个旧的数据写回缓存。这样一来你的缓存就变得脏了。

所以呢，为了避免这种麻烦，“延迟双删”就派上用场了。

咱来一步一步kankan：

先删除缓存线程Ageng新数据库后会立即删除缓存中的对应数据。

geng新数据库线程Ageng新数据库中的数据。

等待一段时间这是关键！线程B会等待一段时间，让并发的读请求dou完成。这段时间里“等一等”，让所有并发读取旧数据并回填新的数据的过程dou结束了。

删除缓存线程A在等待一段时间后再删除一次缓存中的对应数据——这次是把可Neng回填的旧值清掉！

这可是个难点啊！怎么才Neng选一个合适的延迟时间呢？定太短没啥效果，定太长又会影响性Neng。

import timedef update_with_delayed_double_deletion:    # 第一次删缓存    redis.delete        # geng新数据库    db.update        # 延迟一段时间    time.sleep  # 500ms，根据业务调整        # 第二次删缓存    redis.delete

优点缺点

实现简单

延迟等待会阻塞写请求

Neng有效降低缓存不一致概率

延迟时间不好精确估算

兼容现有 Cache-Aside 架构

极端高并发下仍可Neng有小概率不一致

读多写少 写操作不频繁，延迟等待的开销可接受

允许秒级Zui终一致 不要求实时强一致

无主从或主从延迟可控 延迟时间Neng估算得准

延迟双删 = "先删缓存 → geng新DB → 等一会儿 → 再删一次" ，用"等一等"来覆盖并发读回填旧值的时间窗口。

. 先删除缓存. geng新数据库. 休眠/等待一段时间. 
删除缓存

用代码表示：

删好友和踢群,有时也指删好友时勾选将我从TA的列表里删除 然后延迟一段时间 删除缓存中的数据,......

延迟时间 ≈ 主从同步延迟 + 业务读操作耗时 + 冗余缓冲

主从同步延迟Ru果有主从架构，通常 100ms~500ms

业务读操作耗时查询DB + 序列化 + 网络往返

冗余缓冲再加 ~200ms 保险

优点缺点实现简单延时等待会阻塞写请求有效降低了与Cache相关的冲突难以准确估算延时兼容现有Cache-Aside架构在高并发情况下仍然存在小概率的不一致性

读多写少: 写操作频率低,延时开销Ke以接受.

允许Zui终一致性: 不需要实时强一致性保证.                           不允许要求即时结果 . </li> </ul>

"先删除 cache -> geng新 DB -> 等一等 -> 再删除一次"，目的是通过 "等一下" 来覆盖 concurrent read 回填 old 数据的时间窗口.

九、细致分析 9.1 单次删除问题场景分析 9.1.1 时间点

时间点  线程A              线程B  t1    geng新数据库  t2                            查询数据库 → 得到旧值  t3    删除缓存  t4                            将旧值写入缓存  ← 缓存变脏！

9.1.2 问题分析 9.1.2.1 主从同步 9.1.2.2 查询结果 9.1.2.3 数据写入 9.2 geng高级的应用场景与优化策略 9.2 利用消息队列或者任务队列进行二次削除

import timedef updatewithretry:    #第一次削除+geng新DB        redis.       db.          #延时异步执行第二次削除      def delayed_delete:          time.          try:              redis.          except Exception:              #失败放入重试队列     retryQueue.   threading..start

9.3 关于错误处理与容错机制

即使在Zui新的方案中引入重试机制来解决二次削除失败的问题,也依然存在一定的风险。 因为网络不稳定或者服务器故障dou可Neng导致重复的处理失败。 因此需要geng加精细地设计容错机制, 例如使用幂等的操作或者加入超时机制等等。 但是这些dou需要额外的成本并且增加系统的复杂性。 因此应该谨慎使用。

---