AOF
Append only file 的缩写，以日志的形式记录每个写操作，将 Redis 执行过程过的所有写指令记录下来，只允许添加文件，不允许修改已经被保存的内容；
Redis 重启以后，根据日志记录的内容，将指令再次执行一次，以达到恢复数据的目的；
appendonly.aof 文件
在配置文件设定的，AOF 保存的是该文件 ；
AOF 的启动
在配置文件里面设置
AOF 的修复
AOF 文件是有可能损坏的，必须在写的过程中，恰好断电了，或者网络延迟，数据传输丢失，导致 AOF 文件的内容缺失 ；
这时候，使用 redis-check-aof --fix aof文件名字 进行修复，其实修复很简单，就是将不符合 redis 协议格式的数据清除掉 ；
AOF 的恢复
将 AOF 文件放到 redis 的安装目录下，Redis 重启就会对其进行加载读取，恢复数据 ；
AOF 和 RDB
两者可以共存，但是当两者都存在时，Redis 优先读取 AOF 进行数据的恢复 ；
Rewrite
AOF 文件会变得越来越大，这是毋庸置疑的，毕竟一直在记录写操作命令 ；
当文件大小超过规定的阈值时， redis 会 fork 一条新的进程，进行重写 AOF 文件夹，进行一定的压缩 ；
重写的时候，先在临时文件里面操作，写完以后，在重命名为 AOF 文件 ；
重写，并不是读取原有的 AOF 文件，而是在新进程中，读取内存的所有数据，用命令记录，重写一个新的 AOF 文件，这会造成一定的 IO 阻塞 ；
在重写的时候，Redis 会进行只保留能恢复数据的最小指令，比如，有多条 incr xx 命令 ，redis 会直接记录为一条 incrby xx x ；对于复杂的命令，redis 会进行一定的优化 ；
Rewrite 触发机制
Redis 会记录上次的 AOF 文件的大小，当当前的 AOF 文件的大小，达到上次 AOF 文件大小的一倍，且大于 64M 的时候，就会进行 Rewrite 操作 ；
优势
数据丢失的概率很低
AOF 对于记录操作的频率有三个选择
appendfsync always同步持久化，每当有写操作，就立即记录到磁盘，这样做，性能较差，比较是同步的，但是数据绝对的一致 ；appendfsync everysec异步操作，每过一秒，才将一秒之内的写命令进行同步。如果一秒之内宕机，则会丢失数据，基本可以忽略不计；appendfsync no表示不同步，让操作系统自己想什么就什么时候，去刷新缓冲区，然后将进行对磁盘的写，这种效率最快；
劣势
- 相同大小的数据，进行
AOF备份的文件比进行RDB备份的文件要大 ； AOF运行效率要比RDB慢；
RDB VS AOF
同时使用 ；
虽然 AOF 记录的数据更多，并且重启加载，先加载 AOF 文件的，但是 RDB 也需要留着，因为 AOF 有潜在的错误的可能性；