Redis到底怎么持久化，看完这个故事就明白了！

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

“快醒醒！快醒醒！”，隐隐约约，我听到有人在叫我。

慢慢睁开眼睛，原来旁边是MySQL大哥。

“我怎么睡着了？”

“嗨，你刚才是否是出现了错误，整个进程都崩溃了！害得一大堆查询请求都给我怼过来了！”，MySQL说到。

刚刚醒来，脑子还有点懵，MySQL大哥扶我起来继续工做。

“糟了！我以前缓存的数据全都不见了！”

“WTF？你没有作持久化吗？”，MySQL大哥一听脸色都变了。

我尴尬的摇了摇头，“我都是保存在内存中的，因此才那么快啊”

“那也能够在硬盘上保存一下啊，遇到这种状况所有从头再来创建缓存，这不浪费时间嘛！”

我点了点头，“让我琢磨一下，看看怎么作这个持久化”。

RDB持久化

没几天，我就拿出了一套方案：RDB

既然个人数据都在内存中存放着，最简单的就是遍历一遍把它们全都写入文件中。

为了节约空间，我定义了一个二进制的格式，把数据一条一条码在一块儿，生成了一个RDB文件。

不过个人数据量有点大，要是所有备份一次得花很多时间，因此不能太频繁的去作这事，要否则我不用干正事了，光花时间去备份了。

还有啊，要是一直没有写入操做，都是读取操做，那我也不用重复备份，浪费时间。

思来想去，我决定提供一个配置参数，既能够支持周期性备份，也能够避免作无用功。

就像这样：

• save 900 1 # 900秒（15分钟）内有1个写入
• save 300 10 # 300秒（5分钟）内有10个写入
• save 60 10000 # 60秒（1分钟）内有10000个写入

多个条件能够组合使用，只要上面一个条件知足，我就会去进行备份。

后来我又想了一下，这样仍是不行，我得fork出一个子进程去作这件事，不能浪费个人时间。

有了备份文件，下次我再遇到崩溃退出，甚至服务器断电罢工了，只要个人备份文件还在，我就能在启动的时候读取，快速恢复以前的状态啦！

MySQL:binlog

我带着这套方案，兴冲冲的拿给了MySQL大哥看了，期待他给我一些鼓励。

“老弟，你这个方案有点问题啊”，没想到，他竟给我浇了一盆冷水。

“问题？有什么问题？”

“你看啊，你这个周期性去备份，周期仍是分钟级别的，你可知道我们这服务每秒钟都要响应多少请求，像你这样不得丢失多少数据？”，MySQL语重心长的说到。

我一下有些气短了，“但是，这个备份一次要遍历所有数据，开销仍是挺大的，不适合高频执行啊”

“谁叫你一次遍历所有数据了？来来来，我给你看个东西”，MySQL大哥把我带到了一个文件目录下：

• mysql-bin.000001
• mysql-bin.000002
• mysql-bin.000003
• ···

“看，这些是个人二进制日志binlog，你猜猜看里面都装了些什么？”，MySQL大哥指着这一堆文件说到。

我看了一眼，全是一堆二进制数据，这哪看得懂，我摇了摇头。

“这里面呀记录了我对数据执行更改的全部操做，像是INSERT，UPDATE、DELETE等等动做，等我要进行数据恢复的时候就能够派上大用场了”

听他这么一说，我一下来了灵感！告别了MySQL大哥，回去研究起新的方案来了。

AOF持久化

大家也知道，我也是基于命令式的，天天的工做就是响应业务程序发来的命令请求。

回来之后，我决定照葫芦画瓢，学着MySQL大哥的样子，把我执行的全部写入命令都记录下来，专门写入了一个文件，并给这种持久化方式也取了一个名字：AOF（Append Only File）。

不过我遇到了RDB方案一样的问题，我该多久写一次文件呢？

我确定不能每执行一条写入命令就记录到文件中，那会严重拖垮个人性能！我决定准备一个缓冲区，而后把要记录的命令先临时保存在这里，而后再择机写入文件，我把这个临时缓冲区叫作aof_buf。

说干就干，我试了一下，居然发现数据没有写入到文件中去。多方打听才知道，原来操做系统也有个缓存区，我写的数据被他缓存起来了，没有给我写入到文件中去，这不是坑爹呢嘛！

看来，我写完了还得要去刷新一下，把数据真正给写下去，思来想去，我仍是提供一个参数，让业务程序去设置何时刷新吧。

appendfsync参数，三个取值：

• always: 每一个事件周期都同步刷新一次
• everysec: 每一秒都同步刷新一次
• no: 我只管写，让操做系统本身决定何时真正写入吧

AOF重写

这一次我不像以前那么冲动，我决定先试运行一段时间再去告诉MySQL大哥，省得又被他戳到软肋。

试用了一段时间，各方面都运行良好，不过我发现随着时间的推移，我写的这个AOF备份文件愈来愈大，愈来愈大！不只很是占硬盘空间，复制移动，加载分析都很是的麻烦耗时。

我得想个办法把文件给压缩一下，我把这个过程叫作AOF重写。

一开始，我打算去分析原来的AOF文件，而后将其中的冗余指令去掉，来给AOF文件瘦瘦身，不过我很快放弃了这个想法，这工做量实在太大了，分析起来也颇为麻烦，浪费不少精力跟时间。

原来的一条条记录这种方式实在是太笨了，数据改来改去，有不少中间状态都没用，我何不就把最终都数据状态记录下来就行了？

好比：

• RPUSH name_list '编程技术宇宙'
• RPUSH name_list '帅地玩编程'
• RPUSH name_list '后端技术学堂'

能够合并成一条搞定：

• RPUSH name_list '编程技术宇宙' '帅地玩编程' '后端技术学堂'

AOF文件重写的思路我是有了，不过这件事干起来仍是很耗时间，我决定和RDB方式同样，fork出一个子进程来作这件事情。

谨慎如我，发现这样作以后，子进程在重写期间，我要是修改了数据，就会出现和重写的内容不一致的状况！MySQL大哥确定会挑刺儿，我还得把这个漏洞给补上。

因而，我在以前的aof_buf以外，又准备了一个缓冲区：AOF重写缓冲区。

从建立重写子进程开始的那一刻起，我把后面来的写入命令也copy一份写到这个重写缓冲区中，等到子进程重写AOF文件结束以后，我再把这个缓冲区中的命令写入到新的AOF文件中。

最后再重命名新的AOF文件，替换掉原来的那个臃肿不堪的大文件，终于大功告成！

再三肯定个人思路没有问题以后，我带着新的方案再次找到了MySQL大哥，我都作到这份儿上了，这一次，想必他应该无话可说了吧？

MySQL大哥看了个人方案露出了满意的笑容，只是问了一个问题：

这AOF方案这么好了，RDB方案是否是能够不要了呢？

万万没想到，他竟然问我这个问题，我竟陷入了沉思，你以为我该怎么回答好呢？

彩蛋

“你怎么又崩溃了？”

“很差意思，又遇到bug了，不过不用担忧，我如今能够快速恢复了！”

“那老崩溃也不是事儿啊，你只有一个实例太不可靠了，去找几个帮手吧！”

预知详情，请关注后续精彩···