掘地三尺搞定|掘地三尺搞定 Redis 与 MySQL 数据一致性问题
Redis 拥有高性能的数据读写功能,被我们广泛用在缓存场景,一是能提高业务系统的性能,二是为数据库抵挡了高并发的流量请求,点我 -> 解密 Redis 为什么这么快的秘密。
把 Redis 作为缓存组件,需要防止出现以下的一些问题,否则可能会造成生产事故。
- Redis 缓存满了怎么办?
- 缓存穿透、缓存击穿、缓存雪崩如何解决?
- Redis 数据过期了会被立马删除么?
- Redis 突然变慢了如何做性能排查并解决?
- Redis 与 MySQL 数据一致性问题怎么应对?
在本文正式开始之前,我觉得我们需要先取得以下两点的共识:
- 缓存必须要有过期时间;
- 保证数据库跟缓存的最终一致性即可,不必追求强一致性。
[toc]
1. 什么是数据库与缓存一致性 数据一致性指的是:
- 缓存中存有数据,缓存的数据值 = 数据库中的值;
- 缓存中没有该数据,数据库中的值 = 最新值。
- 缓存的数据值 ≠ 数据库中的值;
- 缓存或者数据库存在旧的数据,导致线程读取到旧数据。
为何会出现数据一致性问题呢?把 Redis 作为缓存的时候,当数据发生改变我们需要双写来保证缓存与数据库的数据一致。
数据库跟缓存,毕竟是两套系统,如果要保证强一致性,势必要引入
2PC
或 Paxos
等分布式一致性协议,或者分布式锁等等,这个在实现上是有难度的,而且一定会对性能有影响。如果真的对数据的一致性要求这么高,那引入缓存是否真的有必要呢?
2. 缓存的使用策略 在使用缓存时,通常有以下几种缓存使用策略用于提升系统性能:
Cache-Aside Pattern
(旁路缓存,业务系统常用)Read-Through Pattern
Write-Through Pattern
Write-Behind Pattern
所谓「旁路缓存」,就是读取缓存、读取数据库和更新缓存的操作都在应用系统来完成,业务系统最常用的缓存策略。
2.1.1 读取数据
文章图片
读取数据逻辑如下:
- 当应用程序需要从数据库读取数据时,先检查缓存数据是否命中。
- 如果缓存未命中,则查询数据库获取数据,同时将数据写到缓存中,以便后续读取相同数据会命中缓存,最后再把数据返回给调用者。
- 如果缓存命中,直接返回。
文章图片
优点
- 缓存中仅包含应用程序实际请求的数据,有助于保持缓存大小的成本效益。
- 实现简单,并且能获得性能提升。
String cacheKey = "公众号:码哥字节";
String cacheValue = https://www.it610.com/article/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
到数据库的操作完成。
该方案 pass,因为第一步成功,第二步失败,会造成数据库是旧数据,缓存中没数据继续从数据库读取旧值写入缓存,造成数据不一致,还会多一次 cahche。
不论是异常情况还是高并发场景,会导致数据不一致。 miss。
3.4 先更新数据库,再删缓存
经过前面的三个方案,全都被 pass 了,分析下最后的方案到底行不行。
按照「套路」,分别判断异常和高并发会造成什么问题。
该策略可以知道,在写数据库阶段失败的话就直返返回客户端异常,不需要执行缓存操作了。
所以第一步失败不会出现数据不一致的情况。
删缓存失败 重点在于第一步写最新数据到数据库成功,删除缓存失败怎么办?
可以把这两个操作放在一个事务中,当缓存删除失败,那就把写数据库回滚。
高并发场景下不合适,容易出现大事务,造成死锁问题。如果不回滚,那就出现数据库是新数据,缓存还是旧数据,数据不一致了,咋办?
所以,我们要想办法让缓存删除成功,不然只能等到有效期失效那可不行。
使用重试机制。
比如重试三次,三次都失败则记录日志到数据库,使用分布式调度组件 xxl-job 等实现后续的处理。
在高并发的场景下,重试最好使用异步方式,比如发送消息到 mq 中间件,实现异步解耦。
亦或是利用 Canal 框架订阅 MySQL binlog 日志,监听对应的更新请求,执行删除对应缓存操作。
高并发场景 再来分析下高并发读写会有什么问题……
文章图片
- 98 号技师先下手为强,接下肖菜鸡的这笔生意,数据库执行
set 肖菜鸡的服务技师 = 98
;还是网络卡顿了下,没来得及执行删除缓存操作。 - 主管 Candy 向系统执行读请求,查下肖菜鸡有没有技师接待,发现缓存中有数据
肖菜鸡的服务技师 = 待定
,直接返回信息给客户端,主管以为没人接待。 - 原先 98 号技师接单,由于卡顿没删除缓存的操作现在执行删除成功。
还有一种比较极端的情况,缓存自动失效的时候又遇到了高并发读写的情况,假设这会有两个请求,一个线程 A 做查询操作,一个线程 B 做更新操作,那么会有如下情形产生:
文章图片
- 缓存的过期时间到期,缓存失效。
- 线程 A 读请求读取缓存,没命中,则查询数据库得到一个旧的值(因为 B 会写新值,相对而言就是旧的值了),准备把数据写到缓存时发送网络问题卡顿了。
- 线程 B 执行写操作,将新值写数据库。
- 线程 B 执行删除缓存。
- 线程 A 继续,从卡顿中醒来,把查询到的旧值写到入缓存。
码哥,这咋玩,还是出现了不一致的情况啊。不要慌,发生这个情况的概率微乎其微,发生上述情况的必要条件是:
- 步骤 (3)的写数据库操作要比步骤(2)读操作耗时短速度快,才可能使得步骤(4)先于步骤(5)。
- 缓存刚好到达过期时限。
数据库读操作是远快于写操作的(正是因为如此,才做读写分离),所以步骤(3)要比步骤(2)更快这个情景很难出现,同时还要配合缓存刚好失效。
所以,在用旁路缓存策略的时候,对于写操作推荐使用:先更新数据库,再删除缓存。
4. 一致性解决方案有哪些? 最后,针对 Cache-Aside (旁路缓存) 策略,写操作使用先更新数据库,再删除缓存的情况下,我们来分析下数据一致性解决方案都有哪些?
4.1 缓存延时双删
如果采用先删除缓存,再更新数据库如何避免出现脏数据?
采用延时双删策略。
- 先删除缓存。
- 写数据库。
- 休眠 500 毫秒,再删除缓存。
延迟时间的目的就是确保读请求结束,写请求可以删除读请求造成的缓存脏数据。
所以我们需要自行评估项目的读数据业务逻辑的耗时,在读耗时的基础上加几百毫秒作为延迟时间即可。
4.2 删除缓存重试机制
缓存删除失败怎么办?比如延迟双删的第二次删除失败,那岂不是无法删除脏数据。使用重试机制,保证删除缓存成功。
比如重试三次,三次都失败则记录日志到数据库并发送警告让人工介入。
在高并发的场景下,重试最好使用异步方式,比如发送消息到 mq 中间件,实现异步解耦。
文章图片
第(5)步如果删除失败且未达到重试最大次数则将消息重新入队,直到删除成功,否则就记录到数据库,人工介入。
该方案有个缺点,就是对业务代码中造成侵入,于是就有了下一个方案,启动一个专门订阅 数据库 binlog 的服务读取需要删除的数据进行缓存删除操作。
4.3 读取 binlog 异步删除
文章图片
- 更新数据库;
- 数据库会把操作信息记录在 binlog 日志中;
- 使用 canal 订阅 binlog 日志获取目标数据和 key;
- 缓存删除系统获取 canal 的数据,解析目标 key,尝试删除缓存。
- 如果删除失败则将消息发送到消息队列;
- 缓存删除系统重新从消息队列获取数据,再次执行删除操作。
读缓存最佳实践:先读缓存,命中则返回;未命中则查询数据库,再写到数据库。
写缓存最佳实践:
- 先写数据库,再操作缓存;
- 直接删除缓存,而不是修改,因为当缓存的更新成本很高,需要访问多张表联合计算,建议直接删除缓存,而不是更新,另外,删除缓存操作简单,副作用只是增加了一次 chache miss,建议大家使用该策略。
防止删除失败,我们采用异步重试机制保证能正确删除,异步机制我们可以发送删除消息到 mq 消息中间件,或者利用 canal 订阅 MySQL binlog 日志监听写请求删除对应缓存。
那么,如果我非要保证绝对一致性怎么办,先给出结论:
没有办法做到绝对的一致性,这是由 CAP 理论决定的,缓存系统适用的场景就是非强一致性的场景,所以它属于 CAP 中的 AP。
所以,我们得委曲求全,可以去做到 BASE 理论中说的最终一致性。
其实一旦在方案中使用了缓存,那往往也就意味着我们放弃了数据的强一致性,但这也意味着我们的系统在性能上能够得到一些提升。
所谓 tradeoff 正是如此。
最后,大家可以在评论区叫我靓仔么?不想叫我靓仔的「点赞」和「在看」也是一种鼓励。
加「码哥」微信:MageByte1024,进入专属读者技术群一起谈天说地聊技术。
鸣谢
https://docs.aws.amazon.com/w...
https://codeahoy.com/2017/08/...
https://blog.cdemi.io/design-...
https://hazelcast.com/blog/a-...
【掘地三尺搞定|掘地三尺搞定 Redis 与 MySQL 数据一致性问题】https://developer.aliyun.com/...
推荐阅读
- mysql|mysql删除重复数据,一条sql就搞定
- 一个依赖搞定|一个依赖搞定 Spring Boot 接口防盗刷的流程分析
- 字段特别多,只要id跟后端一致,一个方法搞定
- 5个实用的PDF自动化办公操作~1行Python代码搞定(解密加水印PPT/Word/TxT转PDF)
- U盘无法格式化怎样办?一键搞定U盘格式化
- #yyds干货盘点# Kubernetes 搞定网络原来可以如此简单((25))
- 带你十天轻松搞定 Go 微服务系列
- #yyds干货盘点# HCIE-Security Day6(5个实验搞定源NAT)
- 设计模式11-- 搞定组合模式
- 滤镜也能复制粘贴(视频编辑服务专属滤镜一键搞定)