AOF（Append Of File）
1 概念
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有指令记录下来（读操作不记录），只需追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，即按照文件内容将指令从头到尾执行一遍
2 AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内
（2）AOF缓冲区根据AOF持久化策略[always，everysec，no]将操作sync同步到磁盘的AOF文件中
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
（4）Redis服务重启时，会重新Load加载AOF文件中的写操作达到数据恢复的目的
3 AOF配置
AOF默认不开启，可以在redis.conf中配置文件名称，默认为appendonly.aof，AOF文件的保存路径和RDB的路径一致
配置文件中默认为no，文件名称默认为appendonly.aof
将其改为yes，则开启AOF
重启redis后，可以看到生成了对应文件
当AOF和RDB同时开启时，系统会默认取AOF的数据
4 异常恢复
如果AOF文件意外损坏，可以通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
用vi命令打开appendonly.aof文件并在其后随便追加一个无用信息
重新启动redis后，启动客户端失败，因为无法正确读取AOF文件
此时输入上述命令对aof文件进行修复
此时，正确连接并成功读取数据
5 AOF同步频率设置
同步频率设置分为三种
（1）appendfsync always：
表示始终同步，每次Redis的写入都会立刻记入日志，性能较差但是数据完整性比较好
（2）appendfsync evverysec
每秒同步，每秒计入日志一次，如果此时崩溃，可能会丢失本秒的数据
（3）appendfsync no
不主动同步，把同步时机交给操作系统
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1artBSYI-1634217992319)(/Users/sundaohan/Library/Application Support/typora-user-images/image-20211014210243169.png)]
6 Rewrite压缩
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制，当AOF文件的大小超过所设定的阈值时, Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaofs
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写( 也是先写临时文件最后再rename) ，redis4.0版本后的重写，就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据,替换掉原来的流水账操作。
7 优势
（1）备份机制更稳健，丢失数据概率更低
（2）可读的日志文本，通过操作AOF文件，可以处理误操作
8 劣势
（1）比起RDB占用空间更大
（2）恢复备份速度慢
（3）每次读写都同步的话，性能压力大
不推荐单独使用AOF，最好是RDB和AOF都启用，以免出现Bug