Redis 与 MySQL 数据一致性问题

置顶吴名氏.

已于 2024-06-19 10:49:13 修改

阅读量10w+

点赞数 14

分类专栏： Java redis mysql 文章标签：大数据 mysql redis 数据库一致性

于 2022-06-24 15:00:11 首次发布

本文链接：https://blog.csdn.net/qq_37284798/article/details/125445209

版权

Java 同时被 3 个专栏收录

209 篇文章 32 订阅

订阅专栏

mysql

30 篇文章 2 订阅

订阅专栏

redis

18 篇文章 3 订阅

订阅专栏

Redis 拥有高性能的数据读写功能，被我们广泛用在缓存场景，一是能提高业务系统的性能，二是为数据库抵挡了高并发的流量请求。

把 Redis 作为缓存组件，需要防止出现以下问题，否则可能会造成生产事故。

Redis 缓存满了
缓存穿透、缓存击穿、缓存雪崩
Redis 数据过期了
Redis 突然变慢了
Redis 与 MySQL 数据一致性问题

在本文正式开始之前，需要大家先取得以下两点共识：

缓存必须要有过期时间；
保证数据库跟缓存的最终一致性即可，不必追求强一致性

1. 什么是数据库与缓存一致性？

数据一致性指的是：

缓存中存有数据，缓存的数据值 = 数据库中的值；
缓存中没有该数据，数据库中的值 = 最新值。

反推缓存与数据库不一致：

缓存的数据值 ≠ 数据库中的值；
缓存或者数据库存在旧的数据，导致线程读取到旧数据。

为何会出现数据一致性问题呢？

把 Redis 作为缓存的时候，当数据发生改变我们需要双写来保证缓存与数据库的数据一致性。

数据库跟缓存毕竟是两套系统，如果要保证强一致性，势必要引入 2PC 或 Paxos 等分布式一致性协议，或者分布式锁等等。这个在实现上是有难度的，而且一定会对性能有影响。

如果真的对数据的一致性要求这么高，那引入缓存是否真的有必要呢？

2. 缓存的使用策略

在使用缓存时，通常有以下几种缓存使用策略用于提升系统性能：

Cache-Aside 模式（旁路缓存，业务系统常用）
Read-Through 模式（直读）
Write-Through 模式（同步直写）
Write-Behind 模式

2.1 Cache-Aside (旁路缓存)

所谓「旁路缓存」，就是读取缓存、读取数据库和更新缓存的操作都在应用系统来完成，业务系统最常用的缓存策略。

2.1.1 读取数据

读取数据逻辑如下:

当应用程序需要从数据库读取数据时，先检查缓存数据是否命中；
如果缓存未命中，则查询数据库获取数据。同时将数据写到缓存中，以便后续读取相同数据会命中缓存。最后再把数据返回给调用者；
如果缓存命中，直接返回。

时序图如下：

优点

缓存中仅包含应用程序实际请求的数据，有助于保持缓存大小的成本效益；
实现简单，并且能获得性能提升。

实现的伪代码如下：


String cacheKey = "码哥字节";
String cacheValue = redisCache.get(cacheKey)；
//缓存命中
if (cacheValue != null) {
  return cacheValue;
} else {
  //缓存缺失, 从数据库获取数据
  cacheValue = getDataFromDB();
  // 将数据写到缓存中
  redisCache.put(cacheValue)
}

缺点

由于数据仅在缓存未命中后才加载到缓存中，因此初次调用的数据请求响应时间会增加一些开销，因为需要额外的缓存填充和数据库查询耗时。

2.1.2 更新数据

使用 cache-aside 模式写数据时，如下流程。

写数据到数据库；
将缓存中的数据失效或者更新缓存数据。

使用 cache-aside 时，最常见的写入策略是直接将数据写入数据库，但是缓存可能会与数据库不一致。

我们应该给缓存设置一个过期时间，这个是保证最终一致性的解决方案。

如果过期时间太短，应用程序会不断地从数据库中查询数据。同样，如果过期时间过长，并且更新时没有使缓存失效，缓存的数据很可能是脏数据。

最常用的方式是删除缓存使缓存数据失效。

为啥不是更新缓存呢？

性能问题

当缓存的更新成本很高需要访问多张表联合计算时，建议直接删除缓存，而不是更新缓存数据来保证一致性。

安全问题

在高并发场景下，可能会造成查询查到的数据是旧值，具体原因稍后分析。

2.2 Read-Through 模式（直读）

当缓存未命中，也是从数据库加载数据，同时写到缓存中并返回给应用系统。

虽然 read-through 和 cache-aside 非常相似，在 cache-aside 中应用系统负责从数据库获取数据和填充缓存。

而 Read-Through 将获取数据存储中的值的责任转移到了缓存提供者身上。

Read-Through 实现了关注点分离原则。代码只与缓存交互，由缓存组件来管理自身与数据库之间的数据同步。

2.3 Write-Through 模式（同步直写）

与 Read-Through 类似，发生写请求时，Write-Through 将写入责任转移到缓存系统，由缓存抽象层来完成缓存数据和数据库数据的更新，时序流程图如下：

Write-Through 的主要好处是应用系统的不需要考虑故障处理和重试逻辑，交给缓存抽象层来管理实现。

优缺点

单独直接使用该策略是没啥意义的，因为该策略要先写缓存，再写数据库，对写入操作带来了额外延迟。

当 Write-Through 与 Read-Through 配合使用，就能充分发挥 Read-Through 的优势，同时还能保证数据一致性，不需要考虑如何将缓存设置失效。

