介绍 AOF 日志

AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态。

假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性命令，那么就可以通过对一个空的 Redis 实例顺序执行所有的命令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

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

在这个 AOF 文件里面， 除了用于指定数据库的 select 命令是服务器自动添加的之外， 其他都是我们之前通过客户端发送的命令。

每一条命令对应的 AOF 日志首先会以“*+命令包含的部分数量”开始（该命令由几部分组成）每部分由“$+数字”开头，后面紧跟着该部分的字符（具体的命令、键或值），“数字”表示这部分字符一共有多少字节。

我们以 Redis 执行“set testkey testvalue”命令后记录的 AOF 为例，看看 AOF 日志的内容。

其中，“*3”表示当前命令有三个部分；“$3 set”表示这部分有 3 个字节，也就是“set”命令。

AOF 持久化的实现原理

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

命令追加（append）

当 AOF 持久化功能处于打开状态时， 服务器在执行完一个写命令之后， 会以协议格式将被执行的写命令追加到服务器状态（redisServer 结构体）的 aof_buf （简单动态字符串 类型）的末尾：

struct redisServer {
    // ...
    // AOF缓冲区
    sds aof_buf;
    // ...
};

文件写入（wirte）、文件同步（sync）

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

因为服务器在处理文件事件时可能会执行写命令， 使得一些内容被追加到 aof_buf 缓冲区里面， 所以服务器在每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数， 考虑是否需要将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件里面， 这个过程可以用以下伪代码表示：

def eventLoop():
    while True:
        #处理文件事件，接收命令请求以及发送命令回复
        #处理命令请求时可能会有新内容被追加到 aof_buf 缓冲区中
        processFileEvents()
        
        #处理时间事件
        processTimeEvents()
        
        #考虑是否要将 aof_buf中的内容写入和保存到 AOF文件里面
        flushAppendOnlyFile()

AOF 的写回策略

flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定， 各个不同值产生的行为如下所示。

• 值为 Always，同步写回：将 aof_buf 缓冲区里面的所有内容写入并同步到 AOF 文件（wirte + fsync，fsync 由主线程执行）
• 值为 Everysec，每秒写回：将 aof_buf 缓冲区里面的所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间距离现在超过一秒钟，那么再次对 AOF 文件进行同步，并且这个同步操作是由一个线程专门负责执行的（write，如果距离上次同步的时间超过一秒钟就 fsync，fsync 由子线程执行）
• 值为 No，操作系统控制的写回：将 aof_buf 缓冲区里面的所有内容写入到 AOF 文件，但不对 AOF 文件进行同步，何时同步由操作系统来决定（只 write，不 fsync；fsync 的时机由操作系统决定）

如果用户没有主动为 appendfsync 选项设置值， 那么 appendfsync 选项的默认值为 everysec。

将 aof_buf 缓冲区里面的所有内容写入到 AOF 文件的意思是，将内容写入内核缓冲区。

将 aof_buf 缓冲区里面的所有内容写入并同步到 AOF 文件的意思是，将内核写入内核缓冲区，并将内核缓冲区中的数据同步到磁盘。

注意，在实际运行中， 程序在 Everysec 模式下对 fsync 或 fdatasync 的调用并不是每秒一次，它和调用 flushAppendOnlyFile 函数时 Redis 所处的状态有关。

每当 flushAppendOnlyFile 函数被调用时， 可能会出现以下四种情况：

• 子线程正在执行 fsync ，并且：

