Redis设计 - AOF持久化

前言

Redis 是内存数据库，它将数据存储在内存里，如果不想办法将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失，所以 Redis 提供了持久化功能。

本章将带你了解Redis持久化的AOF持久化是如何实现的。

AOF 持久化概述

除了 RDB 持久化之外，Redis 还提供了 AOF（Append Only File）持久化功能。与 RDB 持久化通过保存数据库中键值对来保存数据库的状态不同，AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库的状态。

AOF 持久化

假设执行如下命令

redis> SET msg "hello"
OK
redis> SADD fruits "apple" "banana" "cherry"
(integer) 3
redis> RPUSH numbers 128 256 512
(integer) 3

AOF持久化的方式，就是将三条命令保存在AOF文件中。写入其中的命令都是纯文本格式，默认会添加上SELECT 命令，用来切换数据库。

AOF文件内容示例

AOF持久化的实现

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

命令追加

AOF持久化处于开启状态时， Redis 执行一条写命令后，先将该命令追加到 AOF 缓冲区中，在以后的某个时刻再将 AOF 缓冲区中的内容同步到文件中。

为什么需要AOF缓冲区？

AOF 持久化需要将所有写命令记录在文件中来保存服务器状态，而文件写入操作效率比较低，如果每执行一条写命令都要写一次 AOF 文件无疑是低效的。为了提高效率，Redis 提供了一个中间层 – AOF 缓冲区。

typedef struct redisServer {
    //aof缓冲区
    sds aof_buf;

} redisServer;

AOF文件写入与同步

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

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

def eventLoop():

    while True:
    
        # 处理文件事件，接收命令请求以及发送命令回复
        # 处理命令请求时可能会有新内容被追加到 aof_buf 缓冲区中
        processFileEvents()

        # 处理时间事件
        processTimeEvents()

        # 考虑是否要将 aof_buf 中的内容写入和保存到 AOF 文件里面
        flushAppendOnlyFile()

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

appendfsync选项的值	flushAppendOnlyFile 函数的行为
always	将aof_buf缓冲区中的所有内容写入并同步到AOF文件
everysec	将aof_buf缓冲区的所有内容写入到AOF文件，如果上次同步AOF文件的时间距离现在超过1秒，则同步到AOF文件，是 Redis 的默认同步策略
no	将aof_buf缓冲区的所有内容写入到AOF文件，但不进行AOF文件同步，何时同步由操作系统决定

三种持久化的效率和安全性：

• always：速度最慢，每个事件循环都要执行同步操作，但最安全。
• everysec：效率和安全性比较适中，如果机器崩溃只丢失前一秒处理的新数据。
• no：该模式速度最快（无需执行同步操作）但也最不安全，如果机器崩溃将丢失上次同步后的所有数据。

文件的写入和同步
为了提高文件的写入效率，调用操作系统的writer函数时，操作系统通常会将数据暂时保存在内存缓冲区，等缓冲区被填满、或者超过了指定的时限后，才会真正将缓冲区的数据写到磁盘里。
所以AOF文件的同步操作，正是将缓冲区的数据写到磁盘里（系统提供fsync和fdatasync两个同步函数）

AOF文件的载入与数据还原

因为AOF文件保存的是Redis命令，所以服务器只要读取并执行AOF文件的写命令，就可以还原服务器的数据。

Redis读取AOF文件并还原数据库状态的详细步骤如下：

1. 创建一个不带网络链接的伪客户端（fake client），它执行命令的效果和带网络连接的客户端执行命令效果完全一样。
2. 从AOF文件中分析并读取一条写命令，使用伪客户端执行该命令。
3. 重复执行步骤2，直到所有的命令都执行完毕。

AOF文件载入过程

AOF重写

AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以 AOF 文件的大小随着时间的流逝一定会越来越大；影响包括但不限于：对于 Redis 服务器，计算机的存储压力；AOF 还原出数据库状态的时间增加

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

AOF文件重写的实现

重写功能并不需要对现有的AOF文件进行分析，这个功能是直接读取服务器当前的数据库状态，生成新的AOF文件，然后原子替换旧文件。

例如：

redis> SADD animals "Cat"    // {"Cat"}
(integer) 1
redis> SADD animals "Dog"    // {"Cat", "Dog" }
(integer) 1
redis> SADD animals "Panda"    // {"Cat", "Dog", "Panda" }
(integer) 1

为了记录animals键的状态，AOF文件必须保存上面3条写入命令。

AOF重写时，只需要读取animals键的值，然后用一条命令记录就行了。
但是实际上可能不一定是一条，因为为了避免客户端输入缓冲区溢出，重写列表、哈希表、集合、有序集合这四种可能存在很多元素时，如果元素个数超过redis.h/REDIS_AOF_REWRITE_ITEMS_RER_CMD常量值，就会将命令拆分成多条命令。

AOF后台重写

AOF重写程序aof_rewrite函数会进行大量的写入操作，调用这个函数的线程会被长时间阻塞（Redis服务器使用单线程处理命令请求），所以会导致重写AOF文件期间，服务器无法处理客户端发来的请求。

AOF重写作为一种辅佐性的维护手段，不能因为重写而导致服务器无法处理请求，所以Redis将AOF重写放到子进程执行：

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

在子进程重写AOF文件期间，父进程可能处理了新的写请求，会导致重写后的数据不一致，所以Redis又增加了一个AOF重写缓冲区，在服务器创建子进程的时候开始使用。

因此，在子进程执行AOF重写期间，服务器会执行一下三个工作：

1. 执行客户端发来的命令。
2. 将执行后的写命令追加道AOF缓冲区。
3. 将执行后的写命令追加道AOF重写缓冲区。

AOF缓冲区重写

子进程完成AOF重写工作后，会向父进程发送一个信号，父进程接收到信号后，会调用信号处理函数：

1. 将AOF重写缓冲区的内容，追加到新的aof文件下，这时数据状态保持一致了。
2. 对新的AOF文件进行改名，原子的替换掉旧的AOF文件。

为了保持数据一致，在信号处理函数执行时会对父进程造成阻塞，期间暂停对客户端请求的处理。这也是整个AOF后台重写唯一会阻塞父进程的地方。