【数据库 的面试】redis缓存一致性怎么保证?redis mysql 缓存方案_mysql缓存机制_redis同步数据到mysql


作者:牛牛玛特 公众号:牛牛玛特

2019年,牛牛面试字节深圳某部门时,被问到如何保证redis和mysql的数据一致性?牛牛凭着多年积累,和面试官就各种情况畅聊10分钟,顺利过关。

2020年,同样的问题,牛牛在鹅厂三面中再次被问及。如此高频的问题,如果你遇到,能否对答如流?

缓存是什么?

缓存在计算机领域是一个非常重要的概念。牛牛首次接触缓存,是在操作系统的课上。简单来说,存储的速度是有区别的,缓存就是把低速存储的结果,临时保存在高速存储,以提高查询效率。

在数据库场景下,更廉价、高效但可靠性稍低的redis可以给更昂贵、较慢、可靠性强的mysql做缓存。

为什么需要缓存?

关系型数据库如mysql,通常支持完整的ACID特性,即原子性、一致性、隔离性和持久性,架构复杂,因而性能普遍较低。高并发的查询需求,会给mysql带来很大压力,造成数据库系统的不稳定,同时也容易产生延迟。

根据局部性原理,80%的请求会落到20%热点数据上,在读多写少场景下,增加一层缓存非常有助提升系统吞吐量和健壮性。通常,我们会使用redis来作为mysql的缓存,如果在redis中能找到缓存,就叫缓存命中,此时就直接用redis的数据;如果缓存未命中,那么再从mysql读取数据。可以看到,redis就像一个盾牌🛡️一样,帮助mysql分担请求,减轻压力。

数据库 的面试,redis缓存一致性,redis mysql 缓存方案,mysql缓存机制,redis同步数据到mysql

存在问题

mysql的数据随着时间流逝,可能会发生更新,此时redis缓存数据就会落后,我们如何保证它们的一致性呢?

这里要明白一点,面试官要考察的,一定是符合实际场景的最终一致性,如果非要杠强一致性,那么八成是希望你告诉他,强一致性带来的成本巨大,还不如不用缓存。

解决方案

方案一:等待过期,顺其自然

使用redis的过期时间,mysql更新时,redis不做处理,等待缓存过期失效,再从mysql拉取缓存。

这种方式实现简单,但不一致的时间会比较明显,具体由你的业务来配置。如果读请求非常频繁,且过期时间设置较长,则会产生很多脏数据。

优点:

  • redis原生接口,开发成本低,易于实现;
  • 管理成本低,出问题的概率会比较小。

不足:

  • 完全依赖过期时间,时间太短容易造成缓存频繁失效,太长容易有较长时间不一致,对编程者的业务能力,有一定要求。

方案二:尝试删除,从头再来

在方案一的基础上扩展,不光通过key的过期时间兜底,还需要在更新mysql时,同时尝试删除redis,如果删除成功,下次访问该数据,则会直接查询mysql的数据,此时再写入redis,就完成了数据同步。这里为什么说是尝试删除呢?因为有了key本身的过期时间作为保障,最终一致性是一定达成的,主动删除redis数据只是为了减少不一致的时间,但不能让其成为一个关键路径,影响核心流程。

数据库 的面试,redis缓存一致性,redis mysql 缓存方案,mysql缓存机制,redis同步数据到mysql

优点:

  • 相对方案一,达成最终一致性的延迟更小;
  • 实现成本较低,只是在方案一的基础上,增加了删除逻辑。

不足:

  • 如果更新mysql成功,删除redis却失败,就退化到了方案一;
  • 在高并发场景,业务server需要和mysql、redis同时进行连接,这样是损耗双倍的连接资源,容易造成连接数过多的问题。

方案三:主动更新,信箱投递

从被动防守,到主动进攻,在更新mysql之后,redis也要更新,怎么更新呢?用消息队列!具体来说,是将更新操作交给消息队列,由消息队列保证可靠性,此外再搭建一个消费服务订阅消息队列,来异步更新redis数据。

数据库 的面试,redis缓存一致性,redis mysql 缓存方案,mysql缓存机制,redis同步数据到mysql

优点:

  • 使用消息队列,就相当于将请求投递至信箱,只要投递成功即完成任务,不用关心结果,实现了进一步解耦;
  • 消息队列本身具有可靠性,在投递成功的前提下,通过手动提交等手段去消费,可以保证更新操作至少在redis中执行一次。

不足:

  • 有时序性问题。举个栗子🌰,两台业务服务器在同一时间发出a = 1和a = 5两条请求,若mysql中先执行a=1再执行a=5,则mysql中a的值最终为5;但由于网络传输本身有延迟,所以无法保证两条请求谁先进入消息队列,最终redis的结果可能是1也可能是5,如果是1,mysql和redis中的数据就会产生不一致;
  • 引入了消息队列,同时要增加消费服务,成本较高;
  • 依旧有消耗更多客户端连接数的问题。

方案四:订阅日志,完全解耦

把我们搭建的消费服务作为mysql的一个slave,订阅mysql的binlog日志,解析日志内容,再更新到redis。此方案和业务完全解耦,redis的更新对业务方透明,可以减少心智成本。

数据库 的面试,redis缓存一致性,redis mysql 缓存方案,mysql缓存机制,redis同步数据到mysql

优点:

  • 在同步服务压力不大情况下,延迟较低;
  • 和业务完全解耦,在更新mysql时,不需要做额外操作;
  • 解决了时序性问题,可靠性强。

缺点:

  • 要单独搭建一个同步服务,并且引入binlog同步机制,成本较大;
  • 同步服务如果压力比较大,或者崩溃了,那么在较长时间内,redis中都是老旧数据。

方案选型

  1. 首先确认产品上对延迟性的要求,如果要求极高,且数据有可能变化,别用缓存。
  2. 通常来说,方案1就够了。牛牛咨询过4、5个团队,基本都是用方案1,因为使用缓存方案,通常是读多写少场景,同时业务上对延迟具有一定的包容性。方案1虽然有一定延时,但比较实用。
  3. 如果想增加更新时的即时性,就选择方案2,不过一定要注意,针对redis老数据的删除操作不要作为关键路径,影响核心流程。
  4. 方案3、方案4均适用于对延时要求比较高的业务,其区别为前者是推模式,后者是拉模式,而后者具有更强的可靠性,且无时序性问题。既然都愿意花功夫做处理消息的逻辑,不如一步到位,用方案4!

结论

在面试中,可以直接摊牌“我有四种方案”,然后讲优势,谈场景,论选型,展现专业风采;如果遇到的是那种感觉会追问的面试官,也可以从简单讲到复杂,引导面试官一步一步追问,一点点推导,你来我往,宾主尽欢。