【Redis】持久化——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 所⽰。

1. 所有的写⼊命令会追加到 aof_buf（缓冲区）中。
2. AOF 缓冲区根据对应的策略向硬盘做同步操作。
3. 随着 AOF ⽂件越来越⼤，需要定期对 AOF ⽂件进⾏重写，达到压缩的⽬的。
4. 当 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 介绍它的运⾏流程。

1. 执行 AOF 重写请求
   如果当前进程正在执行AOF重写, 请求不执行, 如果当前进程正在 bgsave 操作, 重写延迟到 bgsave 完成之后再执行.
2. 父进程执行fork 创建子进程
3. 重写
   1. 主进程 fork 之后, 继续相应其他命令. 所有修改操作写入 AOF 缓冲区并根据 appendfsync策略同步到硬盘, 确保AOF文件机制正确
   2. 子进程只有 fork 之前的所有内存信息, 父进程中需要将fork之后这段时间的修改操作写入AOF重写缓冲区中
4. 子进程根据内存快照, 将命令合并到新的 AOF 文件中
5. 子进程完成重写
   1. 新文件写入后, 子进程发送信息给父进程
   2. 父进程把 AOF 重写缓冲区内临时保存的命令追加到新AOF文件中.
   3. 用新 AOF 文件替换老 AOF文件

启动时数据恢复

当 Redis 启动时，会根据 RDB 和 AOF ⽂件的内容，进⾏数据恢复，如图 4-4 所⽰。

持久化小结

1. Redis 提供了两种持久化⽅案：RDB 和 AOF。
2. RDB 视为内存的快照，产⽣的内容更为紧凑，占⽤空间较⼩，恢复时速度更快。但产⽣ RDB 的开销较⼤，不适合进⾏实时持久化，⼀般⽤于冷备和主从复制。
3. AOF 视为对修改命令保存，在恢复时需要重放命令。并且有重写机制来定期压缩 AOF ⽂件。
4. RDB 和 AOF 都使⽤ fork 创建⼦进程，利⽤ Linux ⼦进程拥有⽗进程内存快照的特点进⾏持久化，尽可能不影响主进程继续处理后续命令。