与RDB持久化通过保存数据库中的键值对来记录数据库中的的状态不同，AOF持久化是通过保存Redis服务器所执行的命令来记录数据库状态的

开启AOF

      默认情况下，redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启，我们修改配置文件或者在命令行直接使用config set修改，AOF 保存文件的位置和 RDB 保存文件的位置一样，都是通过 redis.conf 配置文件的 dir 配置，可以过 config get dir 命令获取保存的路径。

恢复AOF文件

重启redis然后重新加载

异常修复

redis-check-aof --fix 进行修复

AOF的重写

       由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，创建一个新的Aof文件来替换现有的aof文件

        Redis 是单线程工作，会将AOF 重写程序放到子进程中进行，这样服务器进程（父进程）可以继续处理其他命令此外Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。这样就解决了因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。

AOF的优点

（1）AOF 持久化数据更完整，秒级数据丢失(取决于设置fsync策略)。

（2）AOF日志文件是一个纯追加的文件。就算服务器突然停止，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以进行修复。

（3）AOF可读性很强，很容易导出来用于恢复数据。例如我们不小心用

FLUSHALL

AOF的缺点

（1）对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。

（2）相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。

（3）RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

AOF 和 RDB如何选择？

（1）不要只使用RDB，因为那样会导致丢失很多数据 
（2）也不要只使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug 
（3）结合使用AOF和RDB两种持久化机，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复