AOF

当一个 Redis 客户端需要执行命令时， 它通过 网络连接 ， 将 协议文本 发送 给 Redis 服务器

比如说， 要执行命令 SET KEY VALUE

客户端将向服务器发送文本 "*3\r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVALUE\r\n" 

服务器在接到客户端的请求之后， 它会根据 协议文本的内容 ， 选择适当的 命令函数 ， 并将各个 参数 从 字符串 文本转换为 Redis 字符串对象 StringObject

比如说， 针对上面的 SET 命令例子， Redis 将客户端的命令指针指向实现 SET 命令的 setCommand 函数

并创建三个 Redis 字符串对象， 分别保存 SET 、 KEY 和 VALUE 三个参数（命令也算作参数）

每当命令函数 成功执行 之后， 命令参数 都会被 传播 到 AOF 程序 ， 以及 REPLICATION 程序。这个执行并传播命令的过程可以用以下伪代码表示：

if (execRedisCommand(cmd, argv, argc) == EXEC_SUCCESS):
    if aof_is_turn_on():
        propagate_aof(cmd, argv, argc) # 传播命令到 AOF 程序

    if replication_is_turn_on():
        propagate_replication(cmd, argv, argc) # 传播命令到 REPLICATION 程序

以下是该过程的流程图：

这里不讨论REPLICATION，列在这里只是为了完整性的考虑

当命令被传播到 AOF 程序之后， 程序会根据 命令 以及命令的 参数 ， 将命令从 字符串对象 转换 回 原来的协议文本

比如说， 如果 AOF 程序接受到的三个参数分别保存着 SET 、 KEY 和 VALUE 三个字符串

那么它将生成协议文本 "*3\r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVALUE\r\n" 

协议文本生成之后， 它会被追加到 edis.h/redisServer 结构的 aof_buf 末尾 。aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本：

struct redisServer {

    // 其他域...

    sds aof_buf;

    // 其他域...
};

至此， 追加命令到缓存的步骤执行完毕。综合起来，整个缓存追加过程可以分为以下三步：

1. 接受命令、命令的参数、以及参数的个数、所使用的数据库等信息
2. 将命令还原成 Redis 网络通讯协议
3. 将协议文本追加到 aof_buf 末尾

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

• WRITE：根据条件，将 aof_buf 中的缓存 写入 到 AOF 文件
• SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件 保存 到 磁盘 中

两个步骤都需要根据一定的条件来执行， 而这些 条件 由 AOF 所使用的 保存模式 来决定

实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是 数据库中键的当前值 。考虑这样一个情况， 如果服务器对键 list 执行了以下四条命令：

RPUSH list 1 2 3 4      // [1, 2, 3, 4]

RPOP list               // [1, 2, 3]

LPOP list               // [2, 3]

LPUSH list 1            // [1, 2, 3]

那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。如果要保存这个列表的当前状态， 并且尽量减少所使用的命令数， 那么最简单的方式不是去 AOF 文件上分析前面执行的四条命令， 而是直接 读取 list 键在数据库的 当前值 ， 然后用一条 RPUSH 1 2 3 命令来代替前面的四条命令

再考虑这样一个例子， 如果服务器对集合键 animal 执行了以下命令：

SADD animal cat                 // {cat}

SADD animal dog panda tiger     // {cat, dog, panda, tiger}

SREM animal cat                 // {dog, panda, tiger}

SADD animal cat lion            // {cat, lion, dog, panda, tiger}

那么使用一条 SADD animal cat lion dog panda tiger 命令， 就可以还原 animal 集合的状态， 这比之前的四条命令调用要大大减少

除了列表和集合之外， 字符串、有序集、哈希表等键也可以用类似的方法来保存状态

并且保存这些状态所使用的命令数量 比起 之前建立这些键的状态所使用命令的数量要 大大减少

根据键的 类型 ， 使用 适当的 写入命令 来重现 键的当前值 ， 这就是 AOF 重写的实现原理。 整个重写过程可以用伪代码表示如下：

def AOF_REWRITE(tmp_tile_name):

  f = create(tmp_tile_name)

  for db in redisServer.db:   # 遍历所有数据库
    if db.is_empty(): continue # 如果数据库为空，那么跳过这个数据库

    f.write_command("SELECT " + db.number) # 写入 SELECT 命令，用于切换数据库
    for key in db: # 遍历所有键
      if key.have_expire_time() and key.is_expired(): continue # 如果键带有过期时间，并且已经过期，那么跳过这个键

      if key.type == String: # 用 SET key value 命令来保存字符串键
        value = get_value_from_string(key)
        f.write_command("SET " + key + value)

      elif key.type == List: # 用 RPUSH key item1 item2 ... itemN 命令来保存列表键
        item1, item2, ..., itemN = get_item_from_list(key)
        f.write_command("RPUSH " + key + item1 + item2 + ... + itemN)

      elif key.type == Set: # 用 SADD key member1 member2 ... memberN 命令来保存集合键
        member1, member2, ..., memberN = get_member_from_set(key)
        f.write_command("SADD " + key + member1 + member2 + ... + memberN)

      elif key.type == Hash: # 用 HMSET key field1 value1 field2 value2 ... fieldN valueN 命令来保存哈希键
        field1, value1, field2, value2, ..., fieldN, valueN = get_field_and_value_from_hash(key)
        f.write_command("HMSET " + key + field1 + value1 + field2 + value2 + ... + fieldN + valueN)

      elif key.type == SortedSet: # 用 ZADD key score1 member1 score2 member2 ... scoreN memberN 命令来保存有序集键
        score1, member1, score2, member2, ..., scoreN, memberN = get_score_and_member_from_sorted_set(key)
        f.write_command("ZADD " + key + score1 + member1 + score2 + member2 + ... + scoreN + memberN)

      else:

        raise_type_error()

      if key.have_expire_time(): # 如果键带有过期时间，那么用 EXPIREAT key time 命令来保存键的过期时间
        f.write_command("EXPIREAT " + key + key.expire_time_in_unix_timestamp())

    f.close() # 关闭文件

上一节展示的 AOF 重写程序可以很好地完成创建一个新 AOF 文件的任务

但是， 在执行这个程序的时候， 调用者线程会被阻塞

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

1. 子进程进行 AOF 重写期间， 主进程 可以 继续处理 命令请求

2. 子进程带有主进程的 数据副本 ，使用子进程而 不是线程 ，可以在 避免锁 的情况下，保证 数据的安全性

   所谓的数据副本，就是 redisServer结构的db链表
   

不过， 使用子进程也有一个问题需要解决：因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令

而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致

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

换言之， 当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：

1. 处理命令请求
2. 将写命令追加到现有的 AOF 文件中
3. 将写命令追加到 AOF 重写缓存中

这样一来可以保证：

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

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

1. 将 AOF 重写缓存 中的内容全部 写入 到 新 AOF 文件 中

   当步骤 1 执行完毕之后， 现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了
   

2. 对 新的 AOF 文件 进行 改名 ，覆盖原有的 AOF 文件

   当步骤 2 执行完毕之后， 程序就完成了新旧两个 AOF 文件的交替
   

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

在其他时候， AOF 后台重写都不会对主进程造成阻塞， 这将 AOF 重写对性能造成的影响降到了最低

这就是 AOF 后台重写， 也即是 BGREWRITEAOF 命令的工作原理