AOF是append-only file的简称。
当redis server启动时，如果没有开启AOF模式，则加载AOF文件，否则将加载RDB文件。
如果redis中数据发生变化，那么不会直接写到硬盘里，而是先写到AOF缓冲区aof_buf中。
一 原理
AOF持久化需要三个过程：
1）命令追加：写到aof_buf中；
2）写入文件：执行write操作；
3）同步文件：同步到磁盘中。
while(1){
processFileEvents(); // 处理文件事件
processTimeEvents(); // 处理时间事件
flushAppendOnlyFile(); // 是否将aof_buf中的内容写入和同步到AOF文件里面
}
redis进程是一个死循环，如果发现有写命令，那么这些命令会以Redis通信协议的格式添加到aof_buf中（命令追加），并执行appendfsync策略（写入和同步），这种策略一共有三种：
1）always：将aof_buf中的内容写入并同步到AOF文件中。
2）everysec：将aof_buf中内容写如AOF文件中，如果上次同步AOF文件的时间距离现在超过1s，那么再次同步AOF文件。这个操作是由一个线程专门负责执行的。
3）no：将aof_buf中的内容写入到AOF文件中，但并不对AOF同步，何时同步交给OS。
用户调用write函数，并不会直接写入磁盘，而是将数据暂存在内存缓冲区中，等缓冲区被填满或者超过指定时限后，会将数据同步到磁盘中（flush）.
1的优点是数据安全，效率太低，因为过于频繁的调用系统；只有在这种策略下，redis的事务是满足持久化的。
3的优点是效率较高，但是不够安全，因为buf中的数据可能因为宕机而丢失；
2介于两者之间，在效率和安全之间达到一个平衡。这里我们又一次看到折中思想在计算机中的应用。
二 AOF文件重写
AOF模式的一个问题是AOF文件可能会变得非常大。
通过分析AOF文件，往往发现里面有太多的重复和冗余数据，可以生成一个新的AOF文件来代替旧的AOF文件，这就是AOF重写。这个操作满足一定条件是，Redis会自动触发。
AOF重新通过bgRewriteAOF命令来完成，这时会fork一个子进程，这样主进程还可以继续处理命令。除此之外，子进程带有主进程的数据副本，可以在避免锁的情况下，保证数据的安全性。
AOF重写面临的一个问题是：在重写期间，主进程继续处理命令，而新的命令有可能还会对现在有数据进行修改，这会导致当前数据库中的数据和生成的AOF文件不一致。
为了解决上述问题，Redis增加了一个AOF重写缓冲区rewrite_buf，主进程接收到新的写命令之后，会把这个命令的协议内容追到rewrite_buf中。这样主进程在处理命令的时候，一面将命令追加到aof_buf中，一面将写命令追加到rewrite_buf中。也就是说在重写的时候，也会更新旧文件，这是为了防止重写AOF失败。
当子进程重写完毕之后，会给父进程发送一个信号，父进程接受到这个信号以后，会调用一个信号处理函数，完成以下工作：
1）将rewrite_buf中的数据全部写到新的AOF文件中。
2）修改新的AOF文件的文件名（主进程会短暂阻塞），覆盖旧的文件。
2017-12-27阅：
数据持久化的路径：内存->buf->文件，分别对应了AOF的三个步骤。
appendfsync策略以时间作为折中的标准。
2019-03-19阅：
append, write, flush
always, everysec, no
