AOF
- 使⽤ AOF
- 命令写⼊
- ⽂件同步
- 重写机制
- 启动时数据恢复
- 持久化小结
AOF（Append Only File）持久化：以独⽴⽇志的⽅式记录每次写命令，重启时再重新执⾏ AOF⽂件中的命令达到恢复数据的⽬的。AOF 的主要作⽤是解决了数据持久化的实时性，⽬前已经是Redis 持久化的主流⽅式。理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能⾮常有帮助。
使⽤ AOF
开启 AOF 功能需要设置配置：appendonly yes，默认不开启。AOF ⽂件名通过appendfilename 配置（默认是 appendonly.aof）设置。保存⽬录同 RDB 持久化⽅式⼀致，通过 dir配置指定。AOF 的⼯作流程操作：命令写⼊（append）、⽂件同步（sync）、⽂件重写（rewrite）、重启加载（load），如图 4-2 所⽰。
- 所有的写⼊命令会追加到 aof_buf（缓冲区）中。
- AOF 缓冲区根据对应的策略向硬盘做同步操作。
- 随着 AOF ⽂件越来越⼤，需要定期对 AOF ⽂件进⾏重写，达到压缩的⽬的。
- 当 Redis 服务器启动时，可以加载 AOF ⽂件进⾏数据恢复。
命令写⼊
AOF 命令写⼊的内容直接是⽂本协议格式。例如 set hello world 这条命令，在 AOF 缓冲区会追加如下⽂本：
此处遵守 Redis 格式协议，Redis 选择⽂本协议可能的原因：⽂本协议具备较好的兼容性；实现简单；具备可读性。
AOF 过程中为什么需要 aof_buf 这个缓冲区？Redis 使⽤单线程响应命令，如果每次写 AOF ⽂件都直接同步硬盘，性能从内存的读写变成 IO 读写，必然会下降。先写⼊缓冲区可以有效减少 IO 次数，同时，Redis 还可以提供多种缓冲区同步策略，让⽤⼾根据⾃⼰的需求做出合理的平衡。
⽂件同步
Redis 提供了多种 AOF 缓冲区同步⽂件策略，由参数 appendfsync 控制，不同值的含义如表 4-1 所⽰。
系统调⽤ write 和 fsync 说明：
- write 操作会触发延迟写（delayed write）机制。Linux 在内核提供⻚缓冲区⽤来提供硬盘 IO 性能。write 操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区⻚空间写满或达到特定时间周期。同步⽂件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
- Fsync 针对单个⽂件操作，做强制硬盘同步，fsync 将阻塞直到数据写⼊到硬盘。
- 配置为 always 时，每次写⼊都要同步 AOF ⽂件，性能很差，在⼀般的 SATA 硬盘上，只能⽀持⼤约⼏百 TPS 写⼊。除⾮是⾮常重要的数据，否则不建议配置。
- 配置为 no 时，由于操作系统同步策略不可控，虽然提⾼了性能，但数据丢失⻛险⼤增，除⾮数据重要程度很低，⼀般不建议配置。
- 配置为 everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能。理论上最多丢失 1 秒的数据。
重写机制
随着命令不断写⼊ AOF，⽂件会越来越⼤，为了解决这个问题，Redis 引⼊ AOF 重写机制压缩⽂件体积。AOF ⽂件重写是把 Redis 进程内的数据转化为写命令同步到新的 AOF ⽂件。
重写后的 AOF 为什么可以变⼩？有如下原因：
- 进程内已超时的数据不再写⼊⽂件。
- 旧的 AOF 中的⽆效命令，例如 del、hdel、srem 等重写后将会删除，只需要保留数据的最终版本。
- 多条写操作合并为⼀条，例如 lpush list a、lpush list b、lpush list 从可以合并为 lpush list a b c。
较⼩的 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 占⽤⼤⼩相⽐较上次重写时增加的⽐例。
当触发 AOF 重写时，图 4-3 介绍它的运⾏流程。
- 执行 AOF 重写请求
如果当前进程正在执行AOF重写, 请求不执行, 如果当前进程正在 bgsave 操作, 重写延迟到 bgsave 完成之后再执行. - 父进程执行fork 创建子进程
- 重写
- 主进程 fork 之后, 继续相应其他命令. 所有修改操作写入 AOF 缓冲区并根据 appendfsync策略同步到硬盘, 确保AOF文件机制正确
- 子进程只有 fork 之前的所有内存信息, 父进程中需要将fork之后这段时间的修改操作写入AOF重写缓冲区中
- 子进程根据内存快照, 将命令合并到新的 AOF 文件中
- 子进程完成重写
- 新文件写入后, 子进程发送信息给父进程
- 父进程把 AOF 重写缓冲区内临时保存的命令追加到新AOF文件中.
- 用新 AOF 文件替换老 AOF文件
启动时数据恢复
当 Redis 启动时，会根据 RDB 和 AOF ⽂件的内容，进⾏数据恢复，如图 4-4 所⽰。
持久化小结
- Redis 提供了两种持久化⽅案：RDB 和 AOF。
- RDB 视为内存的快照，产⽣的内容更为紧凑，占⽤空间较⼩，恢复时速度更快。但产⽣ RDB 的开销较⼤，不适合进⾏实时持久化，⼀般⽤于冷备和主从复制。
- AOF 视为对修改命令保存，在恢复时需要重放命令。并且有重写机制来定期压缩 AOF ⽂件。
- RDB 和 AOF 都使⽤ fork 创建⼦进程，利⽤ Linux ⼦进程拥有⽗进程内存快照的特点进⾏持久化，尽可能不影响主进程继续处理后续命令。
