K：缓存数据库双写数据一致性方案

Posted 2020-11-26 mystringisnotnull

对于缓存和数据库双写，其存在着数据一致性的问题。对于数据一致性要求较高的业务场景，我们通常会选择使用分布式事务(2pc、paxos等)来保证缓存与数据库之间的数据强一致性，但分布式事务的复杂性与对资源的占用问题，使得该处理方式会造成系统性能的降低。对于数据一致性要求没那么高的业务场景，选择分布式事务的处理方式就会显得不是那么必要。为此，在一般情况下，对于数据一致性要求没那么高的业务场景，会选择使用cache-aside-pattern方案来保证缓存与数据库之间，数据的最终一致性，以下文章便是介绍并整理该cache-aside-pattern方案的内容。

对于缓存中的数据，我们提出三个目标：

1. 尽可能不将数据库中的旧数据存入缓存中
2. 允许缓存中的数据与数据库中的数据存在一小段时间的不一致
3. 缓存中的数据与数据库中的数据存在数据不一致的时间应尽量短

对于缓存与数据库的双写问题，无外乎“增删改查” 这四个过程，再考虑进并发的“读读，写写，读写”情况，所有可能的情况组合并不多。为此，我们可以采用穷举的方式对该方案进行说明。

查:

对于数据的查找，该方案的过程与cpu中查找数据的过程是一致的，其过程如下：

1. 先查找缓存中的数据，当命中缓存的时候返回数据，查找结束。
2. 当没有命中缓存时，查找数据库，对数据库中查找出的相关数据进行处理，之后将相关的数据存入缓存中，查找结束。

其示意图如下：

在考虑高并发查询的情况下，对于该处理过程，如下示意图所示。

当客户端1、客户端2、....、客户端n查询同一数据，且该数据不存在于缓存中时，所有的客户端请求都会去访问数据库，此时会出现缓存击穿的情况，对于缓存击穿的相关问题及解决方案，我们留到下一篇文章再进行讲解。

增：

对于新增数据的情况，我们将数据直接添加进数据库中，且不将新增的数据加载入缓存中，其过程如下示意图所示：

在考虑高并发之时，其过程如下示意图所示：

通过示意图，我们了解到，当采用该种方式新增数据时，在并发情况下，并未出现与我们的目标相违背的问题。

删：

当需要对数据进行删除时，我们有两种删除的方案可供选择。

第一种： 先删除缓存中的数据，再删除数据库中的数据

第二种： 先删除数据库中的数据，再删除缓存中的数据

我们对这两种方案分别进行分析：

先删缓存：

对于先删除缓存中的数据，后删除数据库中的数据这种方案，其示意图如下:

考虑进高并发的情况，当存在读请求和删除数据的请求并发时，由于网络的不可靠和延时问题，其可能出现如下示意图所示的情况：

通过示意图我们了解到，存在着缓存中缓存进已删除的旧数据的情况，这违背了我们提出的第一个目标。

那么，先删除数据库中的数据的情况呢？会出现这样的问题吗？我们接着分析。

先删数据库：

对于先删除数据库中的数据，后删除缓存中的数据这种方案，其示意图如下。

同样考虑进高并发的情况，当存在读请求和删除数据的请求并发时，其发生的情况如下示意图所示：

此时，并未出现与我们的目标相违背的问题。综上，我们在删除数据时，应选择先删除数据库中的数据再删除缓存中的数据的这一方案。

但是该方案仍存在着问题。我们再往下思考，当删除了缓存中的相关数据，此时来了大量读取该数据的请求。这时，就会导致“缓存穿透”问题的出现(该问题同样在下一篇文章中进行讲解)。

改：

当需要对数据进行变更的时候，我们有三种方案可供选择。

第一种： 先更新数据库，后更新缓存

第二种： 先删除缓存，后更新数据库

第三种： 先更新数据库，后删除缓存

我们对这三种方案逐一进行分析。

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

对于先更新数据库，后更新缓存这种方案，其示意图如下：

考虑高并发的情况，当存在两个更新操作的并发请求时，由于网络的延时问题，其可能会出现如下这种情况：

由上述示意图可知，当存在两个更新操作时，其有将数据库中的旧数据存入缓存中的情况，这违背了我们的第一个目标。那么，有没有办法解决呢？答案是有的，借助乐观锁的相关思想，我们可以给每个数据加上一个版本号，当数据要存入缓存时，比较一下数据的版本号即可。到目前为止，更新了数据库中的相关数据之后，再更新缓存中的数据这个方案看起来是可以的，但是这个方案存在着一个问题，就是需要去更新缓存中的数据，更新缓存中的数据这个操作会影响系统的性能。特别是在写多读少，且缓存的数据不是直接从数据库中存入，而是经过计算之后再进行缓存的业务场景中时，对系统性能造成的影响会更加明显。为此我们可以借助“懒加载”的思想，在更新数据之时，将缓存中的数据进行删除，等到需要用到的时候，才将数据加载进缓存中。下面我们将讨论在更新时删除缓存的两个可能的方案。

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

对于先删除缓存，后更新数据库的方案，其示意图如下：

考虑高并发的情况，当存在读请求和更新请求并发的情况，由于存在网络延时，其可能出现如下示意图中的情况：

由示意图中的情况可知，在读写并发的情况下，其存在着将数据库中的旧数据存入缓存中的问题。这违背了我们的第一个目标。

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

对于先更新数据库，后删除缓存的情况，其如下示意图所示：

考虑并发的情况，当存在读请求和更新请求并发，且此时缓存中的数据恰好失效时，再加上由于网络的延迟问题，则有可能会出现如下示意图所示的情况。

由示意图可知，当缓存中的数据恰好失效时，其是可能存在着缓存中存入数据库中的旧数据的可能性的。但是，发生这种情况的概率是比较低的，因为让该种情况出现的条件较为“苛刻”，需要恰好缓存中的数据失效，且要求“读操作”慢于“写操作”。但在通常情况下，“写操作”是慢于“读操作”的，因为写操作一般会涉及到数据库锁的相关操作。
综上，在对比了以上三种方案之后，对于数据更改的情况，我们采用先更新数据库，后删除缓存的方式。

---