AOF（Append-Only-File）持久化：保存写状态
- 记录下除了查询以外的所有变更数据库状态的指令
- 以append的形式追加保存到AOF文件中（增量）
解决AOF文件大小不断增大的问题，原理如下：
Redis 提供了bgrewriteaof 日志重写指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。(注意这里也是读内存,没有管历史文件)
- 调用fork()，创建一个子进程
- 子进程把新的AOF写到一个
临时文件里，不依赖原来的AOF文件 - 主进程持续将新的变动同时写到内存和原来的AOF里
- 主进程会获取子进程重写AOF的完成信号，往新AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
- AOF恢复的过程像是把AOF日志文件里保存的命令重新执行一遍一样
重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式(相当于rdb)重写了一个新的AOF文件 重写过程分析,建议大家都看看,加强理解
触发AOF后台重写的条件
AOF重写可以由用户通过调用BgRewriteAOF手动触发。 服务器在AOF功能开启的情况下，会维持以下三个变量：
- 记录当前AOF文件大小的变量
aof_current_size。 - 记录最后一次AOF重写之后，AOF文件的大小
aof_rewrite_base_size。 - 增长百分比变量
aof_rewrite_perc。
每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：
- 没有BGSAVE命令（RDB持久化）/AOF持久化在执行；
- 没有BGREWRITEAOF在进行；
- 当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB）或者在redis.conf配置了auto-aof-rewrite-min-size大小；
- 当前AOF文件大小和最后一次重写后的大小之间的比率大于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）
如果前面三个条件都满足，并且当前AOF文件大小比最后一次AOF重写时的大小要大于指定的百分比，那么触发自动AOF重写。
当既有RDB文件又有AOF文件时候,Redis启动时候用哪个呢?
RDB和AOF的优缺点
- RDB优点：全量数据快照，文件小，恢复快
- RDB缺点：无法保存最近一次快照之后的数据
- AOF优点：本质上是命令的执行日志可读性高，适合保存增量数据，数据不易丢失
- AOF缺点：文件体积大，恢复时间长
