AOF（append only file）：以独立日志的方式记录每次写的命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
以下是AOF工作流程图：
一、开启AOF
Redis中默认不开启AOF，appendonly yes，是开启的配置。
文件的名字默认为appendonly.aof，可以通过参数appendfilename来设置。
目录也是通过dir来设置。
二、命令写入append
所有写入命令会追加到aof_buf（缓冲区）中。
三、文件同步sync
AOF缓冲区，根据策略向硬盘做同步。由参数appendfsync控制，常规使用everysec选项：
- always：命令写入aof_buf后，直接调用系统的fsync操作同步到AOF文件。
- everysec：命令写入aof_buf后，调用系统的write操作，write操作完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。
- no：命令写入aof_buf后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。
四、文件重写rewrite
随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。把Redis进程内的数据转化为写命令同步到新AOF文件的过程。AOF重写过程分为手动触发和自动触发：
- 手动触发：直接调用bgrewriteaof。
- 自动触发：根据auto-aof-rewrite-min-size（默认64M）和auto-aof-rewrite-percentage参数确定自动触发时机。
- 自动触发时机 = (aof_current_size > auto-aof-rewrite-min-size) && (aof_current_size / aof_base_size) > auto-aof-rewrite-percentage。
- 当前AOF文件大小：aof_current_size。
- 上一次重写后的AOF文件空间大小：aof_base_size。
- 其中aof_current_size和aof_base_size可以在命令info persistence的结果中查看到。
AOF重写流程如下：
- 执行AOF重写请求。
- 如果当前进程正在执行AOF重写，请求不执行，直接返回。
- 如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行。
- 主进程执行fork操作完成后，继续响应其他命令。所有修改命令继续写入aof_buf缓冲区中并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
- fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认为32M。
- 父进程将重写缓冲区内的数据写入到新的AOF文件中。
- 使用新的AOF文件替换老文件，完成AOF重写。
五、重启加载load
当Redis服务器重启时，可以加载AOF文件进行数据恢复。
如上图，流程说明：
- AOF持久化开启且存在AOF文件时，优先加载AOF文件。
- AOF关闭或者AOF文件不存在时，加载RDB文件。
- 加载AOF/RDB文件成功后，Redis启动成功。
- AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
六、文件校验
对于错误格式的AOF文件：先进行备份，然后采用redis-check-aof --fix命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据。
AOF文件结尾不完整的情况下：可以使用aof-load-truncated配置来兼容这种情况。
转载地址：https://blog.csdn.net/jiangxiulilinux/article/details/104908226
