redis-RDF和AOF

redis是一个内存数据库，它的数据都储存在内存中，所以就存在如果断电就会数据丢失的问题，redis为了解决这个问题就推出两种持久化的方式，分别是RDB和AOF

RDB

RDB就是以快照的方式进行持久化，他会保存当前时刻redis的数据，还原时也会还原这个时刻的redis数据，RDB的触发策略是在redis.conf中进行配置，默认的是三种策略，

save 900 1

save 300 10

save 60 10000

1.在900秒内key变化了一次就进行持久化，2.在300秒内key变化了10次就进行持久化，3.在60秒内变化了10000次就进行一次持久化。

如果你想对这个策略进行修改，也可以到redis.conf中进行修改，他的格式是秒数从上到下是大到小，key的变化次数是从上到下是小到大

redis在触发RDB是实际上在父进程下创建了一个子进程，比如linux的fork()函数。

为什么要创建一个子进程呢。

因为如果还是在同一个进程中，当redis进行RDB时，redis就会阻塞，为了不阻塞redis的使用，我们采用的方式就是fork()，fork函数的底层使用的是copy on write的方式，当使用fork时，首先会创建一个子进程，这个子进程会复制父进程的内存页表，他不会复制父进程的物理内存，所以会节省资源。

子进程进行RDB操作，而父进程则进行读写操作，当发生写操作时，key的指针会指向新的地址，而子进程依旧fork那个时间点的内存指向。所以子进程可以慢慢写，不需要在意父进程的数据变化。

RDB的速度很快，但是相应的因为它是以保存的某个时间点的快照，所以一但出现断电的情况，它的数据恢复实际上是会损失一段时间内的数据的，但是因为RDB是每隔一段时间进行一个落盘，并且使用fork的方式，所以他的速度会相对来说快很多。

AOF

aof相较于RDB提供了更可靠的持久化方式，aof的是以redis的命令请求协议格式保存的，而且是纯文本格式，也就是说我们可以直接打开aof文件查看。

但是正因为aof以命令的格式存储，所以aof是有一定可能出现bug的，从理论上来说他的健壮性相对于RDB来说要低一些。

aof默认是关闭的，我们可以在redis.conf中修改appendonly no为appendonly yes来开启aof，同时在redis.conf中也可以修改aof的文件同步频率， 默认是appendfsync everysec  每个一秒就进行一次同步，另外还有 always  ，每一次有写操作时都会进行一个同步，no 这个由操作系统来决定何时进行同步。

以everysec为例，aof在收到写操作时实际上第一步是讲收到的命令缓存在一个aof_buf的缓冲区中，等到时间到了之后就开始追加到aof文件的后方。这时就会出现一个问题，aof文件只有一个，不断的追加会使这个aof文件不断的变大，这样会大大的占用磁盘空间，而且也会增加redis的恢复时间，而且aof文件中也会有大量的无效命令。

怎么解决这个问题呢？就是aof的重写程序，当aof文件到达一定程度的时候就会触发重写程序，这个重写程序会首先会fork出一个子进程，在子进程中通过当前的redis的数据生成对应的set语句，并插入到一个新的aof文件中，这个时候还有一个问题就是在重写的过程中如果发生了写操作，就没有办法同步到新的aof文件中，所以这个时候就会再新建子进程的同时会创建一个aof重写缓冲区，在发生写操作时，会同时向aof_buf缓冲区和aof重写缓存区中缓存写命令，等到重写程序将当前所有的redis的数据都生成set命令后，会通知主进程，主进程就会调用一个信号处理器，这个信号处理器做了两件事，首先将aof重写缓冲区中的命令追加到新的aof文件的后方，此时新的aof文件的命令就是和当前的redis的数据相同，第二件事就是修改新的aof文件的文件名，并原子的覆盖旧的aof文件，当信号处理器做完这些事以后，父进程就可以继续执行读写命令了。

这样的好处是节省了磁盘的文件，最小化的存储了aof文件，并且，使用创建子进程的方式，节省了时间，只在信号处理器执行时阻塞了读写操作，把aof重写对父进程的影响降到了最低。