按理说，

会导致永久性的脏数据的。我们一起来看一下怎么回事。

常见的缓存更新套路

• 从更新数据库来看，把新值写进数据库；
• 说到删缓存。把当前缓存里的那条旧数据清掉，下一次读请求会从数据库重新加载；
• 给缓存加个过期时间：这是给「删不干净」做兜底的。删的动作可能因为网络抖动没成功，或者刚删完就被并发的读请求把旧值又塞回了缓存。过期时间保证脏数据最多活一阵子，到期自动失效。

就算这三步每一步都做对了缓存和数据库还是可能不一致。有一种场景下脏数据会一直存在缓存里使用者怎么刷都是旧值，只能等过期时间到了才消失。

这是一个竞态，Cache‑Aside这种方式的方法太短了短到让人觉得不会出问题。下文我们来讨论一下这个问题。

关于缓存一致性

聊缓存之前得先约定好我们在聊什么。按理说，

痛点：

• 你是否担心“命中率”低导致业务直接落回数据库？
• 你是否担心“永远不可见”旧值会让使用者持续看到错误信息？

用这个定义的话，可以来看两个事情。

1. 第一个： 如果某键不存在于缓存里就谈不上错，但这也代表着该键完全没有命中。谈一致性不能脱离命中率，否则就没有意义。
2. 第二个： 定义里有个关键词是「最终」。也就是允许短暂的不一致，但不允许永久的不一致。短暂的旧值业务上通常可以接受，使用者刷新一下页面就正常了；永久的旧值则是故障，让使用者无论刷多久都看到错误的数据。

痛点再补充：

• "永远旧" 的情况往往导致业务投诉、退单甚至品牌声誉受损，你需要尽快解决这一风险。
• "短暂" 的不一致虽然技术上可接受。但若业务对实时性要求极高，即便很短，也可能造成“抢不到库存”的误判。

有人会问。为什么不直接做强一致，让缓存任何时刻都和数据库相同？因为...

Cache‑Aside模式下的永久不一致问题

读→写→回填竞态示例

1. A 请求读未命中；其实，B 请求写并删除对应键；C A 回填旧值到 cache —— 此时 cache 已经出现长期脏数据。

四种写法怎么选？不过，

• 痛点： 你是否担心写操作时可能因为网络抖动或并发导致 cache 状态无法同步？

删除失败怎么办？

把失效逻辑挪到 binlog 订阅里更安全吗？

Facebook 用租约解决回填竞态

小结与实践建议