大话Redis(1)

目录

Redis的诞生

Redis与Mysql的携手合作

Redis支持的数据结构存储

当Redis也遇到困难

Mysql大哥的心塞

全世界的无产Redis联合起来!!


Redis的诞生

在Redis还没诞生时,Mysql大哥过的很辛苦,互联网发展的越来越快,他容纳的数据也越来越多,用户请求也随之暴涨。而每个用户请求,都变成了对他的一个又一个的读写操作。像双十一、618这种全民购物狂欢的日子,都是Mysql受苦受难的日子。但后来发现,其实有一大半的用户请求都是读操作,而且经常都是重复查询一个东西,浪费他很多时间去进行磁盘I/O。后来有人就琢磨,是不是也可以学学CPU,给数据库也加一个缓存呢?于是Redis就诞生了。两者合作成“最强王者”

Redis与Mysql的携手合作

Redis和Mysql开始在后端服务器中相互合作,流程为:

应用程序们从mysql查询到的数据在Redis中登记一下,后面在需要用到的时候就先找Redis要

Redis支持的数据结构存储

String Hash Bitmap List Set SartedSet

Redis把登记的数据都记录在内存中,就不用去执行慢如蜗牛的I/O操作了,所以找Redis比找Mysql就省去了不少时间。

当Redis也遇到困难

随着程序的运行,Redis缓存的数据越来越多,有相当部分时间用来替Mysql挡住用户请求。但很快发现事情不妙,由于Redis缓存的数据在内存中,可不能无节制的这么存下去。于是Redis想了一个办法:给缓存内容设置一个超时时间,具体多少时间Redis不管,交给应用程序自己来。而Redis做的是将超期的内容删除掉,及时腾出空间就行。当然不可能一次性就把所有过期内容都删除掉,因为要经过扫描要花不知多久的时间,这会严重影响Redis接待新的客户请求的。时间紧任务重,于是Redis开始选择随机一部分过期内容删除,能缓解内存压力就行了。但经过一段时间后,Redis又发现有些键值运气比较好,每次都没有被它的随机算法选中,这可不行。于是Redis在原来定期删除的基础上又加了一招,那些原来逃脱我随机选择算法的键值,一旦查询请求,被Redis发现已经超期了,那就绝不客气立即删除。这种方式因为是被动式触发的,不查询就不会发生,所以也叫惰性删除。可是再经过一段时间,发现有些键值既逃过了随机算法又一直没有被查询,导致他们一直逍遥法外,而与此同时,可以使用的内存空间却越来越少。

而且退一步讲,就算把过期的数据都删除掉,那万一过期时间设置的很长,还没等到去清理,内存就吃满了。所以Redis又憋了个大招,使用内存淘汰策略:提供八种淘汰策略供应用程序选择,用于Redis遇到内存不足时该如何决策

Redis用这三套组合拳,就再也不用担心把内存撑满的问题了。

Mysql大哥的心塞

1.另一边的Mysql大哥就没Redis这么舒坦了。有时候遇到些烦人的请求,查询的数据不存在,Mysql就要白忙活一场,不仅如此,因为数据不存在,Redis也没法缓存,导致同样的请求来了,每次都要让Mysql大哥白忙活一场,Redis作为缓存的价值就没有体现了,这就是人们常说的缓存穿透

2.还有一次,Mysql大哥好不容易摸鱼了一把,突然一大堆请求给他怼了过去,给他打了个措手不及,一阵忙活后,Mysql怒气冲冲找到了Redis:

这便是缓存击穿

但Redis此时还没放在心上,于是之后捅了更大的篓子......

3.在发生缓存击穿后的又一天,又出现了大量的网络请求发到了Mysql大哥那边,比上次规模大得多,搞得Mysql大哥一会功夫就被干趴下了好几次,等到好半天这波流量才算过去,Mysql才缓过神了,又找到了Redis:

一起协商后,决定再新增两条策略:不仅把键值的过期时间随机了一下,还设置了热点数据永不过期。于是安稳的日子又持续了一段时间,可后来......

4.有一次Redis在努力工作中,不小心出了错,整个进程都崩溃了,当再次启动时,之前缓存的数据全都没了,暴风雨式的用户请求再一次全都怼到了Mysql大哥那里,被它喷了个狗血淋头。

Redis立马拿出了一套方案:RDB。既然数据全都存放在内存中,最简单的就是全部遍历一遍,把它们全部写入文件中,为了节约空间,Redis定义了二进制格式,把数据一条一条码在一起,生成了一个RDB文件,不过数据量有点大,要是全部备份一次得花不少时间,所以不能花太多时间干这事,要不然就不用干正事了。于是Redis提供了一个配置参数,既可以支持周期性备份,也可以避免作无用功,就像这样:

后来Redis又想了下,还创建了个子进程来替他做这件事,以节省时间。以后断电甚至服务器崩了,只要备份文件还在,就能在启动的时候读取快速恢复之前的状态。之后Redis将这套方案拿给了Mysql大哥看:

经过对话后,Redis有了灵感,拿起了新的方案:AOF持久化

Redis在这其中不断优化,崩发出了耕更多的灵感:如AOF重写(压缩)、指令合并

最后fork一个子进程替自己干这些事,AOF持久化大功告成

Redis再次将方案拿给了Mysql大哥:

Mysql大哥也是问了问,让我自己思考。总之,这段风波暂时是过去了。

但后面还有个问题又来了:

全世界的无产Redis联合起来!!

有一次,Redis基友群里,许久未见的大白发了一条消息:

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

蜗牛变涡流

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值