Redis中的AOF工作流程

AOF（append only file）：以独立日志的方式记录每次写的命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

以下是AOF工作流程图：

一、开启AOF

Redis中默认不开启AOF，appendonly yes，是开启的配置。

文件的名字默认为appendonly.aof，可以通过参数appendfilename来设置。

目录也是通过dir来设置。

二、命令写入append

所有写入命令会追加到aof_buf（缓冲区）中。

三、文件同步sync

AOF缓冲区，根据策略向硬盘做同步。由参数appendfsync控制，常规使用everysec选项：

1. always：命令写入aof_buf后，直接调用系统的fsync操作同步到AOF文件。
2. everysec：命令写入aof_buf后，调用系统的write操作，write操作完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。
3. no：命令写入aof_buf后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。

四、文件重写rewrite

随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。把Redis进程内的数据转化为写命令同步到新AOF文件的过程。AOF重写过程分为手动触发和自动触发：

1. 手动触发：直接调用bgrewriteaof。
2. 自动触发：根据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重写流程如下：

1. 执行AOF重写请求。
2. 如果当前进程正在执行AOF重写，请求不执行，直接返回。
3. 如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行。
4. 主进程执行fork操作完成后，继续响应其他命令。所有修改命令继续写入aof_buf缓冲区中并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
5. fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认为32M。
6. 父进程将重写缓冲区内的数据写入到新的AOF文件中。
7. 使用新的AOF文件替换老文件，完成AOF重写。

五、重启加载load

当Redis服务器重启时，可以加载AOF文件进行数据恢复。

如上图，流程说明：

1. AOF持久化开启且存在AOF文件时，优先加载AOF文件。
2. AOF关闭或者AOF文件不存在时，加载RDB文件。
3. 加载AOF/RDB文件成功后，Redis启动成功。
4. AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

六、文件校验

对于错误格式的AOF文件：先进行备份，然后采用redis-check-aof --fix命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据。

AOF文件结尾不完整的情况下：可以使用aof-load-truncated配置来兼容这种情况。

转载地址：https://blog.csdn.net/jiangxiulilinux/article/details/104908226