除了 RDB 持久化之外，Redis 还提供了 AOF（Append Only File）持久化功能。与 RDB 持久化通过保存数据库中键值对来保存数据库的状态不同，AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库的状态
AOF 持久化的实现
AOF 持久化功能的实现可以分为：命令追加（append），文件写入（write），文件同步（sync）三个步骤
命令追加
AOF 持久化需要将所有写命令记录在文件中来保存服务器状态，而文件写入操作效率比较低，如果每执行一条写命令都要写一次 AOF 文件无疑是低效的。为了提高效率，Redis 提供了一个中间层 – AOF 缓冲区，也就是说当 Redis 执行一条写命令后，先将该命令追加到 AOF 缓冲区中，在以后的某个时刻再将 AOF 缓冲区中的内容同步到文件中
当 AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾
AOF 文件的写入与同步
Redis 的服务器进程就是一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像 serverCron 函数这样需要定时运行的函数
因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到 aof_buf 缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数，考虑是否需要将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件里面：
def eventLoop():
while True:
# 处理文件事件，接收命令请求以及发送命令回复
# 处理命令请求时可能会有新内容被追加到 aof_buf 缓冲区中
processFileEvents()
# 处理时间事件
processTimeEvents()
# 考虑是否要将 aof_buf 中的内容写入和保存到 AOF 文件里面
flushAppendOnlyFile()
flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定：
-
AOF_FSYNC_NO
在该模式下，Redis 服务器在每个事件循环都将 AOF 缓冲区中的数据写入 AOF 文件中，但不执行同步 fsync 方法，由操作系统决定何时同步。该模式速度最快（无需执行同步操作）但也最不安全（如果机器崩溃将丢失上次同步后的所有数据） -
AOF_FSYNC_ALWAYS
在该模式下，Redis 服务器在每个事件循环都将 AOF 缓冲区中的数据写入 AOF 文件中，且执行一次 AOF 文件同步操作。该模式速度最慢（每个事件循环都要执行同步操作）但也最安全（如果机器崩溃只丢失当前事件循环中处理的新数据） -
AOF_FSYNC_EVERYSEC
在该模式下，Redis 服务器在每个事件循环都将 AOF 缓冲区中的数据写入 AOF 文件中，且每秒执行一次 AOF 文件同步操作。该模式效率和安全性（如果机器崩溃只丢失前一秒处理的新数据）比较适中，是 Redis 的默认同步策略
AOF 文件的载入与数据还原
因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样
AOF 重写
AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以 AOF 文件的大小随着时间的流逝一定会越来越大；影响包括但不限于：对于 Redis 服务器，计算机的存储压力；AOF 还原出数据库状态的时间增加
为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 重写功能：Redis 服务器可以创建一个新的 AOF 文件来替代现有的 AOF 文件，新旧两个文件所保存的数据库状态是相同的，但是新的 AOF 文件不会包含任何浪费空间的冗余命令，通常体积会较旧 AOF 文件小很多
AOF 文件重写的实现
AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或写入操作，这个功能时通过读取服务器当前的数据状态来实现的
实现原理：遍历数据库中的所有键（忽略已过期的键），读取键现在的值，用一条命令去记录键值对，代替之前修改该键值对的多个命令
在实际中，为了避免执行命令时造成客户端输入缓冲区溢出，重写程序在处理列表、哈希、集合、有序集合这四种可能会带有多个元素的键时，会先检查键所包含的元素数量，如果超过某个限制，会使用多条命令来记录键的值，而不单单使用一条命令
AOF 后台重写
aof_rewrite 函数可以创建新的 AOF 文件，但是这个函数会进行大量的写入操作，所以调用这个函数的线程将被长时间的阻塞，因为 Redis 服务器使用单线程来处理命令请求；所以如果直接是服务器进程调用 aof_rewrite 函数的话，那么重写 AOF 期间，服务器将无法处理客户端发送来的命令请求
Redis 不希望 AOF 重写会造成服务器无法处理请求，所以 Redis 决定将 AOF 重写程序放到子进程（后台）里执行。这样处理的最大好处是：
- 子进程进行 AOF 重写期间，主进程可以继续处理命令请求；
- 子进程带有主进程的数据副本，使用子进程而不是线程，可以避免在锁的情况下，保证数据的安全性
使用子进程进行 AOF 重写的问题
子进程在进行 AOF 重写期间，服务器进程还要继续处理命令请求，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致
如何修正
为了解决这种数据不一致的问题，Redis 增加了一个AOF 重写缓冲区，这个缓冲区在 fork 出子进程之后开始启用，Redis 服务器主进程在执行完写命令之后，会同时将这个写命令追加到 AOF 缓冲区和 AOF 重写缓冲区
即子进程在执行 AOF 重写时，主进程需要执行以下三个工作：
- 执行 client 发来的命令请求
- 将写命令追加到现有的 AOF 文件中
- 将写命令追加到 AOF 重写缓存中
可以保证：
- AOF 缓冲区的内容会定期被写入和同步到 AOF 文件中，对现有的 AOF 文件的处理工作会正常进行
- 从创建子进程开始，服务器执行的所有写操作都会被记录到 AOF 重写缓冲区中
当子进程完成对 AOF 文件重写之后，它会向父进程发送一个完成信号，父进程接到该完成信号之后，会调用一个信号处理函数，该函数完成以下工作：
- 将 AOF 重写缓存中的内容全部写入到新的 AOF 文件中；这个时候新的 AOF 文件所保存的数据库状态和服务器当前的数据库状态一致
- 对新的 AOF 文件进行改名，原子地覆盖原有的 AOF 文件；完成新旧两个 AOF 文件的替换
当这个信号处理函数执行完毕之后，主进程就可以继续像往常一样接收命令请求了
在整个 AOF 后台重写过程中，只有最后的信号处理函数执行时会造成主进程阻塞，在其他时候，AOF 后台重写都不会对主进程造成阻塞，这将 AOF 重写对性能造成的影响降到最低
以上，即 AOF 后台重写，也就是 BGREWRITEAOF 命令的工作原理
网友评论