Redis持久化之AOF

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.启动时数据恢复