剖析Redis持久化之AOF方式

上一篇对redis持久化之RDB方式进行了剖析。除了RDB持久化功能之外，Redis还提供了AOF（Append Only File）持久化功能。下面就来介绍一下AOF持久化功能。

1、AOF持久化原理

与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。并在服务器启动时，通过重新执行这些命令来还原数据库。如下图：

顺便提一句，被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的。因为Redis的命令请求协议是纯文本格式，所以我们是可以直接打开一个AOF文件，观察里面的内容的。

2、AOF持久化配置

首先在redis.conf文件开启aof持久化（默认没开启）

appendonly yes

然后对redis.conf文件中的“appendfsync”选项进行规则配置。不同的appendfsync值产生的持久化行为也不相同。

appendfsync=always

appendfsync设置为always时，服务器在每个事件循环中将aof_buf缓冲区中的所有内容写入并同步到AOF文件。从效率来说，是三个选项值当中最慢的一个，但从安全性来说，always是最安全的，因为即使出现故障停机，AOF持久化也只会丢失一个事件循环中所产生的命令数据。

#默认选项
appendfsync=everysec

appendfsync设置为everysec时，服务器在每个事件循环中将aof_buf缓冲区中的所有内容写入到AOF文件，并且每隔一秒将再次对AOF文件进行同步，并且这个同步操作是由一个线程专门负责执行的。从效率上来说，everysec模式足够快，并且就算出现故障停机，数据库也只丢失一秒钟的命令数据。

appendfsync=no

appendfsync设置为no时，服务器在每个事件循环中，将aof_buf缓冲区中的所有内容写入到AOF文件，但并不对AOF文件进行同步，何时同步由操作系统决定。从效率上来说，与everysec模式相当。AOF文件写入速度是最快的，但是单次同步时长是三种模式中最长的，当出现故障停机时，服务器将丢失上次同步AOF文件之后的所有写命令数据。

不论设置为以上三种的任一种情况，AOF持久化功能的实现基本可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

3、AOF文件载入与数据还原

因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

4、AOF重写

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可能对Redis服务器、甚至整个服务器造成影响，并且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。
为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写功能。通过该功能，Redis服务器会启动一个子进程，来创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

5、RDB持久化与AOF持久化对比

AOF文件的更新频率通常比RDB文件的更新频率高，所以如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态；只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。