但是只要使用到缓存,无论是本地内存做缓存还是使用 redis 做缓存,那么就会存在数据同步的问题,因为配置信息缓存在内存中,而内存时无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题。接下来就讨论一下关于保证缓存和数据库双写时的数据一致性。

1、先更新数据库,再删除缓存

如果删除缓存失败了,或者刚好有并发的请求导致产生了脏数据,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。

假设这会有两个请求,一个请求A做查询操作,一个请求B做更新操作,那么会有如下情形产生


(1)缓存刚好失效
(2)请求A查询数据库,得一个旧值
(3)请求B将新值写入数据库
(4)请求B删除缓存
(5)请求A将查到的旧值写入缓存

然而,发生这种情况的概率又有多少呢?


发生上述情况有一个先天性条件,就是步骤(3)的写数据库操作比步骤(2)的读数据库操作耗时更短,才有可能使得步骤(4)先于步骤(5)。可是,大家想想,数据库的读操作的速度远快于写操作的(不然做读写分离干嘛,做读写分离的意义就是因为读操作比较快,耗资源少),因此步骤(3)耗时比步骤(2)更短,这一情形很难出现。


假设,有人非要抬杠,有强迫症,一定要解决怎么办?


如何解决上述并发问题?


首先,给缓存设有效时间是一种方案。其次,采用策略里给出的异步延时删除策略,保证读请求完成以后,再进行删除操作。

另外,知名社交网站facebook也在论文《Scaling Memcache at Facebook》中提出,他们用的也是先更新数据库,再删缓存的策略。

2、先删除缓存,再更新数据库

先删除缓存,再更新数据库。如果数据库更新失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新到缓存中。

该方案会导致不一致的原因是。同时有一个请求A进行更新操作,另一个请求B进行查询操作。那么会出现如下情形:
(1)请求A进行写操作,删除缓存
(2)请求B查询发现缓存不存在
(3)请求B去数据库查询得到旧值
(4)请求B将旧值写入缓存
(5)请求A将新值写入数据库

上述情况就会导致不一致的情形出现。而且,如果不采用给缓存设置过期时间策略,该数据永远都是脏数据。

3、延时双删

写请求先删除缓存,再去更新数据库,(异步等待段时间)再删除缓存这种方案读取快速,但会出现短时间的脏数据。

4、指定等待

写请求先修改缓存为指定值,再去更新数据库,再更新缓存。读请求过来后,先读缓存,判断是指定值后进入循环状态,等待写请求更新缓存。如果循环超时就去数据库读取数据,更新缓存。

这种方案保证了读写的一致性,但是读请求会等待写操作的完成,降低了吞吐量

其实每一次的选择都需要我们对于我们的业务进行评估来选择,没有一种技术是对于所有业务都通用的。没有最好的,只有最适合我们的。

参考:https://blog.csdn.net/hukaijun/article/details/81010475