1、什么是AOF

AOF（APPEND ONLY MODE），即追加模式。是redis持久化的一种方案。它采用日志的形式，记录每一个写操作指令，并追加到文件中。redis重启后加载aof文件，将aof文件中的指令在执行一次，达到数据恢复的效果。

2、AOF原理

1.命令传播：

Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。

2.缓存追加：

AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。

3.文件写入和保存：

AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

image.png

3、AOF持久化配置

AOF持久化的配置都在redis.conf配置文件中的APPEND ONLY MODE模块中。

1.开启AOF持久化，将appendonly改为yes。

image.png

2.配置AOF文件名

默认为 appendonly.aof，尽量不要修改用默认的。

image.png

3。配置同步策略

每执行一次写操作都做一次同步
appendfsync always 

每一秒做一次同步操作，默认配置
appendfsync everysec 

不做同步操作
appendfsync no

image.png

4、AOF重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

AOF重写不是在原本的.aof文件上操作，而是直接读取redis服务器上的键值对，用一条命令去代替之前记录这个键值对的多条命令，生成一个新的aof文件去覆盖旧的文件。

image.png

5、AOF重写过程

AOF重写的过程与RDB持久化过程相似。
1：fork一个子进程，重写操作在子进程中进程。
2：子进程中对redis服务器中的键值对去生成记录命令，追加到文件中。
3：子进程给父进程发送一个信号，父进程将重写过程中redis服务器执行的写操作指令追加到心得AOF文件中。

6、重写缓冲区

在重写的过程中可能会出现一个问题。重写时，redis服务器仍然在接收处理其他命令，新的命令可能对数据库做了修改，使得当前数据库与重写后得AOF文件不一致。redis为解决这个问题设置了重写缓冲区。

重写缓冲区在创建子进程后开始使用。重写过程中redis服务器执行一个写命令后，这个命令会被存储到重写缓冲区中。当子进程完成重写后，就会被父进程发送一个信号。父进程将重写缓冲区中命令追加到AOF文件中

7、重写配置

默认为no，不会丢数据。重写过程中redis为阻塞状态，无法执行 
其他命令。设置为yes由子进程去执行重写操作，主进程继续接收处理命令。 
主进程执行得命令存储到重写缓冲区，重写完成后在追加到aof文件， 
如果此时redis挂了，那么缓冲区中的数据将会丢失。 
no-appendfsync-on-rewrite no

默认值为100。aof自动重写配置，当目前aof文件大小超过上一次 
重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一 
定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。 
当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置 
为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸 
仍然很小的情况还要重写。
auto-aof-rewrite-min-size 64mb 

aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数 
据被载入内存。重启可能发生在redis所在的主机操作系统宕机 
后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现 
象  redis宕机或者异常终止不会造成尾部不完整现象，可以选择让 
redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断 
的aof文件被导入的时候，会自动发布一个log给客户端然后load。 
如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。
aof-load-truncated yes

8、aof文件修复

命令： redis-check-aof --fix *.aof

9、AOF优缺点

优点：

• AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
• AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
• AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

缺点：

• 对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
• 虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
• RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。