AOF文件

Redis 将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件， 以此达到记录数据库状态的目的。

假如目前已经执行以下命令

RPUSH list 1 2 3 4

RPOP list

LPOP list

LPUSH list 1

那么上面列举的四个命令在 AOF 文件中就实际保存如下（AOF 文件使用网络通讯协议的格式）

*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n*6\r\n$5\r\nRPUSH\r\n$4\r\nlist\r\n$1\r\n1\r\n$1\r\n2\r\n$1\r\n3\r\n$1\r\n4\r\n*2\r\n$4\r\nRPOP\r\n$4\r\nlist\r\n*2\r\n$4\r\nLPOP\r\n$4\r\nlist\r\n*3\r\n$5\r\nLPUSH\r\n$4\r\nlist\r\n$1\r\n1

可以看到，除了 SELECT 命令是 AOF 程序自己加上去的之外， 其他命令都是之前我们在终端里执行的命令。

同步命令到 AOF 文件的整个过程可以分为三个阶段：

  1. 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
  2. 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。
  3. 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

AOF保存模式

每当服务器常规任务函数被执行、 或者事件处理器被执行时， aof.c/flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作：

WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

两个步骤都需要根据一定的条件来执行， 而这些条件由 AOF 所使用的保存模式来决定。Redis 目前支持三种 AOF 保存模式，它们分别是：

  1. AOF_FSYNC_NO ：不保存。
  2. AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
  3. AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。

不保存

在这种模式下， 每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行， 但 SAVE 会被略过。

在这种模式下， SAVE 只会在以下任意一种情况中被执行：

  • Redis 被关闭
  • AOF 功能被关闭
  • 系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）

这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。

每一秒钟保存一次

在这种模式下， 每次调用 flushAppendOnlyFile 函数，SAVE操作会由子线程进行。如果子线程没有在执行 SAVE，那么WRITE 都会被执行，如果上次成功执行 SAVE 距今已经超过 1 秒 ，那么程序会继续执行SAVE。

而如果当 flushAppendOnlyFile 函数被调用时，子线程正在执行SAVE。那么程序就会判断该 SAVE 的执行是否已经超过 2 秒，如果否，那么程序直接返回，并不执行 WRITE 或新的 SAVE ，此时如果发生停机，那么损失的数据是在2秒以内的。反之，程序执行 WRITE ，但不执行新的 SAVE ，因为这时 WRITE 的写入必须等待子线程先完成（旧的） SAVE ，因此这里 WRITE 会比平时阻塞更长时间，发生故障停机， 那么损失的数据是会超过 2 秒的。

每执行一个命令保存一次

在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。

另外，因为 SAVE 是由 Redis 主进程执行的，所以在 SAVE 执行期间，主进程会被阻塞，不能接受命令请求。

AOF 保存模式对性能和安全性的影响

对于三种 AOF 保存模式， 它们对服务器主进程的阻塞情况如下：

  1. 不保存（AOF_FSYNC_NO）：写入和保存都由主进程执行，两个操作都会阻塞主进程。
  2. 每一秒钟保存一次（AOF_FSYNC_EVERYSEC）：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。
  3. 每执行一个命令保存一次（AOF_FSYNC_ALWAYS）：和模式 1 一样。

模式 1 的保存操作只会在AOF 关闭或 Redis 关闭时执行， 或者由操作系统触发， 在一般情况下， 这种模式只需要为写入阻塞， 因此它的写入性能要比后面两种模式要高， 当然， 这种性能的提高是以降低安全性为代价的： 在这种模式下， 如果运行的中途发生停机， 那么丢失数据的数量由操作系统的缓存冲洗策略决定。

模式 2 在性能方面要优于模式 3 ， 并且在通常情况下， 这种模式最多丢失不多于 2 秒的数据， 所以它的安全性要高于模式 1 ， 这是一种兼顾性能和安全性的保存方案。

模式 3 的安全性是最高的， 但性能也是最差的， 因为服务器必须阻塞直到命令信息被写入并保存到磁盘之后， 才能继续处理请求。

AOF重写

AOF存在一个问题，随着运行时间的流逝， AOF 文件会变得越来越大。所以Redis 需要对 AOF 文件进行重写（rewrite）： 创建一个新的 AOF 文件来代替原有的 AOF 文件， 新 AOF 文件和原有 AOF 文件保存的数据库状态完全一样， 但新 AOF 文件的体积小于等于原有 AOF 文件的体积。

考虑这样一种情况，有些被频繁操作的键， 对它们所调用的命令可能有成百上千、甚至上万条，但实际上用一条命令就可以记录其当前的状态。所以实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。

AOF后台重写

作为一种辅佐性的维护手段， Redis 不希望 AOF 重写造成服务器无法处理请求， 所以 Redis 决定将 AOF 重写程序放到（后台）子进程里执行， 这样处理的最大好处是：

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

不过， 使用子进程也有一个问题需要解决： 因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外， 还会追加到这个缓存中。这样一来可以保证：

  1. 现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。
  2. 所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。

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

  1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
  2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

这个信号处理函数执行完毕之后， 主进程就可以继续像往常一样接受命令请求了。 在整个 AOF 后台重写过程中， 只有最后的写入缓存和改名操作会造成主进程阻塞。

AOF重写的触发条件

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 （默认值为 1 MB）。
  4. 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

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

参考

[1] AOF