redis的AOF和RDB持久化方式

AOF

AOF是写后日志，mysql在写数据前会先写redo log，而redis会先写数据，再写AOF日志。AOF的写入是在主进程当中完成的。

为什么先写入命令，再写AOF缓冲呢？原因是redis在写日志时不会进行语法检查，所以要先等待写数据的执行结果，如果写数据的执行结果正确，再将日志写入AOF中。

AOF存在的风险：

如果写完数据，还没来得及写日志服务器就挂掉了，此时这个命令的AOF日志就丢失了，使用AOF恢复数据就会丢失。

AOF的三种写入策略：

同步写回：每一个更新数据的命令执行完，立刻将日志写入磁盘。

每秒写回：更新数据的命令执行完后，先将日志写入到缓冲区中，每隔一秒将数据刷入磁盘。

系统控制：不可控，由操作系统决定何时将AOF缓冲区的信息刷入磁盘。

同步写回基本可以做到数据不丢失，但是对性能的影响非常大，会减慢业务的执行。

每秒写回是折中方案，也是最适合的方案，既减轻了redis写日志的压力，也能保证数据的安全性。一秒内的数据可能发生丢失。

系统控制就是将控制权完全交给了操作系统，会丢失多少数据，我们完全是不可控的。

AOF存在的问题，不断的写AOF日志，会造成AOF文件特别大。文件大了之后，继续写AOF的效率会变低，同时操作系统里的文件系统对文件的大小也有限制，可能无法保存很大的文件。而且如果AOF文件特别大，使用AOF恢复数据时也会非常慢，这该怎么办呢？

为了解决这个问题，redis有AOF重写机制！

简单来说，AOF的重写机制，就是让记录的命令从多变一。

因为AOF会记录每一条对数据修改的指令，例如 set k1 zhangsan set k1 lisi set k1 wangwu，所以AOF文件中会记录三条这样的命令。在重写后，AOF只会记录对数据最后一次的更改！也就是根据键值对最新的状态，生成写入的命令。

AOF的重写过程是由后台的子进程来完成的，主要是为了避免主进程的堵塞，fork出来的子进程，和父进程映射的内存是同一块，后台子进程就可以在不影响主进程的情况下，将redis中的数据记录成写操作，写入新的AOF文件中。

redis会创建一个新的AOF文件，读取数据库当前的键值对，根据键值对信息生成每一个键值对对应的写入命令。

由于主进程并没有被堵塞，所以主进程任然会执行新的命令，这些新的操作也会记录到重写日志中。

AOF重写的触发条件：

通过配置文件设定AOF的最大大小，当写入的数据大于了这个设定的大小，就会触发重写机制。

RDB

AOF文件记录的是对所有key的修改操作，使用AOF恢复数据时，需要将这些命令全部执行一遍，如果AOF日志文件过大，会造成命令的执行非常漫长，严重影响当前redis的使用。

所以Redis还有另外一种数据恢复的方式，RDB

RDB相当于是给内存创建了一张快照，记录了内存某一个时间点的所有信息，将这些信息写入到磁盘，所以，RDB是基于二进制数据直接进行的恢复，不需要执行命令，恢复速度很快（直接将这个文件的信息读入内存，当然快了）这个快照文件，就称为RDB文件

RDB的写入提供了两种方式。

1、使用save,在主进程中执行，会堵塞当前命令的执行。

2、使用bgsave，创建一个子进程，专门用来写入RDB文件，这是默认的执行方式。

如果使用的是bgsave，那么在子进程写入RDB文件的过程中，如果redis中的key已经发生了更改，会怎么样呢？

这就利用了操作系统的读时共享、写时复制技术，父进程可以正常的执行写命令，父进程会重新找一块物理内存进行映射，将要更改的数据重新映射到一块新的物理内存区域。此时子进程不受任何影响，任然可以对之前的数据进行写入，只不过写入的是更改之前的数据。

做全量快照的策略是什么呢？

肯定不能频繁的去做全量快照，因为fork必然会导致子进程拷贝父进程的页目录项和页表信息，如果父进程占用的内存非常大，拷贝页表信息是非常耗时的，会造成一定时间的堵塞。

同时，如果频繁的进行全量快照，会对磁盘带宽的压力非常大，可能上一次fork的子进程还没有完成RDB文件的生成，下一个子进程又开始进行数据快照的操作了。

redis采用的方式是，使用增量快照的方法。

增量快照：在执行一次全量快照后，后续的快照只需要对修改的数据进行快照记录。

redis的快照写入策略，当一定的时间内发生了多少个key的修改，对这些修改的key进行快照。

redis在进行RDB持久化时，会创建一个临时文件写入更改的键值对。

创建临时文件的原因有两个方面

1、如果操作的是一个文件，会造成竞争冒险的问题，必然要引入进程之间的互斥操作，严重影响性能。

2、如果操作的是原RDB文件，如果在写入的过程中redis崩溃了，那整个RDB文件就被污染了。