论Redis持久化

        Redis支持RDB和AOF两种持久化机制。持久化功能有效地避免因进程退出造成的数据丢失问题，下次重启时利用之前持久化的文件即可实现数据恢复。
        Redis持久化方式:
                RDB（Redis DB）
                AOF（AppendOnlyFile）

一、RDB

        RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
        在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中
方式：产生一个RDB:

   a. 阻塞方式：SAVE
              客户端中执行save命令,阻塞Redis服务，无法响应客户端请求
   b. 非阻塞方式： bgsave（复杂度高）
             Redis服务正常接收处理客户端请求,
              Redis会fork()一个新的子进程来创建RDB文件，
              子进程处理完后会向父进程发送一个信号，
              通知它处理完毕,父进程用新的dump.rdb替代旧文件
              
   自动触发：按照配置文件中的条件满足就执行BGSAVE,save 60 1000，
            Redis要满足在60秒内至少有1000个键被改动，会自动保存一次
 
   手动触发：客户端发起SAVE、BGSAVE命令

    SAVE 和 BGSAVE 命令
        SAVE不用创建新的进程，速度略快
        BGSAVE需要创建子进程，消耗额外的内存
        SAVE适合停机维护，服务低谷时段
        BGSAVE适合线上执行

        在进行快照操作的这段时间，如果发生服务崩溃怎么办？很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。

RDB优点
        完全备份，不同时间的数据集备份可以做到多版本恢复
        紧凑的单一文件，方便网络传输，适合灾难恢复
        恢复大数据集速度较AOF快
RDB缺点

        会丢失最近写入、修改的而未能持久化的数据
        fork过程非常耗时，会造成毫秒级不能响应客户端请求

二、AOF

        AOF：以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的。主要作用：解决了数据持久化的实时性。调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多。
AOF写入机制

        AOF方式不能保证绝对不丢失数据,目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

写入磁盘的策略
        appendfsync选项，这个选项的值可以是always、everysec或者no
        always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
        everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
        no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的

运行速度：always的速度慢，everysec和no都很快

AOF重写机制
AOF文件过大,合并重复的操作，AOF会使用尽可能少的命令来记录

重写过程:如下图

1、执行AOF重写请求
2、父进程执行fork创建子进程，开销等同于bgsave过程
3.1、主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区，并根据appendfsync策略同步到磁盘，保证原有AOF机制正确性。
3.2、由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4、子进程根据内存快照，按照命令合并规则写入到新AOF文件。每次批量写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
5.1、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
5.2、父进程把AOF重写缓冲区数据写入到新的AOF文件。
5.3、使用新AOF文件替换老文件，完成AOF重写。

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

AOF优点
        写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
重写机制，优化AOF文件
        如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
AOF缺点
        相同数据集，AOF文件体积较RDB大了很多
        恢复数据库速度比RDB慢（文本，命令重演）