Redis 缓存更新策略：双写、删除缓存、延迟双删各自解决什么问题

缓存一致性最容易让人纠结的地方在于：

• 数据库和缓存到底谁先改
• 改完缓存为什么还会脏
• 为什么有些系统用双写，有些系统只删缓存

先说结论

最常见的几种策略可以先这样理解：

• 双写：写数据库再写缓存
• 删除缓存：写数据库后删缓存
• 延迟双删：删缓存后再补一次延迟删除

在绝大多数普通业务里，更常见也更实用的通常仍是：

• 写数据库后删除缓存

一、为什么缓存更新会难

因为数据库和缓存本来就是两个系统。

当一次写操作发生时，你很难让它们像单机内存赋值那样天然同步。

所以缓存一致性讨论的核心不是“绝对一致”，而是：

• 在业务可接受范围内，怎么把脏数据窗口尽量缩小

二、双写策略在解决什么

思路是：

1. 先写数据库
2. 再写缓存

优点：

• 读请求可能更快拿到新值

问题：

• 并发时两个写可能交错
• 一次失败时补偿更复杂

所以双写看起来直接，但并发下边界并不轻。

三、删除缓存为什么更常见

思路是：

1. 先写数据库
2. 删除缓存

这样做的价值在于：

• 下次读时由读请求触发缓存重建

相比双写，它的一个好处是：

• 缓存值不会在写路径上被多次主动覆盖

所以很多业务系统里，这是一种更稳的默认方案。

四、延迟双删为什么会出现

它通常是为了应对某些并发窗口：

1. 更新前先删缓存
2. 写数据库
3. 延迟一小段时间再删一次缓存

这个思路的目标是：

• 尽量减少并发读把旧值重新写回缓存的概率

但它不是银弹，因为：

• 延迟时间本身不好拍脑袋
• 场景复杂时仍有边界

五、怎么更实际地选

1. 一般业务数据

优先考虑：

• 写数据库后删缓存

2. 高一致性但读写不算特别极端

可以在删除缓存基础上，再结合：

• 过期时间
• 热点控制
• 重建锁

3. 强一致要求非常高

这时很多数据其实就不该优先依赖缓存，而应：

• 先查数据库
• 或引入更重的一致性链路

一句话总结

缓存更新策略没有绝对完美答案，但在大多数业务里，“写数据库后删缓存”仍是最实用、最容易长期维护的基础方案。

关键不是追求理论绝对一致，而是根据业务容忍度控制好脏数据窗口和复杂度。