Redis持久化方案RDB和AOF

Redis提供了两种持久化方式RDB和AOF

RDB

     RDB(Redis DataBase): RDB就是在不同的时间点，将redis存储的数据生成的快照保存在磁盘等介质上。

     RDB的工作原理：在进行持久化时，会将数据写入到临时文件当中，等到持久化过程结束了，会将这个临时文件替换掉上次持久化的文件。因此，我们随时都可以进行备份。

     redis会fork一个子进程来进行备份，主进程是不会进行任何IO操作的，所以就可以保证redis极高的性能。

     如果需要大量的持久化，同时对数据的完整性要求不是很高的话，可以采用RDB的方式进行持久化，当然缺点也是比较明显，如果每五分钟进行一次持久化，那么在五分钟内系统down掉了，那么就会丢失这5分钟的数据。

AOF

     AOF(Append Only File)是从另外一个角度进行持久化，将redis所执行的指令都记录下来，在下次redis重启时，只需要把这些写指令重新执行一遍就可以了。

   通过修改配置文件，redis.conf 中的appendonly为yes就可以打开AOF功能。默认的AOF是每秒进行一次fsync（将写指令记录到磁盘中），在这种情况下，如果redis服务down掉，最多只会丢失一秒钟的数据。

   AOF的同步策略

    每秒同步：每秒钟进行一次数据同步，这个操作是异步的，如果在发生故障时，最多会丢失一秒内的数据

    修改同步：每当对数据进行修改就会进行一次持久化，这种策略下效率比较低，但是数据的安全性高。

    不同步：不使用AOF进行持久化

   如果AOF一直进行追加，满了之后怎么办？

     redis提供了重写机制，当AOF文件超过了设定的阙值之后，就会进行一次AOF内容压缩，只保留恢复数据的最小指令，举个例子，如果对某个数据执行了100次incr，那么再重写时就会将其进行压缩，改为一条set指令。

     AOF在进行文件重写时，采用的是先写入到临时文件，然后再替换，所以意外情况下都不会影响AOF的可用性。

    如果执行了bgrewriteaof命令，那么redis会生成一个全新的aof文件，保存了数据的最小指令集。

    如果AOF文件被写坏了，怎么处理

   1、先拷贝一份写坏的aof文件出来

   2、运行redis-check-aof-fix进行修复。

   3、采用diff -u对比修改点，然后确认问题

   4、重启redis运行修复后的aof文件。

  AOF重写的工作原理

    1、 在准备重写之前，先fork出来一个子进程，子进程读取现有的aof文件，将其包含的指令分析压缩到一个临时文件当中。

    2、在这个时候，主工作进程会将接收到的新指令一边累积到内存缓冲区当中，一边追加到原有的AOF文件当中，避免在重写过程中发生意外，导致数据丢失

    3、重写子进程在执行完操作之后，会向父进程发送一个信号，父进程收到信号之后，就会将内存中缓存的写指令追加到新的AOF文件中。

    4、第三步执行完之后，就会用新的AOF文件替换掉旧的AOF文件，以后再有新的操作都会在新的AOF文件后面追加。

Redis主从复制的方法

    redis主从服务器的复制采用的是异步操作，主要是为了提升服务器的性能，对于主从服务器的架构，可以关闭主服务器的持久化功能，只对从服务器进行持久化。

   主从服务器同步的原理

    1、从服务器向主服务器发出sync信号，主服务器收到后，会调用bgsave指令创建一个子进程去专门进行持久化工作，即将主服务器的数据写入到RDB文件中。在进行持久化的过程中，主服务器的写入指令都保存在内存当中。

    2、当bgsave指令执行结束之后，主服务器将保存好的RDB文件发送给从服务器，从服务器将文件保存在磁盘上，然后将数据读取到内存中，这个过程执行完之后，主服务器会将这段时间保存在内存的指令以redis协议的形式发送给从服务器。

   当多个从服务器发来sync指令，主服务器也只会进行一次bgsave命令来进行持久化工作。

    在redis2.8之前，如果主从服务器断开的话，会进行一次全量同步，在2.8之后，redis新增了一个增量同步策略，大大降低了断开连接之后，恢复连接的成本。

  增量同步的流程

   在主服务器内存维护了一个缓冲区，保存了希望同步到从服务器的指令，如果主从服务器断开后重新连接成功，从服务器会尝试与主服务器连接，一旦连接成功，从服务器会向主服务器发送 希望同步的主服务器id和希望请求的数据偏移位置信息到主服务器，主服务器会校验id和自己的id是否相同，然后检查数据偏移量是否存在于缓存当中，如果两者都满足就会进行增量同步。