缓存和数据库一致性问题

引入缓存提高性能

业务起步阶段，流量非常小，无论是读请求还是写请求，直接操作数据库即可

项目架构模型是这样子的：

随着业务量的增长，项目的请求量越来越大，这时如果每次都从数据库中读数据，那肯定会有性能问题。

这个阶段通常的做法是，引入缓存来提高读性能，架构模型就变成了这样：

缓存中间件的首选，肯定是 Redis，不仅性能高，还提供了很多友好的数据类型，可以很好地满足我们的业务需求。

但是引入缓存之后，我们会面临一个问题：之前数据只存在数据库中，现在要放到缓存中读取，具体要怎么存呢？

最简单直接的方案是「全量数据刷到缓存中」：

• 数据库的数据，全量刷入缓存（不设置失效时间）
• 写请求只更新数据库，不更新缓存
• 启动一个定时任务，定时把数据库的数据，更新到缓存中

优点：

​ 所有请求都可以直接命中缓存，不需要再查数据库，性能非常高

缺点：

• 缓存利用率低

  不经常访问的数据，还留在缓存中

• 数据不一致

  因为是定时刷新缓存，缓存和数据库存在不一致（取决于定时任务的执行频率）

所以，这种方案适合业务体量小，且对数据一致性要求不高的业务场景

那么我们思考一下，当我们的业务体量很大的时候，该如何解决上述的两个问题呢？

缓存利用率和一致性的问题

先来针对第一个问题，如何提高缓存利用率？

想要缓存利用率最大化，我们很容易想到的方案是，缓存中只保留最近访问的热数据

优化方案：

• 写请求依旧只写数据库
• 读请求先读缓存，如果缓存不存在，则从数据库读取，并重建缓存
• 同时，写入缓存中的数据，都设置失效时间

这样一来，缓存中不经常访问的数据，随着时间的推移，都会逐渐过期淘汰掉，最终缓存中保留的，都是经常被访问的热数据，缓存利用率得到最大化

返观关于数据一致性的问题

想要保证缓存和数据库实时一致，那就不能再用定时任务刷新缓存了。

所以当数据发生更新时，我们不仅要操作数据库，还要一并操作缓存。具体就是，修改一条数据的时候，不仅要更新数据库，还要连带着缓存一起更新。

细心的你又会想到，两个操作的先后问题，那应对的方案就有两种：

1. 先更新缓存，后更新数据库
2. 先更新数据库，后更新缓存

暂且先不考虑并发问题，正常情况下，无论谁先谁后，都可以让两者保持一致，但是现在我们需要考虑其中的异常情况。

因为操作分为两步，那么很有可以存在一步成功，一步失败的情况发生

接下来我们来一起思考，逐步分析

先更新缓存，后更新数据库

如果缓存更新成功了，但数据库更新失败，那么此时缓存中是最新值，数据库的依然是旧值

虽然此时读请求是可以命中缓存，拿到正确的值，但是，一旦缓存过期失效，就会从数据库中读到旧值，重建的缓存也是这个旧值

用户就会发现之前修改成功的值又变回去了，对业务造成了影响

先更新数据库，后更新缓存

如果数据库更新成功了，但缓存更新失败了，那么此时数据库中的是最新值，缓存中的是旧值

之后的读请求读到的都是就数据，只有当缓存失效后，重建缓存，才能从数据库中得到正确的值

这时用户会发现，自己刚刚修改了数据，但是却看不到变更，一段时间过后，数据才变更过来，业务也会有影响

由此可见，无论谁先谁后，但凡后者发生异常，就会对业务造成影响。那么如何解决呢？

我们继续分析，除了操作失败问题，还有什么场景会影响数据一致性？

提示：并发问题

并发引发的一致性问题

假设我们采用 先更新数据库，再更新缓存 的方案，并且两步都可以成功执行的前提下，如果存在并发，情况会是怎样？

有线程 A 和线程 B 两个线程，需要更新同一条数据，会发生这样的场景：

