到底是先更新数据库还是先更新缓存？

一时失言乱红尘 2021-09-07 06:19 343阅读 0赞

大家好，我是冰河~~

最近小伙伴最近都在问我，在系统中引入缓存后，当向数据库中写入数据时，是先写数据库还是先写缓存呢？先写数据库和先写缓存有什么区别吗？今天，我们就一起来聊聊这个话题。

从本质上讲，无论是先写数据库还是先写缓存，都是为了保证数据库和缓存的数据一致，也就是我们常说的数据一致性。

随着互联网的高速发展，当今时代已然从IT时代进入到DT时代。互联网系统架构也已经由最初的单体架构转变为分布式、微服务架构模式。从数据体量上来看，各系统存储的数据量越来越大，数据的查询性能越来越低。此时，就需要我们不断的进行优化，一种常用的优化手段就是引入缓存。而引入缓存后，我们在向数据库插入数据时，到底是先更新数据库还是先更新缓存呢？

## 缓存的一般使用 ##

缓存，从本质上讲，是为了更好的协调两个速度差异比较大的组件而引入的一种中间缓存层。例如，如果需要将数据读入CPU进行计算处理，由于CPU的运算速度是非常快的，而磁盘的IO处理相比于CPU来说，慢了很多数量级，每次从磁盘读取数据，势会造成CPU长时间并且频繁等待磁盘IO。此时，我们就可以通过内存来缓和CPU和磁盘之间的速度差异。

![在这里插入图片描述][20210319005122469.png_pic_center]

从缓存的使用上来说，一般是按照如下的流程来使用缓存。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]  
我们也可以表示成如下的序列图。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 1]

在上面的使用示例中，我们只是简单的将数据放入了缓存，最多为缓存设置一个过期时间，到期后，缓存自然就会被清除，后续的请求由于在缓存中获取不到数据，又会从数据库中获取数据，将数据写入缓存。

但是在后续更新数据的操作中，是更新完数据库，接下来更新缓存还是删除缓存？又或者是先删除缓存，再更新数据库？

## 缓存更新策略 ##

从理论上来说，给缓存设置过期时间，其实是一中最终一致性的表现。这种方案下，可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。这也是一般情况下，使用的最多的一种方式。

### 先更新数据库再更新缓存 ###

其实，这种方案很多有经验的小伙伴是很反对的，为啥，我们来分析下。

**首先，这种方案会有线程安全的问题。**

例如，同时有线程A和线程B对数据进行更新操作，可能会出现下面的执行顺序。

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

此时就会出现数据库中的数据与缓存的数据不一致的情况，这是因为线程A先更新了数据库，可能因为网络等异常情况，线程B更新完数据库进而更新了缓存，当线程B更新完缓存后，线程A才更新缓存，这就导致了数据库数据与缓存数据的不一致。

**其次，这种方案也有其不适用的业务场景。**

首先一个业务场景就是数据库写多读少的场景，这种场景下采用先更新数据库再更新缓存的策略，就会导致缓存并未被读取就会被频繁的更新，极大的浪费了服务器的性能。

再一个业务场景就是数据库中的数据不是直接写入缓存的，而是需要大量的复杂运算，将运算结果写入缓存。如果这种场景下使用先更新数据库再更新缓存的策略，也会造成服务器资源的浪费。

### 先删除缓存再更新数据库 ###

先删除缓存再更新数据库的方案也存在着线程安全的问题，例如，线程A更新缓存，同时，线程B读取缓存的数据。可能会出现下面的执行顺序。

(1) 线程A删除缓存  
(2) 线程B查询缓存，发现缓存中没有想要的数据  
(3) 线程B查询数据库中的旧数据  
(4) 线程B将查询到的旧数据写入缓存  
(5) 线程A将新数据写入数据库

此时，就出现了数据库中的数据和缓存中的数据不一致的情况。如果删除缓存失败，也会出现数据库数据和缓存数据不一致的现象。

### 先更新数据库再删除缓存 ###

首先，这种方式也有极小的概率发生数据库数据和缓存数据不一致的情况，例如，线程A做查询操作，线程B执行更新操作，其执行的顺序如下所示。

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

如果上述顺序一旦发生，就会造成数据库中的数据和缓存中的数据不一致的情况发生。

但是，先更新数据库再删除缓存的策略发生数据库和缓存数据不一致的概率很低，原因就是：（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）执行。但是，往往数据库的读操作的速度远快于写操作，因此步骤（3）耗时比步骤（2）更短，这一场景很难出现。

如果删除缓存失败，也会出现数据库数据和缓存数据不一致的现象。

**这样说来，貌似三种方案都不安全呀，那我们该如何做呢？最终要的就是需要引入重试机制。**

## 推荐使用 ##

在实际的生产环境中，推荐 **使用先更新数据库再删除缓存** 的操作。那么，我们该如何解决这种策略下的问题呢？

有两种方案，一种是在程序逻辑中处理失败重试的操作；另外，借助于阿里巴巴开源的Canal。

### 手动失败重试 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 2]

流程如下所示  
（1）更新数据库数据；  
（2）删除缓存数据失败  
（3）将需要删除的key发送至消息队列  
（4）自己消费消息，获得需要删除的key  
（5）继续重试删除操作，直到成功

这种方案有一个缺点，对业务线代码造成大量的侵入。

### 同步数据库数据 ###

先来一张图，这种图从整体架构上解决了数据库数据和缓存数据不一致的情况。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 3]

流程如下图所示：  
（1）更新数据库数据  
（2）数据库将数据表数据的变更信息写入binlog日志当中  
（3）订阅程序获取所需要的数据以及key  
（4）程序逻辑中处理具体的业务逻辑，接收订阅binlog、发起删除缓存的请求。  
（5）尝试删除缓存操作，发现删除失败  
（6）将这些信息发送至消息队列  
（7）重新从消息队列中获得该数据，重试操作。

**好了，今天就到这儿吧，我是冰河，大家有啥问题可以在下方留言，也可以加我微信：sun\_shine\_lyz，我拉你进群，一起交流技术，一起进阶，一起牛逼~~**

[20210319005122469.png_pic_center]: /images/20210901/f04ac5674470490bac276db13c635704.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]: /images/20210901/0c23181b98304e11b64a695b4d36f8ee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210901/28381938a8de417d914567e8c1faa6a0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210901/92ea3cdf85f7426e8095973f6f1129f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20210901/45cd04a9ab4d4df5888026f429ed31a0.png