Redis之AOF持久化小探

除了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文件所保存的状态不一致。
这个问题如下表所示：