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

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

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

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

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

查:

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

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

其示意图如下:

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

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

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

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

增:

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

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

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

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

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

删:

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

第一种: 先删除缓存中的数据,再删除数据库中的数据

第二种: 先删除数据库中的数据,再删除缓存中的数据

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

先删缓存:

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

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

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

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

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

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

先删数据库:

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

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

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

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

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

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

改:

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

第一种: 先更新数据库,后更新缓存

第二种: 先删除缓存,后更新数据库

第三种: 先更新数据库,后删除缓存

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

先更新数据库,后更新缓存:

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

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

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

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

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

先删除缓存,后更新数据库:

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

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

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

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

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

先更新数据库,后删除缓存:

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

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

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

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

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


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

相关推荐