缓存与数据库的双写一致性

 

一、缓存读取

    缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。 

二、缓存更新

　　缓存的更新，主要有以下三种操作：

1、先更新数据库，再更新缓存

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

3、先删除缓存，再更新数据库

　　别问为什么没有先更新缓存，在更新数据库的玩法，问就不知道。。。。好吧，想象一下，缓存更新成功，数据更新失败的care，这个后果太灾难性了。。多线程的时候交叉更新也扛不住啊。。

2.1先更新数据库，再更新缓存

这套方案，也是大家是普遍反对的。有如下两点原因：

- 原因一（线程安全角度）

同时有请求A和请求B进行更新操作，也就是刚刚说的交叉更新，那么会出现

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

这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。

- 原因二（业务场景角度）

（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。

2.2先更新数据库，再删缓存

此为facebook采用方案。

但是此方案当原子性被破坏时，即更库成功，删除缓存失败，则会遇到缓存与数据库不一致的问题，

对此，可以用一下两个方案解决：

或者

 

 第二天中订阅程序，对mysql可使用canel。

当然，也存在以下可能，会存在问题：

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

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

2.3先删缓存，再更新数据库

当此方案并发比较高的时候，同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:

（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库

 对此，我们可以采用延时双删的策略，代码如下： 

        redis.delKey(key);
        db.updateData(data);
        Runnable runnable = () ->  redis.delKey(key);
        executor.schedule(runnable, 1, TimeUnit.SECONDS);

此处executor为ScheduledThreadPoolExecutor

当然，以上case出现的时候，第二次删除缓存是可能失败的。但这个概率已经很小，加上缓存本身有过期时间，所以当并发量不高的时候，也是一个可以接受的方案。

如果一定要解决这个问题，可采用上述2.2的两种方案保证删除缓存的成功。