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 <filename>‘命令来修复损坏的AOF文件。
3、用修复后的AOF文件重新启动Redis服务。
redis.conf的配置，将appendonly改为yes
Redis一启动就会在dir目录下生成appendonly.aof，开始这个文件是0字节的。
查看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参数
