面试官：看你简历介绍，对redis比较熟悉哦？
小萌(看着面试官诡异的笑容，微微一颤) ：恩，还算熟悉的
面试官：好，那我们说说redis的持久化机制呗
小萌(还好，这个了解) ：经典的redis的持久化机制分为两种：rdb和aof；4.0之后，redis又提供了一种混合型的持久化机制
面试官：恩，好的，分别详细说说各自的实现机制，优缺点
小萌：rdb就是把某时刻的数据以二进制的形式固化到磁盘上，优点是二进制存储，结构压缩紧凑，方便传输，适用于备份容灾，缺点是实时性不高，单纯rdb，很难保证数据的可靠性，容易造成数据丢失；
小萌：aof则是以日志的形式记录数据的变更信息，相对于rdb，其数据实时性较高，一定程度上保证了数据的安全可靠，但是，其文件大小容易暴增，如果aof刷盘频繁的话，还会影响redis性能；
小萌(一口气说了这么多，稍微休息下)：而混合型则是在一个文件中同时使用rdb和aof格式，集上述两种的优势于一身
面试官：恩恩，那rdb备份一般什么时候进行呢？
小萌：rdb有三种触发方式。第一种，save命令触发，这种是堵塞式的，一般不推荐使用；第二种是bgsave命令触发，执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求；第三种就是根据业务情况自动触发，在某个固定时间段内，如果出现了指定次数的数据变更则进行rdb...
面试官: 恩恩，那说说aof吧？
小萌：恩，好的
(稍微回忆了下...)
aof是redis的另一种持久化机制，核心思想是以日志的形式记录所有写操作，这样，当redis宕机重启后，可以根据日志文件快速恢复数据；
面试官：恩，那按照你这么说，这个日志文件会越来越大？
小萌：恩，如果不做任何处理，是会越来越大的；针对这个问题，redis通过其aof文件重写机制来解决了这个问题
面试官：咦，有点兴趣了，能介绍下这个重写机制么？我也学习学习...
小萌(...装，你就装吧, 我可不敢随便说...)
小萌：恩，aof重写机制是这样的。当有命令触发或aof达到一定大小后，会触发aof文件重写。重写时，redis会fork一个子进程出来，在子进程中，将内存中所有数据通过redis写命令写入到一个新的aof文件；aof写完后，再删除旧的aof文件，将新的aof文件更名为旧的aof文件
面试官：恩恩，想了下啊，感觉是不是有点问题？你看啦，重写时，如果有新的数据变更了怎么办？这个子进程应该是感知不到的吧？
小萌(嘿嘿，我就知道你在装，我故意说漏了一点，如果你不懂，不可能这么快就意识到这个问题。面试官好狡猾啊，得小心点...)
小萌：恩恩，是的，这里补充一下哈；在fork后，子进程负责将内存中的数据写入新的aof文件；同时，父进程中，如果有新的数据变更，会将其变更记录写到rewrite_buf中；待子进程写完后，通过信号通知父进程，父进程收到通知后，继续将rewrite_buf中的变更信息写入到新的aof文件... 这样新的aof文件就不会缺失数据了
面试官(微微一笑)：恩，不错，学习了...好的，我们再聊聊别的东西吧
……
