Redis 使用Redis作为缓存，你真的考虑周全了吗？

谁践踏了优雅 2023-07-13 08:12 5阅读 0赞

# **前言** #

## **看到标题，可能小伙伴们会虎躯一震？**   嗯？   难道不应该使用Redis做缓存？ ##

## **答**： ##

## 不是你想的那样， ##

## 只是说，有几种情况，使用缓存我们需要了解考虑周全，选择正确的使用姿势。 ##

# **正文** #

### 好，我们进入该篇正题。 ###

***（一定要耐心结合我举例进行推演才能更加明白）***

我们既然选择了缓存，用redis存储缓存数据，必然是为了一个字，快。

就是想避免每次都访问数据库，能直接从缓存很快地拿出数据。

那么，大家在使用缓存的时候，会不会冥冥之中有对数据的准确性有过怀疑？ 对数据的时效性有过质疑？

**先列出，我们使用缓存的时候，会选择到的方式  四种**：

* （对于读操作，不用多言，那肯定是先读缓存，没有才从数据库获取。）*

*所以着重针对 写 操作 分析：*

第一种：

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

第二种：

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

第三种：

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

第四种：

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

##  逐一分析可能存在的问题 ##

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

存在问题1：

\-假设原来的值是500，先需要更新数据库的值变为1000， 成功了； 数据库的值为 1000；  
\-接着就会去更新缓存， 因为未知原因（网络等），导致更新失败； 缓存的值为 500不变。

\-那么读操作来了，先去缓存里面读数据，拿到的是 500， 无疑这是读到了**旧的数据**。

存在问题2：

**高并发场景时**，

\-假设原来的值是500，线程A更新数据库的值变为1000， 成功了； 数据库的值为 1000，接着就准备去更新缓存；

\-这时候，线程B来了，更新数据库的值变成200，接着就会去更新缓存；

\-因为网络的波动原因，B线程从后追上A线程， 率先更新了缓存的值，200； 此时缓存数据为200，非常正确。  
\-但紧接着，A线程缓过神来了，把缓存的值更新为了1000；

\-这时候，读操作来了，先读缓存，拿出来的值是1000，实际上应该是200，无疑这是读到了**错误数据**。

** 特别是写操作远大于读操作的项目场景， 这个还是很让人头疼的。**

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*懒人手动分割线\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

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

存在问题1：

\-假设原来的值是500，先需要更新缓存的值1000，成功了；缓存的值为1000；

\-接着就会去更新数据库， 因为未知原因（网络等），导致更新失败； 数据库的值为 500不变。

\-那么读操作来了，先去缓存里面读数据，拿到的是1000，可是数据库是500 。无疑这是读到了**错误数据**。

因为数据库更新不成功，缓存的数据应该也是不可以成功的。

存在问题2：

**高并发场景时**，

\-假设原来的值是500，线程A更新缓存的值变为1000，成功了；缓存的值为1000，，接着就准备去更新数据库；

\-这时候，线程B来了，更新更新缓存的值变成200，接着就会去更新数据库；

\-因为网络的波动原因，B线程从后追上A线程， 率先更新了数据库，200； 此时数据库数据为200。

-但紧接着，A线程缓过神来了，把数据库的值的值更新为了1000；

\-此时此刻，缓存数据是200，数据库数据是1000； 读操作来了，无疑这是读到了**错误数据**。

** 特别是写操作远大于读操作的项目场景， 这个还是很让人头疼的。**

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*懒人手动分割线\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

**看完上面2种情况，明显我们都知道，在高并发切写远多于读的时候，这两种情况都是很不可取的；**

**所以，就衍生出一个策略，在写操作的时候，不要去更新缓存，而且选择直接删除缓存。**

**更新缓存的操作，放在读操作进行；**

**读操作为：如果缓存有，读出；无，读出数据库的值，更新缓存。**

*** ps：当然读多写少的场景，上面2种方式也都还行。***

### **那就是 先删除缓存，再更新数据库  还是  先更新数据库，再删除缓存 这两个之间的抉择了。** ###

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

存在问题1：

\-假设原来缓存的值是500，数据库也是500；

\-先删除缓存， 因为未知原因（网络等），导致更新数据库时失败；

\-这时候，读操作来了，无影响，因为缓存没有，直接读数据库，正常；

\-这时候，写操作又来，无影响，缓存已经没有，继续更新数据库，正常；

这么一看，好像还蛮不错！

然而并不然！因为删缓存的策略代替更新缓存，上面讲到了是把缓存写入操作给了读操作进行。