1. 1. 这个 fsync 的执行时间未超过 2 秒，那么程序直接返回，并不执行 write 或新的 fsync 。
   2. 这个 fsync 已经执行超过 2 秒，那么程序执行 write，但不执行新的 fsync 。(注意，因为这时 write 的写入必须等待子线程先完成旧的 fsync ，因此这里 write 会比平时阻塞更长时间。

• 子线程没有在执行 fsync ，并且：

1. 1. 上次成功执行 fsync 距今不超过 1 秒，那么程序执行 write，但不执行 fsync 。
   2. 上次成功执行 fsync 距今已经超过 1 秒，那么程序执行 write 和 fsync 。

Redis 官网上所说的， AOF 在“每秒写回”时发生故障， 只丢失 1 秒钟数据的说法， 实际上并不准确。

AOF 持久化的效率和安全性

服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。

• always 的效率是 appendfsync 选项三个值当中最慢的一个， 但从安全性来说， always 也是最安全的， 因为即使出现故障停机， AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
• everysec 的效率足够快， 并且就算出现故障停机， 数据库也只丢失几秒钟的命令数据。
• no 的效率最快，不过因为这种模式会在系统缓存中积累一段时间的写入数据，当出现故障停机时，服务器将丢失上次同步 AOF 文件之后的所有写命令数据。

三种写回策略体现了系统设计中的一个重要原则 ，即 trade-off，或者称为“取舍”，指的就是在性能和可靠性保证之间做取舍。

AOF 文件重写

技术是为了解决问题而生的，AOF 文件重写用于减少 AOF 文件的体积， 减少使用 AOF 文件来进行数据还原所需的时间 。

所以随着服务器运行时间的流逝， AOF 文件中的内容会越来越多， 文件的体积也会越来越大， 如果不加以控制的话， 体积过大的 AOF 文件很可能对 Redis 服务器、 甚至整个宿主计算机造成影响， 并且 AOF 文件的体积越大， 使用 AOF 文件来进行数据还原所需的时间就越多。

为了解决 AOF 文件体积膨胀的问题， Redis 提供了 AOF 文件重写（rewrite） 功能。 通过该功能， Redis 服务器可以创建一个新的 AOF 文件来替代现有的 AOF 文件， 新旧两个 AOF 文件所保存的数据库状态相同，但新 AOF 文件不会包含任何浪费空间的冗余命令， 所以新 AOF 文件的体积通常会比旧 AOF 文件的体积要小得多。

AOF 文件重写的实现原理

虽然 Redis 将生成新 AOF 文件替换旧 AOF 文件的功能命名为“AOF 文件重写”，但实际上，AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

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

在 Redis4.0 后支持混合持久化方式，如果使用混合持久化：

• 当服务器执行写命令后，Redis 会以 AOF 持久化方式将命令写回 incr.aof 文件。
• 当进行 AOF 文件重写时，Redis 会以 RDB 持久化方式将当前数据库状态保存到名为 base.aof 文件，然后再将 AOF 重写缓冲区中的所有内容写入 incr.aof 文件。
• 当 Redis 服务器重启后，将载入 base.aof 和 incre.aof 文件以还原数据库状态。

子进程执行 AOF 文件重写

Redis 不希望 AOF 重写造成服务器无法处理请求， 所以 Redis 将 AOF 重写程序放到子进程里执行， 这样做可以同时达到两个目的：

• 子进程进行 AOF 重写期间， 服务器进程（父进程） 可以继续处理命令请求。
• 子进程带有服务器进程的数据副本， 使用子进程而不是线程， 可以在避免使用锁的情况下， 保证数据的安全性。

Redis 需要处理在 AOF 重写期间，服务器执行的所有写命令，否则服务器当前的数据库状态和重写后的 AOF 文件所保存的数据库状态将不一致。

为了解决这种数据不一致问题， Redis 服务器设置了一个 AOF 重写缓冲区， 这个缓冲区在服务器创建子进程之后开始使用。当 Redis 服务器执行完一个写命令之后， 它会同时将这个写命令发送给 AOF 缓冲区（名为 aof_buf 的简单动态字符串）和 AOF 重写缓冲区，当子进程完成创建新 AOF 文件的工作之后， 服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾， 使得新旧两个 AOF 文件所保存的数据库状态一致。 最后，服务器用新的 AOF 文件替换旧的 AOF 文件， 以此来完成 AOF 文件重写操作。

这样一来可以保证：

• AOF 缓冲区的内容会定期被写入和同步到 AOF 文件， 对现有 AOF 文件的处理工作会如常进行。
• 从创建子进程开始， 服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里面。

AOF 文件重写的触发时机

AOF — Redis 设计与实现 (redisbook.readthedocs.io)

AOF 重写可以由用户通过调用 bgrewriteaof 手动触发。

另外， 服务器在 AOF 功能开启的情况下， 会维持以下三个变量：

• 记录当前 AOF 文件大小的变量 aof_current_size 。
• 记录最后一次 AOF 重写之后， AOF 文件大小的变量 aof_rewrite_base_size 。
• 增长百分比变量 aof_rewrite_perc 。

每次当 serverCron 函数（时间事件）执行时，它都会检查以下条件是否全部满足，如果全部满足的话， 就会触发自动的 AOF 重写：

1. 没有 bgsave 命令在进行。
2. 没有 bgrewriteaof 在进行。
3. 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 64 MB）。
4. 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

默认情况下， 增长百分比为 100% ， 也即是说， 如果前面三个条件都已经满足， 并且当前 AOF 文件大小比最后一次 AOF 重写时的大小要大一倍的话， 那么触发自动 AOF 重写。

Redis 的服务器周期性操作函数 serverCron 默认每隔 100 毫秒就会执行一次， 该函数用于对正在运行的服务器进行维护。

AOF 配置的选项

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

参考资料

《Redis 设计与实现》