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文件并还原数据库状态的详细步骤如下：

创建一个不带网络链接的伪客户端（fake client），它执行命令的效果和带网络连接的客户端执行命令效果完全一样。
从AOF文件中分析并读取一条写命令，使用伪客户端执行该命令。
重复执行步骤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重写期间，服务器会执行一下三个工作：

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

AOF缓冲区重写

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

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

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