Redis数据一致性问题的三种解决方案

Myth丶恋晨 2023-10-14 10:20 55阅读 0赞

## 1、首先redis是什么 ##

Redis（Remote Dictionary Server )，是一个高性能的基于Key-Value结构存储的[NoSQL][]开源数据库。大部分公司采用Redis来实现分布式缓存，用来提高数据查询效率。

## 2、为什么会选Redis ##

在Web应用发展的初期，系统的访问和并发并不高，交互也比较少。但随着业务的扩大，访问量的提升，使得服务器负载和关系型数据库出现瓶颈，而导致瓶颈的源头，主要体现在磁盘IO上。随着互联网的进一步发展，对系统性能有了更高的要求，Redis的出现，解决了很多问题。至于我们为什么要选择Redis，我总结为以下六个原因：

1）、基于内存存储，可以降低对关系型数据库的访问频次，从而缓解数据库压力

2）、数据IO操作能支持更高级别的QPS，官方发布的指标是10W；

3）、提供了比较多的数据存储结构，比如string、list、hash、set、zset等等。

4）、采用单线程实现IO操作，避免了并发情况下的线程安全问题。

5）、可以支持数据持久化，避免因服务器故障导致数据丢失的问题

6）、Redis还提供了更多高级功能，比如分布式锁、分布式队列、排行榜、查找附近的人等功能，为更复杂的需求提供了成熟的解决方案。

## 3、 应用场景 ##

缓存，作为Key-Value形态的内存数据库，Redis 最先会被想到的应用场景便是作为数据缓存

分布式锁，分布式环境下对资源加锁

分布式共享数据，在多个应用之间共享

排行榜，自带排序的数据结构（zset）

消息队列，pub/sub功能也可以用作发布者 / 订阅者模型的消息

![format_png][]

## 4、redis用作缓存时 ##

### 4.1、作为缓存使用流程 ###

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

![format_png 1][]

### 4.2、数据性一致性问题 ###

例如我们使用Redis来作为缓存时，让请求先访问到Redis，而不是直接访问数据库。而在这种业务场景下，可能会出现缓存和数据库数据不一致性的问题。

在更新的时候，操作缓存和数据库无疑就是以下四种可能之一：

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

#### 4.2.1、先更新缓存，再更新数据库 ####

![format_png 2][]

**如果我成功更新了缓存，但是在执行更新数据库的那一步，服务器突然宕机了，那么此时，我的缓存中是最新的数据，而数据库中是旧的数据**。

脏数据就因此诞生了，并且如果我缓存的信息（是单独某张表的），而且这张表也在其他表的关联查询中，那么其他表关联查询出来的数据也是脏数据，结果就是直接会产生一系列的问题。

#### 4.2.2、先更新数据库，在更新缓存 ####

![format_png 3][]

只有等到缓存过期之后，才能访问到正确的信息。那么在缓存没过期的时间段内，所看到的都是脏数据。

以上两图中只要执行第二步时失败了，就必然会产生脏数据。

#### 4.2.3、先删除缓存，在更新数据库 ####

这种方式在没有高并发的情况下，是可能保持数据一致性的。

![format_png 4][]

如果只有第一步执行成功，而第二步失败，那么只有缓存中的数据被删除了，但是数据库没有更新，那么在下一次进行查询的时候，查不到缓存，只能重新查询数据库，构建缓存，这样其实也是相对做到了数据一致性。

但如果是处于**读写并发**的情况下，还是会出现数据不一致的情况：

![format_png 5][]

执行完成后，明显可以看出，1号用户所构建的缓存，并不是最新的数据，还是存在问题的

#### 4.2.4、先更新数据库，在删除缓存 ####

如果更新数据库成功了，而删除缓存失败了，那么数据库中就会是新数据，而缓存中是旧数据，数据就出现了不一致情况。

![format_png 6][]

和之前一样，**如果两段代码都执行成功，在并发情况下会是什么样呢**？

![format_png 7][]

还是会造成数据的不一致性。

但是此处**达成这个数据不一致性的条件明显会比起其他的方式更为困难** ：

*  时刻1：读请求的时候，缓存正好过期
 *  时刻2：读请求在写请求更新数据库之前查询数据库，
 *  时刻3：写请求，在更新数据库之后，要在读请求成功写入缓存前，先执行删除缓存操作。

