美团二面:Redis与MySQL双写一致性如何保证?

标签: 美团 redis mysql | 发表时间:2021-05-21 00:24 | 作者:捡田螺的小男孩
出处:https://juejin.im/backend?sort=monthly_hottest

前言

四月份的时候,有位朋友去美团面试,他说被问到Redis与MySQL双写一致性如何保证? 这道题其实就是在问缓存和数据库在双写场景下,一致性是如何保证的?本文将跟大家一起来探讨如何回答这个问题。

谈谈一致性

一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的。

  • 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大
  • 弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态
  • 最终一致性:最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型

三个经典的缓存模式

缓存可以提升性能、缓解数据库压力,但是使用缓存也会导致数据 不一致性的问题。一般我们是如何使用缓存呢?有三种经典的缓存模式:

  • Cache-Aside Pattern
  • Read-Through/Write through
  • Write behind

Cache-Aside Pattern

Cache-Aside Pattern,即 旁路缓存模式,它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。

Cache-Aside读流程

Cache-Aside Pattern的读请求流程如下:

Cache-Aside读请求

  1. 读的时候,先读缓存,缓存命中的话,直接返回数据
  2. 缓存没有命中的话,就去读数据库,从数据库取出数据,放入缓存后,同时返回响应。

Cache-Aside 写流程

Cache-Aside Pattern的写请求流程如下:

Cache-Aside写请求

更新的时候,先 更新数据库,然后再删除缓存

Read-Through/Write-Through(读写穿透)

Read/Write Through模式中,服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互,都是通过 抽象缓存层完成的。

Read-Through

Read-Through的简要流程如下

Read Through简要流程

  1. 从缓存读取数据,读到直接返回
  2. 如果读取不到的话,从数据库加载,写入缓存后,再返回响应。

这个简要流程是不是跟 Cache-Aside很像呢?其实 Read-Through就是多了一层 Cache-Provider,流程如下:

Read-Through流程

Read-Through实际只是在 Cache-Aside之上进行了一层封装,它会让程序代码变得更简洁,同时也减少数据源上的负载。

Write-Through

Write-Through模式下,当发生写请求时,也是由 缓存抽象层完成数据源和缓存数据的更新,流程如下: Write-Through流程

Write behind (异步缓存写入)

Write behindRead-Through/Write-Through有相似的地方,都是由 Cache Provider来负责缓存和数据库的读写。它两又有个很大的不同: Read/Write Through是同步更新缓存和数据的, Write Behind则是只更新缓存,不直接更新数据库,通过 批量异步的方式来更新数据库。

Write behind流程

这种方式下,缓存和数据库的一致性不强, 对一致性要求高的系统要谨慎使用。但是它适合频繁写的场景,MySQL的 InnoDB Buffer Pool机制就使用到这种模式。

操作缓存的时候,删除缓存呢,还是更新缓存?

一般业务场景,我们使用的就是 Cache-Aside模式。 有些小伙伴可能会问, Cache-Aside在写入请求的时候,为什么是 删除缓存而不是更新缓存呢?

Cache-Aside写入流程

我们在操作缓存的时候,到底应该删除缓存还是更新缓存呢?我们先来看个例子:

  1. 线程A先发起一个写操作,第一步先更新数据库
  2. 线程B再发起一个写操作,第二步更新了数据库
  3. 由于网络等原因,线程B先更新了缓存
  4. 线程A更新缓存。

这时候,缓存保存的是A的数据(老数据),数据库保存的是B的数据(新数据),数据 不一致了,脏数据出现啦。如果是 删除缓存取代更新缓存则不会出现这个脏数据问题。

更新缓存相对于删除缓存,还有两点劣势:

  • 如果你写入的缓存值,是经过复杂计算才得到的话。更新缓存频率高的话,就浪费性能啦。
  • 在写数据库场景多,读数据场景少的情况下,数据很多时候还没被读取到,又被更新了,这也浪费了性能呢(实际上,写多的场景,用缓存也不是很划算了)

双写的情况下,先操作数据库还是先操作缓存?

Cache-Aside缓存模式中,有些小伙伴还是有疑问,在写入请求的时候,为什么是 先操作数据库呢?为什么 不先操作缓存呢?

假设有A、B两个请求,请求A做更新操作,请求B做查询读取操作。 image.png

  1. 线程A发起一个写操作,第一步del cache
  2. 此时线程B发起一个读操作,cache miss
  3. 线程B继续读DB,读出来一个老数据
  4. 然后线程B把老数据设置入cache
  5. 线程A写入DB最新的数据

酱紫就有问题啦, 缓存和数据库的数据不一致了。缓存保存的是老数据,数据库保存的是新数据。因此, Cache-Aside缓存模式,选择了先操作数据库而不是先操作缓存。

缓存延时双删

有些小伙伴可能会说,不一定要先操作数据库呀,采用 缓存延时双删策略就好啦?什么是延时双删呢?

image.png

  1. 先删除缓存
  2. 再更新数据库
  3. 休眠一会(比如1秒),再次删除缓存。

这个休眠一会,一般多久呢?都是1秒?

这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。 为了确保读请求结束,写请求可以删除读请求可能带来的缓存脏数据。

删除缓存重试机制

不管是 延时双删还是 Cache-Aside的先操作数据库再删除缓存,如果第二步的删除缓存失败呢,删除失败会导致脏数据哦~

删除失败就多删除几次呀,保证删除缓存成功呀~ 所以可以引入 删除缓存重试机制

image.png

  1. 写请求更新数据库
  2. 缓存因为某些原因,删除失败
  3. 把删除失败的key放到消息队列
  4. 消费消息队列的消息,获取要删除的key
  5. 重试删除缓存操作

读取biglog异步删除缓存

