Categories
程式開發

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章!


  

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

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

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

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

读写缓存策略一

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 1

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

策略一优缺点对比

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

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 2

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

Cache Aside 读写策略

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 3

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

读流程:首先从缓存中读取,如果有结果则直接返回结束如果缓存中没有,则读 DB 并将结果回种缓存,然后返回结束写流程:首先将将结果写入 DB然后删除缓存中对应的值

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

Cache Aside 读写策略优缺点对比

优点:从流程图看,此种策略实现比较简单。对于缓存和 DB 的一致性有了一定的保证,其可以解决第一种缓存方案遇到的问题。缺点:很显然,每次更新数据,都会先更新 DB 紧接着就删除缓存,如果读写操作都比较频繁的情况下,势必使得缓存的命中率有所折扣,也就意味着缓存的 miss 率升高,从而导致在一定程度上削弱了缓存的作用。

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

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

Write/Read Through 策略

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 4

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

读流程:首先读缓存,如果缓存命中,则直接返回结果如果缓存未命中,则依赖第三方组件从 DB 中加载数据到缓存中,然后将获取的结果返回。写流程:要更新的数据是否在缓存中存在,若存在则直接将数据写入缓存,之后缓存数据由第三方缓存组件将其更新到 DB若缓存中不存在,则直接将结果写入 DB,这种称之为写穿透

Write/Read Through 策略优缺点对

优点:写缓存 miss 的情况除外,剩余所有操作都只与缓存进行交互,很大程度上避免了缓存与 DB 一直性的情况缺点:从上面流程中不难看出,写缓存 miss 时直接与 DB 交互,会造成请求耗时增加此种缓存策略引入了第三方缓存组件进行辅助,从而增加了系统的复杂度和系统的维护难度由于需要引入第三方组件,而目前很多缓存如 Redis 原生并不兼容第三方组件,所以很难引入

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

Write Back 策略

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

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 5

写操作流程如下:写请求来之后,首先判断要写的 key 在缓存中是否被标记为“脏数据”,如果不是“脏数据”则直接写缓存,然后将其标记为脏数据如果缓存中标记的是“脏数据”,则直接将其写入 DB,然后回种缓存,然后将其标记为“脏数据”读操作流程如下:首先从缓存中获取数据,若有则直接返回若缓存中没有,则寻找可用的缓存快,若缓存快被标记为“脏数据”,则将“脏数据”写入 DB,然后将缓存的数据标记为“非脏数据”,然后返回若缓存快中的数据不是“脏数据”,则从 DB 中加载数据到缓存中,然后将其返回。

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

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

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

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

总结

本文介绍了 5 中生产环境中经常用到的缓存读写策略,读者朋友们可以根据自己的实际业务场景,对其进行适当的改造就可以应用到自己的环境中了。好了,就讲这么多,更多的需要朋友们自行多多体会和应用。下篇文章见,拜拜了您。

Redis系列(七):缓存只是读写回种这么简单吗?如果是,那么请你一定看看这篇文章! 6

  

往期推荐

Redis系列(三):缓存过期该如何剔除?RDB和AOF又是什么?

你必须要知道集群内部工作原理的一些事!

消息是如何在服务端存储与读取的,你真的知道吗?” 

一文读懂消费者背后的那点”猫腻”