图解｜高性能服务器设计之缓存系统一致性

• 内部原因：Redis和MySQL的更新不是天然的原子操作，非事务性的组合拳。

• 外部原因：实际中的读写请求是并发且无序的，可预测性很差，完全不可控。

数据不一致的感知

========

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

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

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

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

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

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

理性看待不一致问题

=========

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

• 强一致性：时时刻刻保持一致。

• 最终一致性：允许短暂的不一致，但是最后还是一致的。

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

画外音：缓存并不是什么万金油，对于写多读少的场景，或许并不是适合用缓存，劝大家不要唯缓存论。

在工程上大部分场景下最终一致性就足够了，因此我们将问题转化为：

在保证数据最终一致性的前提下，如何把数据不一致带来的影响降低到业务可接受的范围内。

=========================================

更新还是删除是个问题

==========

当MySQL被更新时，我们如何处理Redis中的老数据呢？

江湖上有两种常见的做法，我们一起来看看：

• 删除操作 ：直接将key淘汰掉，是否再次被加载由后续读请求决定，本次只负责删除，只管杀不管埋。

• 更新操作 ：直接update发生变化的key，相当于帮后面的请求做了加载的操作，管杀管埋。

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

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

综上，我们更倾向于将delete操作作为通用的选择，因此文章后续都是基于删除缓存的策略来展开的。

如何解决不一致问题

=========

Redis和MySQL的数据不一致产生的根源是: 业务进行更新/写入操作 。

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

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

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

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

============

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

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

如果发生更新操作时，只操作MySQL，那么Redis中的数据更新就只是依赖于过期时间来保底。

换句话说： 如果某个key的数据目前在缓存中，当数据发生更新时，只写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更新完成，就可以立刻恢复一致，影响相对比较小。

但是，假如T0时刻读取的数据在缓存没有，那么触发Cache Miss后会产生回写，假如这个回写动作是在T4时刻完成，那么写入的还是老数据，如图：

这种情况确实有问题，但是真是好巧不巧：

• 事件A：更新MySQL前出现一个读请求，且缓存中无数据出现cache miss

• 事件B：T3时刻回写Redis的操作才完成，在此之前T2时刻清除了缓存

那么发生问题的概率就是P(A)*P(B)，从实际考虑这种综合事件发生的概率非常低，因为写操作远慢于读操作。

也就是实际场景中上图中更新MySQL&淘汰缓存的操作耗时更久，可以把之前回写到Redis老数据给清除掉。

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

思路四：延时双删策略

==========

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

Java架构进阶面试及知识点文档笔记

这份文档共498页，其中包括Java集合，并发编程，JVM，Dubbo,Redis，Spring全家桶，MySQL，Kafka等面试解析及知识点整理

Java分布式高级面试问题解析文档

其中都是包括分布式的面试问题解析，内容有分布式消息队列，Redis缓存，分库分表，微服务架构，分布式高可用，读写分离等等！

互联网Java程序员面试必备问题解析及文档学习笔记

Java架构进阶视频解析合集
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
库分表，微服务架构，分布式高可用，读写分离等等！

[外链图片转存中…(img-yVZpPmBf-1713599318703)]

互联网Java程序员面试必备问题解析及文档学习笔记

[外链图片转存中…(img-36iz3YEf-1713599318703)]

Java架构进阶视频解析合集
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！