除了RDB持久化功能之外，Redis还提供了AOF持久化功能。与RDB通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。
服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态。
I、AOF持久化的实现
AOF持久化功能的实现可以分为命令追加，文件写入， 文件同步三个步骤。
1.1 命令追加
当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态aof_buf缓冲区末尾。
1.2 AOF文件的写入与同步
Redis的服务器进程就是一个事件循环，这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行serverCorn函数这样需要定时运行的函数。
因为服务器在处理文件事件的时候可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前，都会调用flushAppendOnlyFile函数，考虑是否将aof_buf缓冲区中的内容写入和保存到AOF文件中：
def eventLoop():
while true:
#处理文件事件
processFileEvents()
#处理时间事件
processTimeEvents()
#考虑是否要将aof_buf中的内容写入到AOF文件中
flushAppendOnlyFile()
flushAppendOnlyFile函数的行为是由服务器配置的appendfsync选项的值来决定的：
tips： 为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区中，等到缓冲区的空间被填满，或者超过了指定的时限之后，才真正的将缓冲区中的数据写入到磁盘中。
因此，AOF持久化中的文件写入操作其实是将aof_buf缓冲区的内容存放到了内存缓冲区中，这时还没有真正写入到磁盘中，这个缓冲区达到同步条件时，才会执行fsync将这个缓冲区的内容写入到硬盘中，完成文件同步。
举个例子： 假设服务器在处理文件事件期间，执行了三个写入命令：
- SADD databases "Redis" "MySQL", "MongoDB"
- SET data "2013-9-5"
- INCR click_counter 10086
那么aof_buf缓冲区中将包含了这三个命令的协议内容：
如果这时flushAppendOnlyFile函数被调用，假设服务器当前appendfsync选项的值为everysec，并且距离上次同步AOF文件已经超过一秒钟，那么服务器会先将aof_buf中的内容写入到AOF文件中，然后再对AOF文件进行同步。
II、AOF文件的载入与数据还原
Redis读取AOF文件并还原数据库状态的详细步骤如下：
- 创建一个不需要网络连接的伪客户端。
- 从AOF文件中分析并读取出一条写命令。
- 使用伪客户端执行被读出的写命令。
- 循环执行2)和3)，知道将AOF文件全部处理完毕。
III、AOF重写
因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件体积会越来越大，如果不加以控制的话，体积过大的AOF文件可能对Redis服务器，甚至整个宿主计算机造成影响，并且AOF文件的体积过大，使用AOF文件来进行数据还原所需的时间就越多。
为了解决AOF文件体积膨胀的问题，Redis提供了文件重写功能。
3.1 AOF文件重写的实现
虽然Redis将生成新的AOF文件来替换旧的AOF文件的功能命名为“AOF文件重写”，但实际上，AOF文件重写并不需要对现在的AOF文件进行任何读取、分析或写入操作，这个功能是通过读取服务器当前数据库状态来实现的。
如下面的例子：
redis> RPUSH list "A" "B" //["A", "B"]
(integer) 2
redis> RPUSH list "C" //["A", "B", "C"]
(integer) 3
redis> RPUSH list "D" "E" //["A", "B", "C", "D", "E"]
(integer) 4
redis> LPOP list //["B", "C", "D", "E"]
"A"
redis> Lpop list //["C", "D", "E"]
"B"
redis> RPUSH list "F" "G" //["C", "D", "E", "F", "G"]
(integer) 5
服务器为了保存当前的list状态，必须在AOF文件中写入6条命令。
但是，如果服务器想要用尽量少的命令来记录list的状态，那么最简单高效的办法就是直接从数据库中读取键list的值，然后用一条RPUSH list "C", "D", "E", "F", "G"命令即可实现。
这种首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理。
例如，对于图中所表示的数据库，aof_rewrite函数产生的新的AOF文件将为：
3.2 AOF后台重写
上面介绍的aof_rewrite函数可以很好的完成AOF文件重写任务，但是这个函数会进行大量的写入操作，所以调用这个函数的线程将被长时间阻塞，因为Redis服务器使用单个线程来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那么在重写AOF文件期间，服务器将无法处理客户端发来的请求任务。
所以，Redis决定将AOF重写程序放到子进程中执行。这样可以避免服务器端阻塞，并且使用子进程而不使用线程主要是避免使用锁，保证数据的安全性。
但是，使用子进程也存在一个问题，就是在子进程进行AOF重写期间，服务器进程还在接受客户端的请求，而新的命令可能会对现在数据库状态进行修改，从而使得服务器当前的数据库状态和重写之后的AOF文件所保存的状态不一致。
这个问题如下表所示：
为了解决数据不一致问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区：
这样就可以保证数据的一致性，具有AOF重写缓冲区之后重写过程如下表所示：
这也就是BGREWRITEAOF命令的实现原理。
【参考】
[1] 《Redis的设计与实现》
欢迎转载，转载请注明出处wenmingxing Redis之AOF持久化小探