1. 线程 A 更新数据库（X = 1）
2. 线程 B 更新数据库（X = 2）
3. 线程 B 更新缓存（X = 2）
4. 线程 A 更新缓存（X = 1）

最终 X 的值在缓存中是 1，在数据库中是 2，不一致

也就是说，A 虽然先于 B 发生，但 B 操作数据库和缓存的时间，却要比 A 的时间短，执行时序发生错乱，最终这条数据结果是不符合预期的

同样地，采用「先更新缓存，再更新数据库」的方案，也会有类似问题，这里不再详述。

除此之外，我们从缓存利用率的角度来评估这个方案，也是不推荐的

这是因为每次数据发生变更，都无脑更新缓存，但是缓存中的数据不一定会被马上读取，这就会导致缓存中可能存放了很多不经常访问的数据，浪费缓存资源

而且很多情况下，写到缓存中的值，并不是于数据库的值一一对应的，很有可能是先查询数据库，再经过一系列计算得出来的一个值，才把这个值写到缓存中。

由此可见，这种更新数据库+更新缓存的方案，不仅缓存利用率不高，还会造成机器性能浪费

所以此时我们需要考虑另外的方案：删除缓存

删除缓存可以保证一致性吗？

删除缓存对应的方案也有两种：

1. 先删除缓存，后更新数据库
2. 先更新数据库，后删除缓存

经理前面的分析我们已经得知，但凡后者操作失败，都会导致数据不一致

这里我们重点来看并发问题

先删除缓存，后更新数据库

如果有两个线程要并发读写数据，可能会发生以下场景：

1. 线程 A 要更新 X = 2（原值 X = 1）
2. 线程 A 先删除缓存
3. 线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
4. 线程 A 将新值写入数据库（X = 2）
5. 线程 B 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是旧值，在数据库中的是新值，发生不一致

可见，先删除缓存，后更新数据库，当发生读+写并发时，还是存在数据不一致的情况

先更新数据库，后删除缓存

依旧是两个线程并发读写数据：

1. 缓存中 X 不存在（数据库 X = 1）
2. 线程 A 读取数据库，得到旧值（X = 1）
3. 线程 B 更新数据库（X = 2)
4. 线程 B 删除缓存
5. 线程 A 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。

这种情况理论上来说是可能发生的，但是实际上概率极低

因为它必须满足三个条件：

1. 缓存刚好失效
2. 读请求+写请求并发
3. 更新数据库+删除缓存的时间要比读数据库+写缓存时间短

条件 3 发生的概率是非常低的

因为数据库一般都会加锁，所以写数据库的时间一般比读数据库的时间长

这么来看，先更新数据库+再删除缓存的方案，是可以保证数据一致性的

解决了并发问题，我们继续来看之前提到的问题，第二部执行失败导致数据库不一致的问题

如何保证两步都执行成功？

前面提到过，无论是哪种方案，只要第二步失败，就会导致数据库和缓存的不一致

保证第二部成功执行，就是解决问题的关键

最简单的解决方法：重试

无论是操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地补偿

但并不是无脑重试，还需要考虑：

• 立即重试很大概率还会失败
• 重试次数设置多少合理
• 重试会一直占用这个线程资源，无法服务其他客户端请求

更加完善的方案：异步重试

其实就是把重试请求写到消息队列中，然后由专门的消费者来重试，直到成功

或者更加直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直到放到消息队列中，由消费者来操作缓存

到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多的维护成本，这样做值得吗？

这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了。

所以，这里我们必须把重试或第二步操作放到另一个「服务」中，这个服务用「消息队列」最为合适。这是因为消息队列的特性，正好符合我们的需求：

• 消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
• 消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的场景）

至于写队列失败和消息队列的维护成本问题：

• 写队列失败：操作缓存和写消息队列，「同时失败」的概率其实是很小的
• 维护成本：我们项目中一般都会用到消息队列，维护成本并没有新增很多

此时的架构模型：

如果确实不想应用中去写消息队列，是否有更简单的方案，此时又怎么保证一致性呢？

最近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存

