Redis的持久化AOF模式，以日志的形式记录服务器所处理的每一个写操作，在Redis服务启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

AOF的优点：

1、可以带来更高的数据安全性。

2、由于对日志文件的写入操作采用的是append模式，因此在写入过程汇总即使出现宕机，也不会破坏日志文件中已经存在的内容，然而如果我们本次操作写入一半数据就出现系统崩溃，可以在Redis下一次启动之前，通过redis-check-aof工具帮助解决数据一致性的问题。

3、如果日志过大，Redis可以启动rewrite机制，即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改指令被执行，rewrite切换时可以更好的保证数据安全性。

4、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，可以通过该文件完成数据的重建。

AOF的缺点：

1、相同的数据的数据集，AOF文件通常要大于RDB文件。

2、同步策略的不同，AOF在运行效率上往往会慢于RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

在Redis的配置文件中存在三种同步方式，它们分别是：

1、appendfsync always：每次有数据修改发生时都会写入AOF文件。

2、appendfsync everysec：每秒钟同步一次，该策略为AOF的缺省策略。

3、appendfsyn no：从不同步，高效的那是数据不会被持久化。

如何修复损坏的AOF文件？

1、将现有已经损坏的AOF文件额外复制出来一份。

2、执行'redis-check-aof -- fix '命令来修复损坏的AOF文件。

3、用修复后的AOF文件重新启动Redis服务。

redis.conf的配置，将appendonly改为yes

Redis一启动就会在dir目录下生成appendonly.aof，开始这个文件是0字节的。<??http://www.2cto.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+PGltZyBzcmM9"https://www.cppentry.com/upload_files/article/57/1_purh1__.jpg" alt="\">

查看key，有多少

dump.rdb文件时33字节，为什么之前设置的key,没有了呢？

原因：一旦appendonly设置为yes，系统会优先读appendonly.aof文件，而不是dump.rdb

由于appendonly.aof是空的，所以看到key也是空的。

设置一些key

appendonly.aof就变成了112字节

查看appendonly.aof文件，其实是将上面设置的命令记录了一下。

AOF的启动装载

1、AOF优先于RDB

2、RDB的性能优于AOF，因为没有重复

3、Redis一次性将数据加载到内存中，一次性预热

Redis的装载源码如下：

AOF的rewrite

AOF的rewrite参数