AOF持久化在硬盘上保存的是对Redis进行的逻辑操作，类似InnoDB中的bin log。说白了就是你对一个Redis输入了哪些语句，AOF文件都会原封不动的保存起来，等到需要回复Redis的时候再把这些语句执行一遍。
11.1 AOF持久化的实现
AOF简单的理解是把执行的语句记录在硬盘的文件上。
操作系统对文件的写入进行了一些优化，即把一条记录写在硬盘上需要分为两步：1、文件写入缓冲区 2、缓冲区内容同步。为了提高文件的读写速度，当用户调用write函数后，操作系统会把写入的数据暂存在内存缓冲区里。当 内存缓冲区满或者超过缓冲时限后，才会把缓冲区内容同步到硬盘上。这样做的优点是提高了读写效率，每次写入只需写到缓存里而不需要写到硬盘，缺点是具有一定的不安全性，如果缓冲区的内容没有及时同步到硬盘上此时计算机宕机那么就会失去这部分数据。为此操作系统提供了fsnsc fdatasync两个同步函数，强制同步缓冲区的数据到硬盘上。
AOF同步也是一种把记录写到硬盘上的行为，在上述两个步骤之外，Redis额外加一步命令，Redis先把记录追加到自己维护的一个aof_buf中。所以AOF持久化分为三步：1、命令追加 2、文件写入 3.文件同步
11.1.1 命令追加
服务器再执行完一条指令后会以规定的格式追加到aof_buf的末尾。如执行完SET KEY V1后，aof_buf末尾会多以下内容。
11.1.2 AOF文件的写入与同步
完成aof_buf写入后Redis会执行flushAppendOnlyFile,该方法根据配置文件的不同而采用不同的策略把aof_buf里的内容刷到内存缓冲区里，具体的根据appendfsync的取值来决定不同的策略。
- always，每次执行flushAppenfOnlyFIle的时候都会把aof——buf的内容刷到文件缓冲区，并且会同步缓冲区到硬盘
- everysec，把aof_buf刷到文件缓冲区，之后两次文件缓冲区同步间隔超过1秒才会同步缓冲区
- no，只刷到文件缓冲区，不管同步的事情
三种模式下安全性和效率性的比较
- always每次都要同步缓冲区，速度较慢，但不会出现内容缺失
- everysec，速度比always要快，但是有可能会损失一定的数据，不过损失最多是1秒钟
- no，执行速度最快，把文件缓冲区同步的调度交给了操作系统，安全性较差。并且当缓冲区积累到一定程度而不得不把内容写会文件系统后，会消耗大量的时间来完成同步的过程。所以均摊来看no 和 everysec效率类似。
11.2 AOF文件的载入与数据还原
如何从AOF文件中恢复之前保存的数据？AOF是一个逻辑的日志，只需要把AOF从头到尾执行一遍即可。Redis服务器端设计的是执行客户端发出的指令，所以在回复AOF文件的时候创建了一个伪客户端从AOF文件中读取内容发送Redis服务器端实行，当AOF文件全部执行完毕后数据库也就恢复了。
11.3 AOF重写
比如在操作Redis过程中把一个key的值从A改成了B然后又改回了A，此时AOF文件中有两条记录：A->B->A。所以在回复的时候回执行两次回复语句，但事实上是中间的两次变化是冗余的。随着Redis的执行，AOF不仅会变得冗余体积也会膨胀的更大。
为了解决冗余带来的体积膨胀，Redis提供了AOF文件重写功能，通过AOF文件重写得到的新AOF文件，其恢复的结果和旧的AOF文件相同，但是体积更小因为他不会包含冗余指令。
11.3.1 AOF文件重写的实现
AOF文件重写的逻辑非常简单，并不是分析旧的文件去除冗余指令，而是直接获取当前Redis的快照，然后用一条指令实现当前快照的结果并保存到AOF文件中。
Redis作为一个成熟的产品，在这种我想不到的细节处也做了优化。在AOF持久化时写入磁盘的时候会先写到缓冲区，然后再同步到硬盘里。如果把10条很短的写硬盘的命令浓缩成一个很长的写语句，那么此时有可能发生缓冲区溢出，所以当压缩后的一条语句很长的时候Redis会把他拆分成相对短的指令。
11.3.2 AOF后台重写
仔细回顾一下AOF重写其实很简单：得到当前Redis的一个快照，然后把逻辑指令写到硬盘上。现在有两个问题：
1、Redis使用单个线程来处理指令，如果指令去执行文件写操作--一个势必会带来大量阻塞时间的操作，此时会无法响应客户端的请求。所以必须要使用子进程来实现AOF重写，为什么是子进程而非子线程呢？是为了在不加锁的情况下仍然能够保证安全，因为子进程做的事情很单纯读取快照、生成AOF文件。不会和工作的进程产生任何冲突
2、数据不一致。子进程读取的是快照，而且当重写期间父进程仍然在工作所以快照和Redis数据库会存在数据不一致的情况。为了解决这个问题Redis设置了重写缓冲区。
