redis持久化之AOF原理（个人复习用）

AOF持久化实现

与rdb持久化保存数据库中的键值对不同，aof持久化是保存redis服务器所执行的写命令来记录数据库的

持久化分为三个步骤：追加，文件写入和文件同步

追加

当aof持久化功能打开时候，服务器在执行完一个命令后，会将aop命令追加到aop缓存区的末尾，如下图

写入和同步

redis服务器进行就是一个事件循环，文件事件负责接收客户端的请求。事件事件则都是运行函数，如servercron。servercron每次在一个事件事件里面都会调用flushAppendOnlyFile函数，而flushAppendOnlyFile函数的行为由
apendfsync配置文件的参数决定，如下图

AOF的载入和还原

服务器只要读取并重新执行一遍命令，就可以还原服务器关闭之前的姿态，具体流程如下图

AOF重写

aof文件过大，会自动触发重写aof操作。通过aof_rewrite函数，将多个冗余的命令合并为一个命令（通过读取当前数据库的值，而不是重写原有aof文件实现的）
apf重写并不会对现有aof文件作任何读取分析写入的操作，这个功能主要是通过读取服务器当前的数据库状态实现的。
重写后的文件只包含还原当前数据库必要的命令。过期的不会写入aof文件

AOF后台重写

上一节展示的 AOF 重写程序可以很好地完成创建一个新 AOF 文件的任务， 但是， 在执行这个程序的时候， 调用者线程会被阻塞。

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

子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。
不过， 使用子进程也有一个问题需要解决： 因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

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