AOF(Append Only File)

与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。

11.1AOF持久化的实现

AOF持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

11.1.1 命令追加

当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。

11.1.2 AOF文件的写入与同步

Redis的服务器进程是一个事件循环(loop)，循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数。

flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的值来决定：

11.2 AOF文件的载入与数据还原

11.3AOF重写

为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写(rewrite)功能。

11.3.1AOF文件重写的实现

首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理。

11.3.2 AOF后台重写

因为aof_rewrite函数会进行大量的写入操作，所以调用这个函数的线程将被长时间阻塞，因为Redis服务器使用单个线程来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那么在重写AOF文件期间，服务器将无法处理客户端发来的命令请求。

Redis决定将AOF重写程序放到子进程里执行：

• 子进程进行AOF重写期间，服务器进程可以继续处理命令请求。

• 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以避免使用锁的情况下，保证数据的安全性。

为了解决数据不一致问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，会同时将这个命令发送给AOF缓冲区和AOF重写缓冲区

在子进程执行AOF重写期间，服务器进程需要执行以下三个工作：

• 执行客户端发来的命令。

• 将执行后的写命令追加到AOF缓冲区。

• 将执行后的写命令追加到AOF重写缓冲区。

这样一来可以保证

• AOF缓冲区的内容会定期被写入和同步到AOF文件，对现有AOF文件的处理工作会如常进行。

• 从创建子进程开始，服务器执行的所有写命都会被记录到AOF重写缓冲区里面。

当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作：

• 将AOF重写缓冲区中的所有内容重写到新AOF文件中，这时新AOF文件保存的数据库状态将和服务器当前的数据库状态一致。

• 对新的AOF文件进行改名，原子地(atomic)覆盖现有地AOF文件，完成新旧两个AOF文件地替换。

在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器进程造成阻塞，在其他时候，AOF后台重写都不会阻塞父进程，这将AOF重写对服务器性能造成的影响降到了最低。

以上是BGREWRITEAOF命令的实现原理。

11.4 重点回顾

• AOF文件通过保存所有修改数据库的写命令请求来记录服务器的数据库状态。

• AOF文件中的所有命令都以Redis命令请求协议的格式保存。

• 命令请求会先保存到AOF缓冲区里面，之后再定期写入并同步到AOF文件。

• appebdfsync选项的不同值对AOF持久化功能的安全性以及Redis服务器的性能有很大的影响。

• 服务器只要载入并重新执行保存在AOF文件中的命令，就可以还原数据库本来的状态。

• AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。

• AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何读入、分析或者写入操作。

• 在执行BGREWRITEAOF命令时，Redis服务器会维护一个AOF重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作。

本文转自 许大树 51CTO博客，原文链接：http://blog.51cto.com/abelxu/1899752，如需转载请自行联系原作者