我们的业务应用在修改数据时，只需修改数据库，无需操作缓存

那什么时候操作缓存呢？这就和数据库的变更日志有关

当一条数据发生修改时，就会产生一条变更日志（Binlog）我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存

订阅日志变更的日志，目前也有了比较成熟的开源中间件，例如阿里的 canal，使用这种方案的有点在于：

• 无需考虑写消息队列失败情况：只要写 Mysql 成功，Binlog 肯定会有日志
• 自动投递到下有队列：canal 自动把Binlog 投递给下有的消息队列

当然，与此同时，我们需要投入精力去维护 canal 的高可用和稳定性

如果你有留意观察很多数据库的特性，就会发现其实很多数据库都逐渐开始提供「订阅变更日志」的功能了，相信不远的将来，我们就不用通过中间件来拉取日志，自己写程序就可以订阅变更日志了，这样可以进一步简化流程。

至此，我们可以得出结论，想要保证数据库和缓存一致性，推荐采用「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做。

主从库延迟和延迟双删问题

到这里，还有两个问题，我们没有重点分析过。

第一个问题，还记得前面讲到的先删除缓存，再更新数据库方案，导致不一致的场景么？

2 个线程要并发「读写」数据，可能会发生以下场景：

1. 线程 A 要更新 X = 2（原值 X = 1）
2. 线程 A 先删除缓存
3. 线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
4. 线程 A 将新值写入数据库（X = 2）
5. 线程 B 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。

第二个问题：是关于「读写分离 + 主从复制延迟」情况下，缓存和数据库一致性的问题。

在「先更新数据库，再删除缓存」方案下，「读写分离 + 主从库延迟」其实也会导致不一致：

1. 线程 A 更新主库 X = 2（原值 X = 1）
2. 线程 A 删除缓存
3. 线程 B 查询缓存，没有命中，查询「从库」得到旧值（从库 X = 1）
4. 从库「同步」完成（主从库 X = 2）
5. 线程 B 将「旧值」写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在主从库中是 2（新值），也发生不一致。

以上两种情况，缓存都被回种了旧值

最有效的办法就是 把缓存删掉

但是，不能立即删除，而是需要延迟删，这就是业界给出的方案：缓存延迟双删策略

按照延时双删策略，这两个问题的解决方案

解决第一个问题：在线程 A 删除缓存、更新完数据库之后，先休眠一会，再删除一次缓存

解决第二个问题：线程 A 可以生成一条延时信息，写到消息队列中，消费者延时删除缓存

两个方案的目的都是把缓存清掉，这样一来，下次就可以重数据库读取懂啊最新值，写入缓存

但问题来了，延迟删除缓存，延迟时间到底设置要多久？

• 问题1：延迟时间要大于「主从复制」的延迟时间
• 问题2：延迟时间要大于线程 B 读取数据库 + 写入缓存的时间

但是，这个时间在分布式和高并发场景下，其实是很难评估的。

很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。

采用这种方案，也只是尽可能保证一致性而已，极端情况下，还是有可能发生不一致。

所以实际使用中，我还是建议你采用「先更新数据库，再删除缓存」的方案，同时，要尽可能地保证「主从复制」不要有太大延迟，降低出问题的概率。

可以做到强一致吗？

这些方案还是不够完美，想做到真正意义上的强一致，很难

最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。

相反，我们可以换一个角度思考，我们引入缓存的目的是什么？

性能

一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求。

而且，就拿我们前面讲到的方案来说，当操作数据库和缓存完成之前，只要有其它请求可以进来，都有可能查到「中间状态」的数据。

所以如果非要追求强一致，那必须要求所有更新操作完成之前期间，不能有「任何请求」进来。

虽然我们可以通过加「分布锁」的方式来实现，但我们要付出的代价，很可能会超过引入缓存带来的性能提升。

所以，既然决定使用缓存，就必须容忍「一致性」问题，我们只能尽可能地去降低问题出现的概率。

同时我们也要知道，缓存都是有「失效时间」的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到最终一致。