查看原文
其他

哎,这要人老命的缓存一致问题啊!!!

大白 why技术 2021-05-07

1缓存系统交互

缓存系统设计是后端开发人员的必备技能,也是实现高并发的重要武器。

对于读多写少的场景,我们通常使用内存型数据库作为缓存,关系型数据库作为主存储,从而形成两层相互依赖的存储体系。

共识:我们将使用Redis和MySQL作为缓存和主存的实体,展开今天的话题。

缓存系统的读取场景更新场景

  • 读取时只要之前MySQL和Redis中的数据是一致的,后续只要没有更新操作就不会有什么问题,同时借助于内存来提高并发能力,这也是我们设计缓存系统的初衷。

  • 对于读多写少的业务模型,由于操作MySQL和Redis并非天然的原子操作,会造成数据的不一致,需要特殊处理。

读取过程示意:

读取过程:读请求优先从缓存中获取数据,拿到后即可返回;如缓存无数据,则从主存储拿数据,并且将数据更新到缓存中,为后续的读取请求做铺垫。

更新过程之所以会出现数据不一致问题,有内外两大原因

  • 内部原因:Redis和MySQL的更新不是天然的原子操作,非事务性的组合拳。
  • 外部原因:实际中的读写请求是并发且无序的,可预测性很差,完全不可控。

2数据不一致的感知

我们来看个实际中的例子,进一步了解缓存系统的数据不一致问题。

平时上下班挤地铁的时候,我们经常会听网易云,比如我喜欢听民谣,所有会关注官方发布的一些民谣歌曲榜单,如图:

歌单是网易云的运营同学配置的,作为用户我们是无法修改的歌单的内容的,所以这是个非常典型的读多写少的场景。

所以假如我是网易云的后端同学,我肯定会把歌单的信息存储在Redis中,缓存下来提高性能,大概可以是这个样子:

假如因为版权问题,运营删除了一首歌,此时更新了MySQL,但是Redis中的数据并没有及时被更新,那么就会有一少部分用户在歌单中看到本已被删除的歌曲,点击时可能无法播放等。

画外音这就是缓存和主存储的数据不一致的现象,当然具体网易云是咋实现的,咱也不清楚,上述的场景纯属作者脑补来说明不一致问题的直观实例。

3理性看待不一致问题

数据一致性可以说是分布式系统中必然存在的问题,数据一致性可以分为:

  • 强一致性:时时刻刻保持一致。
  • 最终一致性:允许短暂的不一致,但是最后还是一致的。

要实现缓存和主存储的强一致性,需要借助于复杂的分布式一致性协议等,倒不如不用缓存,毕竟缓存的优势还是读多写少的场景。

画外音:缓存并不是什么万金油,对于写多读少的场景,或许并不是适合用缓存。

工程和学术是有区别的,因此我们后续的问题都是围绕最终一致性展开的,因为这才是有意义的问题。

进而我们将问题转化为:

研究重点:在保证数据最终一致性的前提下,如何把数据不一致带来的影响降低到业务可接受的范围内?

4更新还是删除是个问题

当MySQL被更新时,我们如何处理Redis呢?

  • 直接将key淘汰掉,是否再次被加载由后续读请求决定。
  • 直接update发生变化的key,相当于帮后面的请求做了加载的操作。

可以明确一点删除操作直接操作就行(简单明了),但是更新操作可能涉及的处理步骤更多,也就是update可能比delete更复杂。

另外,我们需要尽量保证Redis中的数据都是热数据,update每次都会使得数据驻留在Redis中,或许这是没有必要的,因为这些可能是冷数据,至于要加载哪些数据,还是交给后面的请求比较合适,各司其职。

综上,我们更倾向于将delete作为通用的选择,因此后续都是基于淘汰缓存来展开的。

5如何解决不一致问题

Redis和MySQL的数据不一致产生的根源是业务需要进行更新(写入)操作

先操作Redis 还是 先操作MySQL是个问题,操作时序不同产生的影响也不同。

尺有所短,寸有所长,说到底是一种权衡,哪一种组合产生的负面影响对业务最小,就倾向于哪种方案。

缓存系统的数据不一致问题,是个经典的问题,因此肯定有很多解决问题的套路,所以让我们带着分析和思考去看看,各个方案的利弊。

思路一:设置缓存过期时间

当向Redis写入一条数据时,同时设置过期时间x秒,业务不同过期时间不同。

过期时间到达时Redis就会删掉这条数据,后续读请求Redis出现Cache Miss,进而读取MySQL,然后把数据写到Redis。

如果发生更新操作时,只操作MySQL,那么Redis中的数据更新就只是依赖于过期时间来保底,淘汰后再被加载就是新数据了。

画外音:这种方案是最简单的,如果业务对短时间不一致问题并不在意,设置过期时间的方案就足够了,没有必要搞太复杂。

思路二:先淘汰缓存&再更新主存

进行更新操作时,为了防止其他线程读到缓存中的旧数据,干脆淘汰掉,然后把数据更新到主存储,后续的请求再次读取时触发Cache Miss,从而读取MySQL再将新数据更新到Redis。

  • 在T1时刻:Redis和MySQL对于age的值都是18,二者一致;

  • 在T2时刻:有更新请求需要设置age=20,此时Redis中就没有age这个数据了;在完成Redis淘汰后,进行MySQL数据更新age=20;

