大话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基友群里，许久未见的大白发了一条消息：