继续看高并发的场景。

存在问题2：

**高并发场景时**，

\-假设原来缓存的值是500，数据库也是500；

\-线程A删掉了缓存，正准备去更新数据库，把值变成1000；

\-因为网络的波动原因线程A懵了，呆滞了；

\-这时候，线程B来了，线程B进行的读操作，查询，一看缓存没数据了（被线程A删掉了），接着就去读数据库，值为500；

\-线程B读完数据库的值500后，紧接着把数据写入缓存！ 此时缓存的数据是500；

\-此时线程A缓过神来，更新数据库值为1000。

\-此后，缓存的数据是500，数据库数据是1000， 无疑，又是存在**错误数据**！

**特别是读操作远大于写操作的项目场景， 这个好像又开始很让人头疼了。**

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*懒人手动分割线\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

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

存在问题1：

-假设原来缓存的值是500，数据库也是500；更新数据库值变成1000，成功了；

\-删除缓存失败，还是500；

\-这时候，读操作来了，读出缓存的数据500，无疑这是读到了**错误数据**；

存在问题2：

**高并发场景时**，

-假设原来缓存的值是500，数据库也是500；

\-线程A来了，更新数据库的值为1000，删除了缓存；

\-这时候，线程B也来了，线程B是一个读操作，发现缓存没有，读取了数据库的值1000，然后准备写入缓存；

\-因为网络的波动原因线程B懵了，呆滞了；

\-这时候线程C来了，线程C更新数据库值为2000，然后很利索删除缓存（这时候其实本来就没缓存）；

\-然后线程B缓过神来了，很利索把值1000写入了缓存。

\-这时候，其他读操作来了，读出换成的数据1000，而数据库实际是2000，无疑这是读到了**错误数据**；

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*懒人手动分割线\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

## ？？？    ##

##  嗯？什么？ ##

### **一轮下来把四种姿势都看完了，发现都不好？？？** ###

### ** 那咱们总得选一种用缓存啊？** ###

### 如果项目场景是**读多写少    ：** ###

**而且是并发不考虑的场景，其实更新缓存的方式也是能用一用，不过还是建议用下面的删除缓存的方式。**

### 如果项目场景是写**多读少    ：**  ###

其实这时候,使用删除缓存的策略显然好很多。

## **先删除****缓存****，再更新****数据库   ****分析：** ##

那么选择 如果 **先删除****缓存****，再更新****数据库** **，上面提到了，就是怕高并发的场景，导致数据库的数据是正常的，而缓存的数据是不对的。**  
既然是因为这个缓存数据是脏的，那么针对这个问题，于是乎有了 **延时双删除策略：**

**先删除 缓存 ，再更新数据库， 延时后再删除缓存 **

从字面上其实已经能知道，就是补一刀把后续的脏缓存数据删掉，这么具体的延时时间是多少，就得根据具体项目业务时间去衡量了。

## **先****更新****数据库****，再删除****缓存   分析：** ##

那么选择 如果 **先****更新****数据库** **，再****删除****缓存** **，其实这个方式是 一个国外比较推荐的使用缓存方式** ： Cache-Aside pattern

上面提到了，这种方式在高并发的场景也是存在问题的。

但是为什么外国人这么推荐这种方式呢？

回顾这种方式，在高并发的情形，出现问题的原因是 读操作的后面写入数据到缓存的环节上。  
但是读操作实际上肯定比写操作快得多，所以发生上边描述的出现脏数据的场景的概率也是比较小。  
每次读操作的时候最后会将数据库数据写到缓存， 而写操作最后会删除调缓存。  
我们想象下，读非常快，写稍微慢的场景， 这样就算有读操作写入的旧的缓存数据，也会被慢写操作的删掉。  
这样碰巧发生出现不一致数据的概率就会小很多，这也是外国人推荐的原因。

最后来一个个人的总结：

并发稍微低，那么我们可以用   **先删除****缓存****，再更新****数据库  再配上****延时双删除策略。**  
  
并发稍微高，那么我们可以用 Cache-Aside pattern ，  **先****更新****数据库** **，再****删除****缓存 。**

其实看完这篇的，大家都知道，脏数据 在不适用 分布式锁 或者 其他能保证数据顺序的方法的情况下，都是存在的。  
只不过是出现这种脏数据的概率以及严重性，是否是项目的业务需求可以接收。

对于该篇文章分析存在的问题，都是有额外的补救方法，如加锁，重试，消息队列等等

好，该篇介绍就到此吧。