AOF（Append Only File）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用解决了数据持久化的实时性。
1.使用AOF
开启AOF需要设置配置文件： appendonly yes,默认不开启。（设置完成之后，记得需要重启redis服务否则配置会不生效）AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）
2.AOF的工作流程
1. 所有的写⼊命令会追加到 aof_buf（缓冲区）中。
2. AOF 缓冲区根据对应的策略向硬盘做同步操作。
3. 随着 AOF ⽂件越来越⼤，需要定期对 AOF ⽂件进⾏重写，达到压缩的⽬的。
4. 当 Redis 服务器启动时，可以加载 AOF ⽂件进⾏数据恢复。
3.命令写入：
AOF 命令写⼊的内容直接是⽂本协议格式。例如 set hello world 这条命令，在 AOF 缓冲区会追加如下⽂本：
1 *3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
AOF 过程中为什么需要 aof_buf 这个缓冲区？Redis 使⽤单线程响应命令，如果每次写 AOF ⽂件都直接同步硬盘，性能从内存的读写变成 IO 读写，必然会下降。先写⼊缓冲区可以有效减少 IO 次数，同时，Redis 还可以提供多种缓冲区同步策略，让⽤⼾根据⾃⼰的需求做出合理的平衡。
4.文件同步
Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，不同值得含义如表所示
系统调⽤ write 和 fsync 说明：
• write 操作会触发延迟写（delayed write）机制。Linux 在内核提供⻚缓冲区⽤来提供硬盘 IO 性
能。write 操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区
⻚空间写满或达到特定时间周期。同步⽂件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• Fsync 针对单个⽂件操作，做强制硬盘同步，fsync 将阻塞直到数据写⼊到硬盘。
• 配置为 always 时，每次写⼊都要同步 AOF ⽂件，性能很差，在⼀般的 SATA 硬盘上，只能⽀持⼤约⼏百 TPS 写⼊。除⾮是⾮常重要的数据，否则不建议配置。
• 配置为 no 时，由于操作系统同步策略不可控，虽然提⾼了性能，但数据丢失⻛险⼤增，除⾮数据重要程度很低，⼀般不建议配置。
• 配置为 everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能。理论上最多丢失 1 秒的数据。
5.重写机制
随着命令不断写入AOF，文件会变得越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件体积。AOF文件重写是把redis进程内的数据转化为写命令同步到新的AOF文件。
重写后得AOF文件为什么会变小？
进程内已超时得数据不再写入文件
旧的AOF得无效命令，例如del、hdel、srem等重写后将会删除，只保留数据得最终版本
多条写操作合并成一条
较⼩的 AOF ⽂件⼀⽅⾯降低了硬盘空间占⽤，⼀⽅⾯可以提升启动 Redis 时数据恢复的速度。
AOF 重写过程可以⼿动触发和⾃动触发：
• ⼿动触发：调⽤ bgrewriteaof 命令。
• ⾃动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定⾃动触发时
机。
◦ auto-aof-rewrite-min-size：表⽰触发重写时 AOF 的最⼩⽂件⼤⼩，默认为 64MB。
◦ auto-aof-rewrite-percentage：代表当前 AOF 占⽤⼤⼩相⽐较上次重写时增加的⽐例。
a. 主进程 fork 之后，继续响应其他命令。所有修改操作写⼊ AOF 缓冲区并根据 appendfsync 策
略同步到硬盘，保证旧 AOF ⽂件机制正确。
b. ⼦进程只有 fork 之前的所有内存信息，⽗进程中需要将 fork 之后这段时间的修改操作写⼊
AOF 重写缓冲区中。
4. ⼦进程根据内存快照，将命令合并到新的 AOF ⽂件中。
5. ⼦进程完成重写
a. 新⽂件写⼊后，⼦进程发送信号给⽗进程。
b. ⽗进程把 AOF重写缓冲区内临时保存的命令追加到新 AOF ⽂件中。
c. ⽤新 AOF ⽂件替换⽼ AOF ⽂件。
5.启动时数据恢复