重试删除缓存机制还可以,就是会造成好多业务代码入侵。其实,还可以通过 数据库的binlog来异步淘汰key

image.png

以mysql为例 可以使用阿里的canal将binlog日志采集发送到MQ队列里面,然后通过ACK机制确认处理这条更新消息,删除缓存,保证数据缓存一致性

参考与感谢

相关 [美团 redis mysql] 推荐:

美团二面:Redis与MySQL双写一致性如何保证?

- - 掘金后端本月最热
四月份的时候,有位朋友去美团面试,他说被问到Redis与MySQL双写一致性如何保证. 这道题其实就是在问缓存和数据库在双写场景下,一致性是如何保证的. 本文将跟大家一起来探讨如何回答这个问题. github地址,感谢每一颗star. 一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的.

REDIS与MYSQL实现标签的对比

- - CSDN博客推荐文章
这里来演示下REDIS和MYSQL之间的数据转换问题,REDIS 是典型的KEY -VALUE型NOSQL数据库,并且提供了额外丰富的数据类型. 这里简单列举了标签类型的应用问题. 比如在MySQL里面,对内容的标签有以下简单的几张表,我这里只列出来拆分过后的表结构. 内容表: CREATE TABLE `content` ( `id` int(10) unsigned NOT NULL, -- 内容ID,唯一.

浅谈 Redis 与 MySQL 的耦合性以及利用管道完成 MySQL 到 Redis 的高效迁移

- - CSDN博客数据库推荐文章
    ㈠ Redis 与 MySQL 的耦合性.     在业务架构早期、我们便该"吃着碗里的看着锅里的"、切莫让MySQL 有梦、而Redis 无心.     毕竟、有些关系型的结构不适合放到Redis跑、"男女搭配、干活不累"嘛、推荐让MySQL与Redis喜结连理.     其次、这 2 人、一般是在不同场景做选择、而不会在性能上选择、.

美团在Redis上踩过的一些坑(本人非美团)

- - 互联网 - ITeye博客
    上上周和同事参加了360组织的互联网技术训练营第三期,美团网的DBA负责人侯军伟给大家介绍了美团网在redis上踩得一些坑,讲的都是干货和坑.     我们在运维我们的redis私有云时,也遇到了一些类似的坑:.    一、周期性出现connect timeout:.           大部分互联网公司都会有Mysql或者Oracle的DBA,但是在Nosql方面一般不会设置专门的DBA.

mysql突然出现大量慢sql,随后redis访问超时

- - Linux - 操作系统 - ITeye博客
在亚马逊云买了多台的虚拟主机,一年多没有由于系统的原因出过故障. 早上接到报警,从业务故障上来看,应该是数据库没有响应了. SSH连数据库服务器,发现连不上. 重启数据库服务器,一直起不来. 最后用上周的数据库服务器的系统备份snapshot(我们的数据盘和系统盘是分开的)新建一个Volume,替换掉故障系统盘,重新启动服务器,才顺利进入系统.

redis作为mysql的缓存服务器(读写分离)

- - 数据库 - ITeye博客
Redis是一个key-value存储系统. 和Memcached类似,为了保证效率,数据都是缓存在内存中. 区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步. 在部分场合可以对关系数据库起到很好的补充作用. 它提供了Java,C/C++(hiredis),C#,PHP,JavaScript,Perl,Object-C,Python,Ruby等客户端,使用很方便.

Mysql和Redis数据同步策略 - 元思 - 博客园

- -
不更新缓存是防止并发更新导致的数据不一致. 所以为了降低数据不一致的概率,不应该更新缓存,而是直接将其删除,. 然后等待下次发生cache miss时再把数据库中的数据同步到缓存. 如果先删除缓存,有一个明显的逻辑错误:考虑两个并发操作,线程A删除缓存后,线程B读该数据时会发生Cache Miss,然后从数据库中读出该数据并同步到缓存中,此时线程A更新了数据库.

美团针对Redis Rehash机制的探索和实践

- - 美团点评技术团队
Squirrel(松鼠)是美团技术团队基于Redis Cluster打造的缓存系统. 经过不断的迭代研发,目前已形成一整套自动化运维体系:涵盖一键运维集群、细粒度的监控、支持自动扩缩容以及热点Key监控等完整的解决方案. 同时服务端通过Docker进行部署,最大程度的提高运维的灵活性. 分布式缓存Squirrel产品自2015年上线至今,已在美团内部广泛使用,存储容量超过60T,日均调用量也超过万亿次,逐步成为美团目前最主要的缓存系统之一.

JAVA通过Gearman实现MySQL到Redis的数据同步(异步复制)

- - 企业架构 - ITeye博客
MySQL到Redis数据复制方案. 无论MySQL还是Redis,自身都带有数据同步的机制,像比较常用的 MySQL的Master/Slave模式 ,就是由Slave端分析Master的binlog来实现的,这样的数据复制其实还是一个异步过程,只不过当服务器都在同一内网时,异步的延迟几乎可以忽略.

全新安装Mac OSX 开发者环境 同时使用homebrew搭建 PHP,Nginx ,MySQL,Redis,Memcache ... ... (LNMP开发

- - 操作系统 - ITeye博客
重新安装系统,在苹果商店下载好OS X Mavericks安装文件,然后准备一支16G的USB3.0 U盘. 制作 OS X Mavericks 全新安装启动U盘. untitled 是你的u盘盘符,根据实际情况来. 看到上面的信息说明启动盘制作成功. 安装起来so easy :). 安装完成系统之后, 暂时还没有去迁移文件,由于本人喜好摄影,有大量RAW格式的原图在Aperture 的照片库中,尼康D800一张RAW文件有40M左右,到时候迁移照片库和照片流希望不要掉坑里了.