参考：《Redis设计与实现》
文章目录
1、AOF文件作用
AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态（服务器中非空数据库以及它们的键值对）的。被写入AOF文件的所有命令都是以Redis的命令请求协议格式来保存的，Redis命令请求协议是纯文本格式。
服务器在启动的时候，通过载入和执行 AOF文件中保存的命令来还原服务器关闭之前的数据库状态。
2、AOF持久化实现
1、命令追加
当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将执行的写命令追加到服务器的aof_buf缓冲区末尾
2、AOF文件写入和同步
这一章看下来其实还是会有不理解的地方，比如说写入和同步的区别是什么，所以就从网上找了答案，因为对OS不熟悉，正常熟悉OS应该是理解这一步所讲述的才对。 参考地址：SegmentFault
在AOF持久化的过程中，其实上是分成两个部分:
- WRITE（写入）：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。
- SAVE（同步）：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。
服务器在处理文件时间时可能会执行写命令，把一些内容追加到aof缓冲区，所以在服务器每结束一次事件循环（负责节后客户端的命令请求，以及向客户端发送命令回复）之前，都会调用flushAppendOnlyFile函数，考虑是否把aof缓冲区的内容写入和保存到AOF文件中。
flushAppendOnlyFile的行为由服务器配置的appendfsync选项决定，这个选项对应的参数和含义：
| 参数值 | 含义 |
|---|---|
| always | 每次写入aof_buf缓冲区都把内容写入和同步到AOF文件 |
| everysec(默认) | 如果上次同步AOF文件的时间距离超过一秒，对AoF文件进行同步（由专门的线程进行负责） |
| no | 将aof_buf缓冲区内容写入AOF文件，但是不对AOF文件进行同步，由系统来决定 |
redis默认的文件同步配置是everysec，也就是说每隔一秒对AOF文件进行一次同步，这样做主要是为了在效率（执行同步需要消耗cpu时间）和安全（文件丢失）之间取得一个平衡，在服务器出现故障的情况下，最多丢失一秒的数据。
3、AOF文件载入与数据还原
AOF文件中包含重建数据库状态的所有写命令，所以服务器只要读入并重新执行一遍AOF文件保存的写命令，就可以还原关闭前的数据库状态。
文件载入还原的操作过程图示：
4、AOF重写（BGREWRITEAOF）
1、AOF重写的必要性
主要包含下面两个原因，归纳总结：
- 随着服务器运行时间的流逝，AOF文件体积会逐步变大，这就造成可能对Redis服务器的影响以及数据状态还原的时间变长
- 随着服务器运行时间的流逝，对于一个redis键值对的修改可能包含不止一条命令，而可以把命令进行压缩成一条，所以过多的命令是表达过程，而不是结果
2、AOF重写的实现
1、特点
AOF重写实现的特点：
- 不需要对现有的AOF文件进行任何读取、分析或者写入操作
- 直接从redis数据库的键值对生成对应的redis命令(比如说之前的操作是三个命令添加了10个值,而这种方式可以直接通过一条命令去生成这个键值对的最终状态)
- 为了防止客户端输入缓冲区溢出，如果元素超过redis.h/REDIS_AOF_REWRITE_ITEMS_FER_CMD配置的常量值，重写程序就会用多条命令来记录键的值
2、子进程处理
redis不希望AOF重写的时候无法处理请求，所以redis把AOF重写放在子进程中执行，这样做可以同时达到两个目的：
- 子进程在进行AOF重写期间，服务器进程可以继续执行命令请求
- 子进程携带父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性
3、AOF重写缓冲区
子进程在进行AOF重写的时候，服务器进程还需要继续处理命令，新的命令会对现在的数据库状态进行修改，导致当前的数据库状态和AOF重写之后的状态不一致。
为了解决上述的不一致问题，redis设置了一个AOF重写缓冲区，在执行一个写命令的时候会同时把该命令发送给AOF缓冲区和AOF重写缓冲区。主要是为了保证两个操作都能正常完成：
- AOF缓冲区内容可以定期写入并同步到AOF文件
- 创建子进程之后，服务器处理的命令会写入到AOF重写缓冲区
4、新AOF文件生成处理
当AOF重写工作完成之后，子进程会向服务器进程发送一个信号，这个时候就会触发AOF新文件生成的操作，分为两步：
- 将AOF重写缓冲区的所有内容写入到新的AOF文件中，
- 对新的AOF文件进程改名，原子性的覆盖现有的AOF文件，完成新旧文件的替换