我是Redis，一个叫Antirez的人把我带到了这个世界。 突然挂了！Redis缓存都在内存里，所以结束了“醒醒吧！醒醒！”隐约中，我听到有人在叫我 慢慢睁开眼睛，原来你旁边是MySQL大哥。 “我怎么睡着了？”“喂，你刚才是不是搞错了？整个过程崩溃了！好多查询请求都来找我了！”，MySQL表示 刚睡醒，脑子还有点懵，哥哥MySQL扶我起来继续工作。 “哦，不！我之前缓存的数据都没了！”“搞什么鬼？没有做到坚持吗？”，MySQL老大一听脸色都变了。 尴尬，我摇了摇头。“我都记在记忆里，所以这么快。”“那也可以保存在硬盘上。在这种情况下，我将从头开始构建缓存。不是浪费时间嘛！”突然挂了！Redis缓存都在内存里，我点点头，“让我想想，看看怎么做这个持久化。” 在RDB坚持了几天之后，我想出了一个计划:既然我在RDB的所有数据都存储在内存中，那么最简单的就是遍历一遍，然后把它们全部写入一个文件。 为了节省空间，我定义了一个二进制格式，并把数据条码放在一起生成一个RDB文件。 突然挂了！Redis缓存都在内存里，所以结束了。不过我的数据量有点大，一下子备份下来会花很多时间，所以不能太频繁，或者不用业务，花时间备份就好。 还有，如果一直没有写操作，但是都是读操作，那我就不用重复备份了，浪费时间。 我想了想，决定提供一个配置参数，可以支持定期备份，避免做无用功。 是这样的:1次写入在save 900 1 # 900秒(15分钟)，10次写入在save 300 10 # 300秒(5分钟)，10000次写入在save 60 10000 # 60秒(1分钟)。可以组合使用多个条件。只要满足以上条件，我就做备份。 后来我又想了想，还是不行。我得叉出一个子流程来做，不能浪费时间。 有了备份文件，下次我崩溃退出，甚至服务器没电了，只要我的备份文件还在，我就可以在启动时读取，快速恢复之前的状态！突然挂了！Redis缓存都在内存里，所以结束了。MySQL:binlog我拿着这个方案，兴奋地拿给大哥MySQL看，期望他能给我一点鼓励。 “老弟，你的计划有问题。”没想到，他给我泼了冷水。 “这个问题？有什么问题？”“你看，你定期去备份，周期是分钟级的。你知道我们的服务每秒要响应多少请求，你不能丢失多少数据吗？”，MySQL语重心长的说道。 突然挂了！Redis缓存都在内存里，我有点喘不过气来。“但是，这种备份必须一次遍历统一数据，开销相当大，不适合高频率执行。”“谁让你遍历一次制服数据的？来，我给你看样东西。”MySQL大哥带我去了一个文件目录:MySQL-bin . 00001 MySQL-bin . 00002 MySQL-bin . 00003...“看，这些是我的二进制日志binlog。猜猜里面有什么？”，MySQL大哥指着这堆文件说 我看了看。这都是一堆二进制数据。我无法理解。我摇摇头。 它记录了我对数据进行的所有操作，如插入、更新、删除等。，当我想要恢复数据时，它会有很大的用处。”听了他的话，我很受启发！告别MySQL大哥，回去研究新方案。 如你所知，AOF的坚持是基于命令的，我的日常工作就是响应来自业务程序的命令请求。 回来后，我决定跟着瓢，向MySQL的老大哥学习，把我执行的所有写命令都记录下来，专门写一个文件，还给这种持久化起了个名字:AOF(Append Only File) 突然挂了！Redis缓存都在内存里，所以结束了。但是我对RDB计划有同样的问题。我应该多久写一次文件？我一定不能把每个写命令都记录在文件里，那样会严重拖累我的性能！我决定准备一个缓冲区，然后把要记录的命令临时存储在这里，然后在合适的时候写文件。我把这个临时缓冲区叫做aof_buf。 突然挂了！Redis缓存都在内存里，是时候开始了。我试了一下，发现数据没有写入文件。 我多方打听得知，原来操作系统也有缓存区，我写的数据被他缓存了，所以没有写到文件里。这不是骗人的吗？好像写完了还要刷新数据。想了想，我还是给业务程序提供一个参数来设置什么时候刷新吧。 Appendfsync参数，有三个值:always:每个事件周期同步刷新；每秒钟同步刷新；不:我只是写，让操作系统决定什么时候真正写。这次我不像以前那么冲动了，决定先试用一段时间再告诉MySQL，免得再被他戳中。 试用了一段时间后，一切正常，但我发现我写的AOF备份文件随着时间的推移越来越大！不仅占用大量硬盘空间，而且复制、移动、加载分析都非常麻烦和耗时。 我得想办法压缩文件。我称这个过程为AOF重写。 突然挂了！Redis缓存全部在内存中。起初，我打算分析原始的AOF文件，然后删除多余的指令来精简AOF文件。但是很快就放弃了这个想法，工作量太大，分析起来比较麻烦，浪费了很多精力和时间。 原来一个一个记录的方式真的很蠢。数据变了，很多中间状态都没用了。为什么我不记录最终的数据状态呢？比如RPUSH name_list '编程技术宇宙' RPUSH name_list '后台技术派'可以合并成一个解决方案:RPUSH name_list '编程技术宇宙''编程技术派'后台技术派'我有重写a of文件的想法，但是还需要很长时间去做。我决定和RDB一起工作。 和我一样谨慎，发现如果我在重写子流程的过程中修改了数据，会和重写的内容不一致！大哥MySQL会找茬，我得补这个漏洞。 突然挂了！Redis缓存都在内存里，所以结束了。所以，除了之前的aof_buf: AOF重写缓冲区之外，我准备了另外一个缓冲区。 从创建重写子流程的那一刻起，我就将下面的写命令复制到这个重写缓冲区中。在子进程重写AOF文件之后，我将把这个缓冲区中的命令写入新的AOF文件。 最后，重命名新的AOF文件，替换原来臃肿的文件，最后你就完成了！突然挂了！Redis缓存全部在内存中。在一次次确定自己的思路正确后，我带着新的方案再次找到了MySQL大哥。这些我都做过。这个时候，想必，他应该无话可说了吧？我的大哥MySQL看完我的方案后露出了满意的笑容，但只问了一个问题:这个AOF方案这么好，RDB方案可以废弃吗？没想到他问了我这个问题，我陷入了沉思。你觉得我该怎么回答？鸡蛋“你怎么又坏了？”“我心情不好，又遇到bug了，不过不用担心，我现在能很快恢复！”“老故障不是问题。你只有一个太不可靠的例子。去找几个帮手吧！”