先上图，相信网上这张图大家随意搜一下都能搜到，我相信你也能自己叙述一遍这张图的流程，话不多说，说一下AOF的重写执行流程吧？自己先叙述一遍图

aof日志文件只接收write命令，也就只存储增删改命令，不存储读命令

口述：

1）触发重写，执行bgrewriteaof命令

2）父进程fork子进程进行重写，fork子进程的同时父进程阻塞，fork完毕父进程继续接受指令（子进程只是父进程的快照（相当于复制了某时刻的父进程））

3.1）子进程在创建新的aof文件的同时，父进程继续接收write指令，存储到继续存到aof_buf缓存中和aof_rewirte_buf缓存中，所以父进程继续往旧的aof文件中备份，同时也要往新的AOf文件中备份。

4）新的aof备份完成

5.1）同时父进程，备份的新文件创建完成

5.2）将aof_rewrite_buf缓存中的备份到新的aof文件中

5.3) 新的文件替换就的aof文件

文字描述：

关于文件重写的流程，有两点需要特别注意：

(1)重写由父进程fork子进程进行；

(2)重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

对照上图，文件重写的流程如下：

1) Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。前面曾介绍过，这个主要是基于性能方面的考虑。

2) 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。

3.1) 父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。

3.2) 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

4) 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。

5.1) 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。

5.2) 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

5.3) 使用新的AOF文件替换老文件，完成AOF重写。

原文链接：https://mp.weixin.qq.com/s/PRPnt3xuAArsTNMxQshhTQ

作者：一起写程序