Redis：延迟双删的适用边界与落地细节

Tue, 16 Jun 2026 17:04:23 +0800

延迟双删不是新概念，但线上一出缓存脏读，我曾经在项目中把它当成标准答案直接套进去。结果通常是代码写了两次删除，问题却没真正收住。

这篇就聚焦一个知识点：延迟双删到底解决什么问题，为什么它只能改善最终一致概率，以及在 .NET 服务里怎么把第二次删除做得更稳一点。

1. 问题背景：数据库已经更新，为什么缓存里还是旧值

聊一个高频场景：商品详情页读 Redis，后台商品编辑写数据库。读流量远大于写流量，最常见的缓存策略是 Cache Aside。

我的更新代码长这样：先更新数据库，再删除缓存。平时看起来没什么问题，但高并发下还是会偶发脏数据。业务侧看到的现象一般是：管理后台已经改价成功，前台用户短时间内还能查到旧价格。

关键不在“删没删缓存”，而在并发时序。

一个典型过程是这样的：

线程 A 更新数据库中的商品价格
线程 A 删除 Redis 中的商品缓存
线程 B 正好在这个空档读缓存未命中，开始查数据库
线程 B 读到的仍然是旧值，或者读到了事务提交前的旧快照
线程 B 把旧值重新写回 Redis

这时候数据库是新值，缓存却又变回旧值了。问题根因不是删除动作本身，而是删除之后，旧数据又被别的请求回填进缓存。

如果只看文字，这个并发窗口不算直观。把它画成时序图会更清楚：

sequenceDiagram
    autonumber
    participant A as 写线程A
    participant R as Redis
    participant D as Database
    participant B as 读线程B

    A->>D: 更新商品价格为新值
    A->>R: 删除商品缓存
    B->>R: 读取商品缓存
    R-->>B: 未命中
    B->>D: 查询商品数据
    D-->>B: 返回旧值或旧快照
    B->>R: 回填旧值到缓存
    B-->>B: 后续请求命中旧缓存

这张图里最关键的不是“删缓存”这一步，而是删完之后到下一次稳定回填新值之前，中间存在一个旧值重新进入 Redis 的窗口。延迟双删补的就是这个窗口。

Redis on Coding with Denglei

Redis：延迟双删的适用边界与落地细节

1. 问题背景：数据库已经更新，为什么缓存里还是旧值