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

缓存系统交互

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

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

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

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

• 读取时只要之前MySQL和Redis中的数据是一致的，后续只要没有更新操作就不会有什么问题，借助于内存读取速度来提高并发能力，这也是我们设计缓存系统的初衷。
• 单纯读取的情况并不多，即使是读多写少的业务模型，也还是会有更新操作，由于操作MySQL和Redis并非天然的原子操作，因此需要我们特殊处理。

读取过程示意：

读取过程：

读请求优先从缓存中获取数据，拿到后即可返回，完成交互；

如缓存无数据，则从主存储拿数据，并且将数据更新回写到缓存中，为后续的读取请求做铺垫。

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

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

数据不一致的感知

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

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