AOF持久化策略
Append only file，采用追加的方式保存
默认文件appendonly.aof
记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库
调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多
AOF写入机制
AOF方式不能保证绝对不丢失数据
目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失
写入磁盘的策略
appendfsync选项，这个选项的值可以是always、everysec或者no
always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
运行速度：always的速度慢，everysec和no都很快
AOF重写机制
AOF文件过大
合并重复的操作，AOF会使用尽可能少的命令来记录
重写过程
1、执行AOF重写请求
2、父进程执行fork创建子进程，开销等同于bgsave过程
3.1、主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区，并根据appendfsync策略同步到磁盘，保证原有AOF机制正确性。
3.2、由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4、子进程根据内存快照，按照命令合并规则写入到新AOF文件。每次批量写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
5.1、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
5.2、父进程把AOF重写缓冲区数据写入到新的AOF文件。
5.3、使用新AOF文件替换老文件，完成AOF重写。
注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复
AOF重写触发
手动：客户端向服务器发送BGREWRITEAOF命令
自动：配置文件中的选项，自动执行BGREWRITEAOF命令
auto-aof-rewrite-min-size ，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是 否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写死循环
auto-aof-rewrite-percentage ，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写
AOF重写配置项举例
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendonly no / yes
当AOF文件大于64MB时候，可以考虑重写AOF文件
只有当AOF文件的增量大于起始size的100%时（就是文件大小翻了一倍），启动重写
默认关闭，请开启
优点
写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
重写机制，优化AOF文件
如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
缺点
相同数据集，AOF文件体积较RDB大了很多
恢复数据库速度比RDB慢（文本，命令重演）