这个方案听着还不错的样子,但是读写请求都是并发的,先后顺序完全无法预测,甚至后发出的请求先处理完成,也是很常见的。

可见一个明显的漏洞:在淘汰Redis的数据完成后,更新MySQL完成之前,这个时间段内如果有新的读请求过来,发现Cache Miss了,就会把旧数据重新写到Redis中,再次造成不一致,并且毫无察觉后续读的都是旧数据。

画外音:这个方案其实不能说完全没有用,但是至少不完美吧。

思路三:先更新主存&再淘汰缓存

进行更新操作时,先更新MySQL,成功之后,淘汰缓存,后续读取请求时触发Cache Miss再将新数据回写Redis。

这种模式在更新MySQL和淘汰Redis这段时间内,请求读取的还是Redis的旧数据,不过等MySQL更新完成,就可以立刻恢复一致,影响相对比较小。

上述是在缓存中有数据的情况,也就是T2时刻的读请求没有触发Cache Miss,也就不会更新缓存,因此问题不大。

但是,假如T2时刻读取的数据在缓存没有,那么触发Cache Miss后会产生回写,假如这个回写动作是在T4时刻完成,那么写入的还是老数据,如图(注:T2标注和描述有误,详评论区):

这种情况确实有问题,但是真是太巧了吧,分析一下:

  • 事件A:淘汰Redis前来了一个读请求;
  • 事件B:T2时刻的读请求触发了Cache Miss;
  • 事件C:回写Redis发生在淘汰缓存之后;

那么发生问题的概率就是P(A)*P(B)*P(C),从实际考虑这种综合事件发生的概率非常低,因为写操作远慢于读操作,也就是图上的T4事件大概率是发生在T3事件之前的。

画外音:先更新MySQL再淘汰Redis的方案,虽然存在小概率不一致问题,但是总体来说工程上是可用的,比如非要说写完MySQL挂了,Redis就没淘汰,这种情况只能说确实有问题。

思路四:延时双删(淘汰)

前面提到的思路二和思路三都只有一次Redis淘汰操作,这里要说的延时双删本质上是思路二和思路三的结合:

说实话个人觉得,这个方案有点堆操作的感觉,而且设置延时的目的是为了避免思路三的小概率问题,延时设置多久不好确定,二来延时降低了并发性能,同时前置的删除缓存操作起到的作用并不大。

这个方案倒是透露出一种思想:多删几次,可能一致性更有保证,那确实如此,但是命中率也就低了,命中率和一致性看来也是一对矛盾。

画外音:这个方案也不是说不行,其实有点麻烦,并且在复杂高并发场景中反而影响性能,要是一般的场景或许也能用起来。

思路五:异步更新缓存

既然直接操作MySQL和Redis都多少存在一些问题,那么能不能引入中间层来解决问题呢?

把MySQL的更新操作完成后不直接操作Redis,而是把这个操作命令(消息)扔到一个中间层,然后由Redis自己来消费更新数据,这是一种解耦的异步方案。

单纯为了更新缓存引入中间件确实有些复杂,但是像MySQL提供了binlog的同步机制,此时Redis就作为Slave进行主从同步,实现数据的更新,成本也还可以接受。

画外音:引入中间层思想真是万金油啊!

6 总结一下

本文主要介绍了以下几个关键内容:

  • 缓存系统适用的场景:读多写少。
  • 缓存系统的读写基本交互过程,读很简单,写有点复杂。
  • 缓存系统写时的不一致问题有内外两个因素:外部读写的并发无序性和内部操作非原子性。
  • 使用缓存系统,我们就需要接受最终一致性的前提,否则不建议用缓存。
    解决缓存数据不一致的思路有很多,或多或少都有不足,具体用哪种,需要根据实际业务场景,没有哪种方案是普遍适用的。

7why哥说

这篇文章转载自公众号【后端技术指南针】,作者大白经过半年的蛰伏,现在要强势回归了,建议大家关注一波。本首即可直达其公众号。

他写的这篇文章,讨论的是一个我一直想写却找不到合适的切入口的文章。

因为缓存一致性问题,在我心里,一度是一个“引战的问题,下面这个截图我是截取的好几次关于这个话题的讨论,拼凑而成:


然后在有一次的讨论中,有一个群友发出了这样的一段话:


以后如果面试的时候遇到了这样的问题,你就把前面的方案都回答出来,然后再用这句话,去做总结,应该算的上是一个趋近于满分的回答了吧




推荐👍 :当我看技术文章的时候,我在想什么?
推荐👍 :真是绝了!这段被JVM动了手脚的代码!
推荐👍 :知乎的一次29.7元的咨询
推荐👍 :面试官一个线程池问题把我问懵逼了。
推荐👍 :这个Bug的排查之路,真的太有趣了。

我是 why,一个主要写代码,经常写文章,偶尔拍视频的程序猿。

欢迎关注我呀。

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存