关于redis:P8架构师详解Redis-在-MySql-中的优化历程

36次阅读

共计 2511 个字符,预计需要花费 7 分钟才能阅读完成。

本文章转自:乐字节

文章次要解说:Redis 在 MySql 中的优化历程

获取更多 Java 相干常识能够关注公众号《乐字节》发送:999

我是 Redis

你好,我是 Redis,一个叫 Antirez 的男人把我带到了这个世界上。

说起我的诞生,跟关系数据库 MySQL 还挺有渊源的。
在我还没来到这个世界上的时候,MySQL 过的很辛苦,互联网倒退的越来越快,它包容的数据也越来越多,用户申请也随之暴涨,而每一个用户申请都变成了对它的一个又一个读写操作,MySQL 是苦不堪言。尤其是到“双 11”、“618“这种全民购物狂欢的日子,都是 MySQL 受苦受难的日子。
据起初 MySQL 通知我说,其实有一大半的用户申请都是读操作,而且常常都是反复查问一个货色,节约它很多工夫去进行磁盘 I /O。
起初有人就推敲,是不是能够学学 CPU,给数据库也加一个缓存呢?于是我就诞生了!
出世不久,我就和 MySQL 成为了好敌人,咱们俩经常携手呈现在后端服务器中。
应用程序们从 MySQL 查问到的数据,在我这里注销一下,前面再须要用到的时候,就先找我要,我这里没有再找 MySQL 要。

因为我把注销的数据都记录在内存中,不必去执行慢如蜗牛的 I / O 操作,所以找我要比找 MySQL 要省去了不少的工夫呢。
可别小瞧这简略的一个扭转,我可为 MySQL 加重了不小的累赘!随着程序的运行,我缓存的数据越来越多,有相当局部工夫我都给它挡住了用户申请,这一下它可乐得清闲自在了!
有了我的退出,网络服务的性能晋升了不少,这都归功于我为数据库挨了不少枪子儿。

缓存过期 && 缓存淘汰

不过很快我发现事件不妙了,我缓存的数据都是在内存中,可是就算是在服务器上,内存的空间资源还是很无限的,不能无节制的这么存上来,我得想个办法,不然吃枣药丸。
不久,我想到了一个方法:给缓存内容设置一个超时工夫,具体设置多长交给应用程序们去设置,我要做的就是把过期了的内容从我外面删除掉,及时腾出空间就行了。

超时工夫有了,我该在什么时候去干这个清理的活呢?
最简略的就是定期删除,我决定 100ms 就做一次,一秒钟就是 10 次!
我清理的时候也不能一口气把所有过期的都给删除掉,我这外面存了大量的数据,要全面扫一遍的话那不晓得要花多久工夫,会重大影响我接待新的客户申请的!
工夫紧工作重,我只好随机抉择一部分来清理,能缓解内存压力就行了。

就这样过了一段日子,我发现有些个键值运气比拟好,每次都没有被我的随机算法选中,每次都能幸免于难,这可不行,这些长时间过期的数据始终霸占着不少的内存空间!气抖冷!
我眼里可揉不得沙子!于是在原来定期删除的根底上,又加了一招:
那些原来逃脱我随机抉择算法的键值,一旦遇到查问申请,被我发现曾经超期了,那我就绝不客气,立刻删除。
这种形式因为是被动式触发的,不查问就不会产生,所以也叫惰性删除!
可是,还是有局部键值,既逃脱了我的随机抉择算法,又始终没有被查问,导致它们始终绳之以法!而于此同时,能够应用的内存空间却越来越少。

而且就算退一步讲,我可能把过期的数据都删除掉,那万一过期工夫设置的很长,还没等到我去清理,内存就吃满了,一样要吃枣药丸,所以我还得想个办法。
我苦思好久,终于憋出了个大招:内存淘汰策略,这一次我要彻底解决问题!
我提供了 8 种策略供应用程序抉择,用于我遇到内存不足时该如何决策:

有了下面几套组合拳,我再也不必放心过期数据多了把空间撑满的问题了~

缓存穿透 && 布隆过滤器

我的日子过的还挺舒坦,不过 MySQL 大哥就没我这么舒坦了,有时候遇到些烦人的申请,查问的数据不存在,MySQL 就要白忙活一场!不仅如此,因为不存在,我也没法缓存啊,导致同样的申请来了每次都要去让 MySQL 白忙活一场。我作为缓存的价值就没失去体现啦!这就是人们常说的缓存穿透。

这一来二去,MySQL 大哥忍不住了:“唉,兄弟,能不能帮忙想个办法,把那些明晓得不会有后果的查问申请给我挡一下”
这时我想到了我的另外一个好敌人:布隆过滤器。

我这位敌人别的本事没有,就善于从超大的数据集中疾速通知你查找的数据存不存在(轻轻通知你,我的这位敌人有一点不靠谱,它通知你存在的话不能全信,其实有可能是不存在的,不过它他要是通知你不存在的话,那就肯定不存在)。

如果你对我这位敌人感兴趣的话,能够看看这里《文言布隆过滤器 BloomFilter》。
我把这位敌人介绍给了应用程序,不存在的数据就不用去叨扰 MySQL 了,轻松帮忙解决了缓存穿透的问题。

缓存击穿 && 缓存雪崩

这之后过了一段时间太平日子,直到那一天···
有一次,MySQL 那家伙正优哉游哉的摸鱼,忽然一大堆申请给他怼了过来,给他打了一个措手不及。
一阵忙活之后,MySQL 火冒三丈的找到了我,“兄弟,咋回事啊,怎么一下子来的这么猛”

我查看了日志,连忙解释到:“大哥,切实不好意思,刚刚有一个热点数据到了过期工夫,被我删掉了,不巧的是随后就有对这个数据的大量查问申请来了,我这里曾经删了,所以申请都发到你那里来了”
“你这干的叫啥事,下次留神点啊”,MySQL 大哥一脸不快乐的来到了。
这一件小事我也没怎么放在心上,随后就抛之脑后了,却没曾想几天之后竟捅了更大的篓子。
那一天,又呈现了大量的网络申请发到了 MySQL 那边,比上一次的规模大得多,MySQL 大哥一会儿功夫就给干趴下了好几次!
等了好半天这一波流量才算过来,MySQL 才缓过神来。
“老弟,这一次又是什么起因?”,MySQL 大哥累的没了力量。
“这一次比上一次更不巧,这一次是一大批数据简直同时过了有效期,而后又产生了很多对这些数据的申请,所以比起上一次这规模更大了”

MySQL 大哥听了眉头一皱,“那你倒是想个办法啊,三天两头折磨我,这谁顶得住啊?”
“其实我也很无奈,这个工夫也不是我设置的,要不我去找应用程序说说,让他把缓存过期工夫设置的平均一些?至多别让大量数据个体生效”
“走,咱俩一起去”
起初,我俩去找应用程序磋商了,不仅把键值的过期工夫随机了一下,还设置了热点数据永不过期,这个问题缓解了不少。哦对了,咱们还把这两次产生的问题别离取了个名字:缓存击穿和缓存雪崩。
咱们终于又过上了舒服的日子···

感激大家的认同与反对,小编会继续转发《乐字节》优质文章

正文完
 0