1、背景

AOF（Append Only File）是redis提供的持久化机制之一，它通过记录所有修改数据库状态的写命令来实现数据库持久化。与RDB（快照）方式不同，AOF记录的是操作过程而非数据状态。

2、工作原理

AOF的工作原理如下：

1、命令记录：当AOF开启时，redis会将每个写命令追加到AOF缓冲区
2、文件同步：根据配置策略将缓冲去内容写入AOF文件
3、文件重写：定期执行AOF重写以压缩文件大小

3、核心配置参数

AOF在redis.conf的相关配置如下：

[root@xxx]# cat /xxx/redis.conf | grep -E 'append|auto-aof'
appendonly yes #启用AOF持久化
appendfilename "xxx" #AOF文件名，没配置默认文件名为appendonly.aof
appendfsync everysec #同步策略
no-appendfsync-on-rewrite yes #控制AOF重写期间是否执行主进程的fsync同步操作
auto-aof-rewrite-percentage 300 #触发重写的增长比例
auto-aof-rewrite-min-size 1G #触发重写的最小文件大小

同步策略（appendfsync ）有三种：

1、always：每个写命令都同步到磁盘，最安全但性能最低
2、everysec（默认）：每秒同步一次，平衡安全性和性能
3、no：由操作系统决定同步时机，性能最好但是可能丢失数据

需要注意no-appendfsync-on-rewrite这个配置的作用机制：

<1>当设置为yes时

1、在AOF重写期间，主进程不会调用fsync来同步AOF文件
2、即使配置了appendfsync 也会被暂时忽略
3、可以显著提供重写期间的性能，减少I/O阻塞

<2>当设置为no时

1、在AOF重写期间，主进程仍会按照配置的appendfsync策略同步AOF文件
2、保证更高的数据安全性，但可能会影响重写性能

4、优缺点

AOF的优缺点如下：

优点	缺点
数据安全性高：可配置不同级别的同步策略（always/everysec/no）	文件体积大：记录所有写命令，长期运行后文件可能远大于RDB
可读性强：AOF文件是纯文本格式，便于人工检查或修复	恢复速度慢：重启时需要重新执行所有命令，比RDB加载慢
容错性好：即使文件部分损坏，仍可通过redis-check-aof工具修复	写入性能开销：相比RDB，AOF通常有更高的写入负载（取决于同步策略）
实时性高：默认每秒同步，最多丢失1秒数据	重写期间可能阻塞：AOF重写时（尤其是大实例）可能短暂影响性能
操作粒度细：记录每个写命令，可精确到命令级别恢复	历史兼容性问题：不同redis版本的AOF格式可能有细微差异
支持混合持久化（redis 4.0+）：结合RDB和AOF优势	配置复杂度高：需合理设置同步策略，重写触发条件等参数

5、AOF文件内容

客户端连接redis执行如下命令：

[root@xxx]# /xxx/redis-cli -h 127.0.0.1 -p 6379 -a xxx
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:16379> select 2 #使用2号库
OK
127.0.0.1:16379[2]> set XXX YYY #设置key=XXX，value=YYY
OK

AOF文件输出如下：

[root@xxx]# tail -f /xxx/appendonly.aof
*2 #表示这部分操作有2个部分
$6 #表示SELECT命令有6个字节
SELECT
$1 #表示使用的2号数据库这个2有1个字节
2
*3 #表示这部分操作有3个部分
$3 #表示set命令有3个字节
set
$3 #表示设置的键XXX有3个字节
XXX
$3
YYY #表示设置的值YYY有3个字节