这个策略颠倒了 Cache-Aside 填充缓存的顺序，并不是在缓存未命中后延迟加载到缓存，而是在数据先写缓存，接着由缓存组件将数据写到数据库。

优点

缓存与数据库数据总是最新的；
查询性能最佳，因为要查询的数据有可能已经被写到缓存中了。

缺点

不经常请求的数据也会写入缓存，从而导致缓存更大、成本更高。

2.4 Write-Behind 模式

这个图一眼看去似乎与 Write-Through 一样，其实不是。区别在于最后一个箭头的箭头：它从实心变为线。

这意味着缓存系统将异步更新数据库数据，应用系统只与缓存系统交互。

应用程序不必等待数据库更新完成，从而提高应用程序性能，因为对数据库的更新是最慢的操作。

这种策略下，缓存与数据库的一致性不强，对一致性高的系统不建议使用。

3. 旁路缓存下的一致性问题分析

业务场景用的最多的就是 Cache-Aside (旁路缓存) 策略，在该策略下，客户端对数据的读取流程是先读取缓存，如果命中则返回；未命中，则从数据库读取并把数据写到缓存中，所以读操作不会导致缓存与数据库的不一致。

重点是写操作，数据库和缓存都需要修改，而两者就会存在一个先后顺序，可能会导致数据不再一致。针对写，我们需要考虑两个问题：

先更新缓存还是更新数据库？
当数据发生变化时，选择修改缓存（update），还是删除缓存（delete）？

将这两个问题排列组合，会出现四种方案：

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

接下来的分析大家不必死记硬背，关键在于在推演的过程中大家只需要考虑以下两个场景会不会带来严重问题即可：

其中第一个操作成功，第二个失败会导致什么问题？
在高并发情况下会不会造成读取数据不一致？

为啥不考虑第一个失败，第二个成功的情况呀？

既然第一个都失败了，第二个就不用执行了，直接在第一步返回 50x 等异常信息即可，不会出现不一致问题。

只有第一个成功，第二个失败才让人头痛，想要保证他们的原子性，就涉及到分布式事务的范畴了。

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

如果先更新缓存成功，写数据库失败，就会导致缓存是最新数据，数据库是旧数据，那缓存就是脏数据了。

之后，其他查询立马请求进来的时候就会获取这个数据，而这个数据数据库中却不存在。

数据库都不存在的数据，缓存并返回客户端就毫无意义了。

该方案直接 Pass。

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

一切正常的情况如下：

先写数据库，成功；
再 update 缓存，成功。

更新缓存失败

这时候我们来推断下，假如这两个操作的原子性被破坏：第一步成功，第二步失败会导致什么问题？

会导致数据库是最新数据，缓存是旧数据，出现一致性问题。

该图与上一个图类似，把 Redis 和 MySQL 的位置对调即可。

高并发场景

谢霸歌经常 996，腰酸脖子疼，bug 越写越多，想去按摩推拿放提升下编程技巧。

疫情影响，单子来之不易，高端会所的技师都争先恐后想接这一单，高并发啊兄弟们。

在进店以后，前台会将顾客信息录入系统，执行 set xx的服务技师 = 待定的初始值表示目前无人接待保存到数据库和缓存中，之后再安排技师按摩服务。

如下图所示：

98 号技师先下手为强，向系统发送 set 谢霸歌的服务技师 = 98 的指令写入数据库，这时候系统的网络出现波动，卡顿了，数据还没来得及写到缓存；
接下来，520 号技师也向系统发送 set 谢霸哥的服务技师 = 520写到数据库中，并且也把这个数据写到缓存中了；
这时候之前的 98 号技师的写缓存请求开始执行，顺利将数据 set 谢霸歌的服务技师 = 98 写到缓存中。

最后发现，数据库的值 = set 谢霸哥的服务技师 = 520，而缓存的值= set 谢霸歌的服务技师 = 98。

520 号技师在缓存中的最新数据被 98 号技师的旧数据覆盖了。

所以，在高并发的场景中，多线程同时写数据再写缓存，就会出现缓存是旧值，数据库是最新值的不一致情况。

该方案直接 pass。

如果第一步就失败，直接返回 50x 异常，并不会出现数据不一致。

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

按照「码哥」前面说的套路，假设第一个操作成功，第二个操作失败推断下会发生什么？高并发场景下又会发生什么？

第二步写数据库失败

假设现在有两个请求：写请求 A，读请求 B。

写请求 A 第一步先删除缓存成功，写数据到数据库失败，就会导致该次写数据丢失，数据库保存的是旧值。

接着另一个读请 B 求进来，发现缓存不存在，从数据库读取旧数据并写到缓存中。

高并发下的问题

还是 98 号技师先下手为强，系统接收请求把缓存数据删除，当系统准备将 set 肖菜鸡的服务技师 = 98写到数据库的时候发生卡顿，来不及写入；
这时候，大堂经理向系统执行读请求，查下肖菜鸡有没有技师接待，方便安排技师服务，系统发现缓存中没数据，于是乎就从数据库读取到旧数据 set 肖菜鸡的服务技师 = 待定，并写到缓存中；
这时候，原先卡顿的 98 号技师写数据 set 肖菜鸡的服务技师 = 98到数据库的操作完成。

这样子会出现缓存的是旧数据，在缓存过期之前无法读取到最数据。肖菜鸡本就被 98 号技师接单了，但是大堂经理却以为没人接待。

该方案 pass，因为第一步成功，第二步失败，会造成数据库是旧数据，缓存中没数据继续从数据库读取旧值写入缓存，造成数据不一致，还会多一次 cahche。

不论是异常情况还是高并发场景，会导致数据不一致。miss。