Cache缓存为何引发数据不一致

Cache（缓存）引发数据不一致，本质上是因为：同一份数据在“数据源”和“缓存”中存在多份副本，而写操作无法在保证性能的前提下，瞬间、原子地让所有副本都保持一致。

下面从原因分类来讲清楚。

一、最本质的原因：读写分离 + 多副本

典型架构：

• 数据库（DB）：权威数据源
• Cache（如 Redis）：加速读副本

写请求 → DB
读请求 → Cache（可能命中旧数据）

只要：

• 写 DB 和写 Cache 不是原子的
• 或 Cache 有过期时间
• 或 Cache 被并发修改

就可能出现不一致。

二、常见引发不一致的具体场景

1️⃣ 先更新 DB，再删/更新 Cache 失败

典型错误顺序：

1. 更新数据库
2. 删除缓存（失败）

结果：

• DB 是新数据
• Cache 仍是旧数据
• 后续读请求命中旧缓存

✅ 即使使用「Cache Aside」模式，第二步失败也会导致不一致。

2️⃣ 并发读写导致脏数据

场景：

线程A：读 cache miss → 读 DB（旧）
线程B：更新 DB → 删 cache
线程A：把旧数据写回 cache

结果：

• Cache 被旧数据“回种”
• 长期不一致

这是经典并发坑。

3️⃣ 缓存过期（TTL）导致的延迟不一致

即使逻辑正确：

• Cache 有 TTL
• 在过期前，读到的都是旧值

这是可接受的最终一致，但不是强一致。

4️⃣ 双写不一致（同时写 DB + Cache）

很多人会：

写 DB
写 Cache

问题：

• 写 DB 成功，写 Cache 失败
• 或并发下顺序错乱

比“删缓存”更容易出错。

5️⃣ 主从复制延迟（DB 层引入）

即使 Cache 正确：

写主库
读从库（还没同步）
写缓存

Cache 里也可能是旧数据。

6️⃣ 批量 / 异步更新遗漏

例如：

• 定时任务批量更新 DB
• 忘记同步失效 Cache
• MQ 异步更新失败无重试

三、为什么不能“彻底解决”？

因为：

• 强一致 ≠ 高性能
• Cache 的存在本身就是牺牲一致性换性能

CAP 视角：

• DB：偏一致性
• Cache：偏可用性 & 性能

四、常见“缓解方案”（不是完全消除）

✅ Cache Aside（推荐）

• 读：miss 才查 DB 并回种
• 写：更新 DB + 删 Cache

✅ 延迟双删

删缓存 → 更新DB → 延迟再删

✅ 设置较短 TTL（兜底）

✅ 用 MQ 保证最终一致

✅ 读写走同一数据源（如只读 Cache，不回种）

五、一句话总结

Cache 引发数据不一致，是因为“缓存是副本”，而“副本永远可能落后于源头”。

如果你愿意，我可以：

• 画一张不一致时序图
• 结合 Redis + MySQL 具体讲
• 或对比 强一致 vs 最终一致 的取舍