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

缓存系统交互

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

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

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

缓存系统需要处理读取场景和更新场景：

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

• 单纯读取的情况并不多，即使是读多写少的业务模型，也还是会有更新操作，由于操作 MySQL 和 Redis 并非天然的原子操作，因此需要我们特殊处理。

​

读取过程示意：

读取过程：读请求优先从缓存中获取数据，拿到后即可返回，完成交互；如缓存无数据，则从主存储拿数据，并且将数据更新回写到缓存中，为后续的读取请求做铺垫。

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

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

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

​数据不一致的感知

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

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

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

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

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

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

【文章福利】另外小编还整理了一些 C++后端开发面试题，教学视频，后端学习路线图免费分享，需要的可以自行添加：学习交流群720209036 群文件共享

小编强力推荐 C++后端开发免费学习地址：C/C++Linux服务器开发高级架构师/C++后台开发架构师​

​理性看待不一致问题

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

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

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

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

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

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

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

更新还是删除是个问题

当 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 就没淘汰，这种情况只能说确实有问题。

思路四：延时双删策略

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

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

这个方案倒是透露出一种思想：多删几次，可能一致性更有保证，那确实如此。

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

思路五：异步更新缓存

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

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

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

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

总结一下

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

• 缓存系统适用的场景：读多写少。

• 缓存系统的读写基本交互过程，读很简单，写有点复杂。

• 缓存系统写时的不一致问题有内外两个因素：外部读写的并发无序性和内部操作非原子性。

• 使用缓存系统，我们就需要接受最终一致性的前提，否则不建议用缓存。

• 解决缓存数据不一致的思路有很多，或多或少都有不足，具体用哪种，需要根据实际业务场景，没有哪种方案是普遍适用的。

原文链接：图解|高性能服务器设计之缓存系统一致性