这通常是很难做到的，因为在真正的并发开发中，更新数据库是需要加锁的，不然没一点安全性~

一定程度上来讲，这种方式还是解决了一定程度上的数据不一致性问题的。

### 4.3、总结 ###

以上四种方式无论选择那种方式，如果实在多服务或时并发的情况下，其实都是有可能产生数据不一致性的。

为了解决这个存在的问题有以下方式：

#### 4.3.1、延迟双删 ####

先进行缓存清除，再执行update，最后（延迟N秒）再执行缓存清除。进行两次删除，且中间需要延迟一段时间

![format_png 8][]

scss

复制代码

`public void write(String key,Object data){ // 延迟双删伪代码 deleteRedisCache(key); // 删除redis缓存 updateMysqlSql(obj); // 更新mysql Thread.sleep(100); // 延迟一段时间 deleteRedisCache(key); // 再次删除该key的缓存 }`

延迟双删的流程图：

![format_png 9][]

解决这样的问题，其实最好的方式就是在执行完更新数据库的操作后，先休眠一会儿，再进行一次缓存的删除，以确保数据一致性

首先延迟删除的时间需要大于 1号用户执行流程的总时间

就是1号用户从数据库读取数据 写入缓存时间

#### 4.3.2、通过发送MQ，在消费者线程去同步Redis ####

![format_png 10][]

无论是更新缓存还是删除缓存，在同时操作缓存和数据库时，都无法保证两者都能一次性操作成功，所以我们最好的办法就是**重试**，这个重试并不是立即重试，因为缓存和数据库可能因为网络或者其它原因停止服务了，立即重试成功率极低，而且重试会占用线程资源，显然不合理，所以我们需要采用**异步重试机制**。

异步重试我们可以使用消息队列来完成，因为消息队列可以保证消息的可靠性，消息不会丢失，也可以保证正确消费，当且仅当消息消费成功后才会将消息从消息队列中删除。

优点1：可以大幅减少接口的延迟返回的问题

优点2：MQ本身有重试机制，无需人工去写重试代码

优点3：解耦，把查询Mysql和同步Redis完全分离，互不干扰

#### 4.3.3、Canal 订阅日志实现 ####

当我们业务修改数据时，我们只需要更新数据库，无需修改缓存，那什么时候修改缓存呢？

以mysql为例，在数据库一条记录发生变更时就会生成一条binlog日志，我们可以订阅这种消息，拿到具体的数据，然后根据日志消息更新缓存，订阅日志目前比较流行的就是阿里开源的canal，那么我们的架构就变为如下形式。

![format_png 11][]

订阅数据库变更日志，当数据库发生变更时，我们可以拿到具体操作的数据，然后再去根据具体的数据，去删除对应的缓存。

当然**Canal** 也是要配合消息队列一起来使用的，因为其**Canal**本身是没有数据处理能力的。

![format_png 12][]

这个方式算的上彻底解耦了，应用程序代码无需再管消息队列方面发送失败问题，全交由 Canal来发送。

[NoSQL]: https://link.juejin.cn?target=https%3A%2F%2Fso.csdn.net%2Fso%2Fsearch%3Fq%3DNoSQL%26spm%3D1001.2101.3001.7020
[format_png]: https://img-blog.csdnimg.cn/img_convert/45875251d4a71807b91c9bda72c1a5ec.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/c7533d0c67df85f180cf657ea0fedefb.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/ac49673f90f8dea9a676c2b87903674e.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/5e78e3be328dde10b9d416a87cd796c9.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/b09b131d438bbed65abeaf9c0c8fc3e3.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/5ae4c675c6a5069de00c5bb98e8a82fd.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/345e77e95a4d1c53c22e7050cdeaca38.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/ed8d314be783fb653b070b56080fbb3b.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/89c6998d2fe4b8b5a231a0bcaa0ad75a.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/fee0139fafee2b797c91aae24745be42.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/6a2b8b2e619627cf1b59262b3d3eea66.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/a928a4144290c9df842f329e60c98af1.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/732bd732a3c619d868bd7d1ab2c7e29a.webp?x-oss-process=image/format,png