1. AOF 是什么？
Append only File，是以日志的形式来记录每个写操作（增量保存），将 redis 执行过的所有写指令记录下来（读指令不记录），只能追加文件，不可以改写文件。redis 启动之初会读取该文件重新构建数据，即，redis 重启就根据日志文件内容将写指令从前到后执行一次以完成数据恢复
2. Redis 中 RDB 默认开启，但是 AOF 默认不开启
在 redis.conf 中，appendonly 参数 默认 no，可改为 yes 打开，文件名为 appendonly.aof
文件路径同 RDB
3. RDB 和 AOF 都开启，redis 听谁的？
听 AOF 的，因为数据不会存在丢失
4. 若 aof 文件损坏，如何异常恢复？
通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复
5. AOF 同步频率设置
appendfsync always
始终同步，每次redis的写入都会立刻记入日志，性能较差，但数据完整性好
appendfsync everysec
每秒同步
appendfsync no
redis 不主动进行同步，把同步时机交给操作系统
6. 重写压缩 （Rewrite 压缩）
如果操作了 set a a1 也操作了 set b b1
那么最终记录得到的是 set a a1 b b1（最终写一个总的，不关注中间操作了什么）
7. 重写的原理？
AOF 文件持续增长而过大时，会 fork 出一个新进程将文件重写（也是先写临时文件，再rename，同 RDB）
redis 4.0 版本之后的重写，是将 rdb 的快照，以二进制的形式赋值在新的 aof 的头部，作为已有的历史数据，替换原来的流水账操作
8. 重写触发条件
AOF 当前大小 >= 64 M + 64 M * 100%（即 128 M）才会重写
9. 缺点
（1）比 RDB 占用更多的磁盘空间
（2）恢复备份速度慢
（3）每次读写都同步的话，有一定的性能压力
