介绍
AOF（Append Only File）是以日志的形式来记录每个写操作（增量保存），将redis执行过程中的所有写指令记录下来（读记录不记录），只许追加文件但不可以改写文件，redis启动之后会读取该文件重新构建数据，或者说，redis重启的话就根据日志文件的内容将写指令从前到后执行一次完成数据的恢复工作。
修改配置项
打开/etc/redis.conf文件，修改内容如下：
appendonly yes
appendfilename "appendonly.aof"
启动服务后，会自动生成aof文件，如下：
注意：当AOF和RDB同时开启时，默认读取AOF，所以查看数据时是空。
我们添加数据，看一下AOF文件大小，如下：
备份与恢复
停掉redis服务，将appendonly.aof复制一份，如下：
cp appendonly.aof appendonly.aof.bak
将appendonly.aof文件删除，如下：
rm -rf appendonly.aof
我们将刚才复制的文件进行重命名，如下：
mv appendonly.aof.bak appendonly.aof
启动redis服务，看看是否会按照aof文件记录的写操作进行数据恢复，如下：
修复
我们将redis服务停掉，在AOF文件的末尾追加一些符号，如下：
vi appendonly.aof
保存后，启动redis服务，用客户端连接，如下：
redis-server /etc/redis.conf
我们发现客户端连接被拒绝了，接下来我们使用修复工具进行修复，如下：
redis-check-aof --fix appendonly.aof
检测到了前缀是'h'，输入y进行修复，如下：
此时我们再次打开appendonly.aof文件，查看hello还在不在，如下：
我们现在启动redis服务，查看是否可以连接，数据是否正常，如下：
使用redis-append-aof修复完成。
重写机制
AOF的重写默认设置，如下：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
当aof文件大小>=base_size + base_size*100%>=64mb的情况下，redis会对aof进行重写。
- bgrewriteaof出发重写，判断当前是否有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
- 主进程fork出子进程执行重写操作，保证主进程不会被阻塞
- 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入
aof_buf和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF生成期间的新数据修改动作不丢失 - 子进程写完新的AOF文件后，向主进程发出信号，父进程更新统计信息，主进程把aof_rewrite_buf中的数据写入到新的AOF文件中
- 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写
优势和劣势
优势：
- 备份机制更稳健，丢失数据概率更低
- 可读的日志文本，通过操作AOF文件处理误操作
劣势：
- 比起RDB占用更多的磁盘空间
- 恢复备份速度慢
- 每次读写都同步，有一定的性能压力
- 存在个别Bug，造成不能恢复
官方建议
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令恢复数据，AOF命令以redis协议追加保存每次写的操作到文件末尾
- Redis还能对AOF文件进行后台重写，是的AOF文件的大小不至于过大
- 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不适用任何持久化方式
- 同时开启两种持久化方式，在这种情况下，当redis重启的时候会优先载入AOF文件来回复原始数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据更完整
- RDB的数据不实时，同时使用两者时服务器重启只会找AOF文件，那要不要考虑只使用AOF呢？
- 建议不要因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段
- 性能建议