Redis系列（七）：缓存只是读写回种这么简单吗？如果是，那么请你一定看看这篇文章！

[导读] 作者：z小赵 ★ 一枚用心坚持写原创的“无趣”程序猿，在自身受益的同时也让朋友们在技术上有所提升。前面利用 6 篇文章讲述了 Redis 相关的基础知识，相信小伙伴们对 Redis 已经有了一个比较深入的认识和理解了；本文来讲讲实际生产环境中 Redis 作为常

作者：z小赵

一枚用心坚持写原创的“无趣”程序猿，在自身受益的同时也让朋友们在技术上有所提升。

前面利用 6 篇文章讲述了 Redis 相关的基础知识，相信小伙伴们对 Redis 已经有了一个比较深入的认识和理解了；本文来讲讲实际生产环境中 Redis 作为常用缓存组件是怎么和 DB（关系型数据库，比如 MySQL）配合使用的。

看到这里可能有些朋友会内心肯定会淡淡的说上一句：写操作先更新 DB，然后在更新缓存，读操作先读缓存，如果没有读 DB 回种缓存，然后返回结果不就完事了么，这有什么好讲的？

只要你有这样的疑问，那么请你一定认真看完本文，因为缓存读写策略远不止你想的那么简单，下面我们就来分析一下几种常用的缓存读写方案，看看哪种更适合你。

读写缓存策略一

如上图所示，对于写操作，先写 DB，如果 DB 成功，则同步写入缓存；对于读操作，首先从缓存中读取，若缓存未命中，则从 DB 中获取，如果取到了结果，将结果回种缓存并返回，若 DB 中也没有结果，则在缓存中设置一个短暂带有过期时间的空值，防止相同 key 频繁请求对 DB 造成大量的无效请求。

策略一优缺点对比

优点

缓存读写策略简单（在很多读多写少的场景中，此种策略使用的频率还是很高的）。
不需要依赖其他第三方缓存组件协同完成。

缺点

举个例子，如上图所示，假设两条线程 1 和线程 2 同时对一件特价商品进行价格调整，假设商品初始状态为 20 元，线程 1 将其价格修改为 19 元并写入缓存，然后线程 2 将商品的价格修改为 18 元，此时线程 A 进行读取操作，因为线程 2 还没来得及将缓存数据修改为 18，所以此时线程 1 拿到的价格为 19 元，但是此时库里的价格却是 18 元。从这个例子可以看出，对于进行频繁修改的数据，使用此种缓存读写策略显然是不合理的。针对这种缓存读写方案的缺陷，我们来看看下一种缓存读写策略。

Cache Aside 读写策略

Cache Aside 读写策略也叫缓存旁路读写策略，从上图可以看出，针对读写的策略分别是：

读流程：

首先从缓存中读取，如果有结果则直接返回结束
如果缓存中没有，则读 DB 并将结果回种缓存，然后返回结束

写流程：

首先将将结果写入 DB
然后删除缓存中对应的值

实际生产环境中，此种策略的使用也相对比较广泛，可以作为一种参考。这里需要注意一点的是，针对写流程，不能先删除缓存，在更新 DB，因为缓存删除后，此时 DB 还没有更新完时，来了一个 get 请求，那么缓存就有可能会被种入一个已失效的结果。

Cache Aside 读写策略优缺点对比

优点：

从流程图看，此种策略实现比较简单。
对于缓存和 DB 的一致性有了一定的保证，其可以解决第一种缓存方案遇到的问题。

缺点：

很显然，每次更新数据，都会先更新 DB 紧接着就删除缓存，如果读写操作都比较频繁的情况下，势必使得缓存的命中率有所折扣，也就意味着缓存的 miss 率升高，从而导致在一定程度上削弱了缓存的作用。

针对此种方案的缺点，其实也有一些比较折中的方案可以考虑。比如在更新 DB 完成后，同样更新缓存，但是在更新缓存的时候增加分布式锁避免；在比如如果业务场景并不是要求强一致性的话，可以将数据写入缓存并增加一个过期时间，这样即使数据不一致也只是一段时间。

对于增加过期时间的这种方式，存在极热 key 的场景并不是适用的，因为一旦 key 过期后，在一瞬间大量请求越过缓存，直冲 DB，也就造成了缓存穿透的问题，所以 Cache Aside 方案看起来很不错，但是也不是万能的。

Write/Read Through 策略

Write/Read Through 的缓存策略不同于前两种，该策略需要引入第三方缓存同步插件。其读写流程如下：

读流程：

首先读缓存，如果缓存命中，则直接返回结果
如果缓存未命中，则依赖第三方组件从 DB 中加载数据到缓存中，然后将获取的结果返回。

写流程：

要更新的数据是否在缓存中存在，若存在则直接将数据写入缓存，之后缓存数据由第三方缓存组件将其更新到 DB
若缓存中不存在，则直接将结果写入 DB，这种称之为写穿透

Write/Read Through 策略优缺点对比

优点：

写缓存 miss 的情况除外，剩余所有操作都只与缓存进行交互，很大程度上避免了缓存与 DB 一直性的情况

缺点：

从上面流程中不难看出，写缓存 miss 时直接与 DB 交互，会造成请求耗时增加
此种缓存策略引入了第三方缓存组件进行辅助，从而增加了系统的复杂度和系统的维护难度
由于需要引入第三方组件，而目前很多缓存如 Redis 原生并不兼容第三方组件，所以很难引入

总和上面这些情况对比，目前采用此种缓存读写策略的场景很少，作者到目前还没有见过使用这种缓存策略的场景。

Write Back 策略

Write Back 策略是一种操作系统在使用的缓存读写策略，由于其实现比较复杂，所以读者朋友可以做一些了解即可，目前没有在生产环境中实际使用过。

写操作流程如下：

写请求来之后，首先判断要写的 key 在缓存中是否被标记为“脏数据”，如果不是“脏数据”则直接写缓存，然后将其标记为脏数据
如果缓存中标记的是“脏数据”，则直接将其写入 DB，然后回种缓存，然后将其标记为“脏数据”

读操作流程如下：

首先从缓存中获取数据，若有则直接返回
若缓存中没有，则寻找可用的缓存快，若缓存快被标记为“脏数据”，则将“脏数据”写入 DB，然后将缓存的数据标记为“非脏数据”，然后返回
若缓存快中的数据不是“脏数据”，则从 DB 中加载数据到缓存中，然后将其返回。

生产环境中其他的缓存读写策略

除了上面我们介绍的 4 中缓存读写策略，实际生产环境中还有一些比较常见的策略，比如针对热点 key 使用的 LRU 缓存策略。

实际生产中，某些场景数据量是非常巨大的，比如微博用户 uid，方便查看某个用户的最近状态，如果全部将其全部都写入到缓存，显然是不合理的；一是缓存存储不了那么多用户信息，二是对应绝大部分用户是完全没有必要写入缓存的，因为对于很大一部分用户信息，只有很少的访问量。所以对于这种场景，只需要缓存最近经常被访问的那部分用户信息即可，针对这种场景，也就诞生了 LRU 缓存。

其实 LRU 缓存在很多框架中也被广泛使用，需要的朋友可以自己研究下很简单的（这里其实也有有一道算法题，感兴趣的朋友可以自行在 LeetCode 上搜索）