【征服redis8】Redis的AOF持久化

Redis 支持多种持久化方式来保证数据的可靠性和持久性。前面我们介绍了RDB方式。我们我们介绍第二种方式——AOF（Append Only File）机制是一种常用的持久化方式，它记录了所有对 Redis 数据库进行修改的命令，在 Redis 重启时可以使用这些命令来重构数据库状态。

1.AOF的基本原理

1.1 如何启动AOF

1.2 AOF 文件的创建

1.3. AOF 文件的写入

1.4. AOF 文件的重写

1.5. AOF 文件的恢复

1.6. 小结

2. RDB和AOF混合方式

3 .AOF 持久化实践

1.AOF的基本原理

1.1 如何启动AOF

在 Redis 的配置文件中，可以通过以下配置项来设置 AOF 持久化相关的参数：

1. appendonly：设置是否开启 AOF 持久化，默认为 no（关闭状态）。

2. appendfilename：设置 AOF 文件名，默认为 appendonly.aof。

3. appendfsync：设置 AOF 文件同步策略，有以下三种可选值：

- always：每次写入都会同步到磁盘，最安全但性能最差；
- everysec：每秒同步一次到磁盘，安全性和性能的折中方案；
- no：由操作系统决定何时同步，最不安全但性能最好。

4. auto-aof-rewrite-percentage：设置 AOF 重写触发的条件之一，即 AOF 文件大小增长率达到该值时触发 AOF 重写，默认为 100。

5. auto-aof-rewrite-min-size：设置 AOF 重写触发的条件之一，即 AOF 文件大小达到该值时触发 AOF 重写，默认为 64MB。

6. aof-load-truncated：设置当 Redis 以 AOF 模式启动时，是否自动修复截断的 AOF 文件，默认为 yes。

7. aof-use-rdb-preamble：设置是否在 AOF 文件中使用 RDB 文件的前缀，默认为 yes。

修改 Redis 配置文件后，需要重启 Redis 才能使配置生效。同时，对于 AOF文件同步策略的选择，需要根据实际情况进行权衡和选择。如果对数据的安全性要求非常高，可以选择 always
策略；如果对性能的要求比较高，可以选择 everysec 策略。

1.2 AOF 文件的创建

当启用 AOF 持久化机制时，Redis 会在启动时创建一个 AOF 文件，用于记录所有写命令。AOF 文件的默认文件名为 appendonly.aof，可以通过配置文件中的 appendfilename 参数进行修改。如果 AOF 文件已经存在，则 Redis 会在启动时读取文件中的内容，并将其加载到内存中。

1.3. AOF 文件的写入

当 Redis 执行写命令时，会将命令追加到 AOF 文件的末尾。如果 AOF 文件不存在，则 Redis 会自动创建一个新的 AOF 文件。如果 AOF 文件已经存在，则 Redis 会将命令追加到文件的末尾。

Redis 为了提高写入性能，通常会将多个命令缓存到内存中，然后在满足一定条件时批量写入到 AOF 文件中。具体来说，Redis 会维护一个 AOF 缓冲区，将每个写命令追加到缓冲区的末尾。当缓冲区的大小超过一定阈值时，或者缓冲区中的命令已经等待了一定时间后，Redis 会将缓冲区中的命令批量写入到 AOF 文件中。

1.3. AOF 文件的同步
为了保证写命令的可靠性和持久性，Redis 会在写入 AOF 文件后进行同步操作，将数据从内存中刷到磁盘中。这就是我通常所说的刷盘操作。刷盘操作可以分为两种方式：

同步磁盘上的所有数据，每次写入 AOF 文件时，Redis 会调用 fsync 系统调用将数据从内存刷到磁盘中。这种方式可以保证数据的可靠性，但是会带来较大的性能损耗。
定期同步磁盘上的数据，Redis 也可以通过配置文件中的 appendfsync 参数来控制 AOF 文件的同步方式。其中，有三种常用的方式：

always：每次写入 AOF 文件时都进行同步操作，可以保证数据的可靠性，但是会带来较大的性能损耗。
everysec：每秒钟对 AOF 文件进行一次同步操作，可以在一定程度上平衡数据安全和性能需求。
no：不进行同步操作，只在 Redis 进程退出时进行一次同步操作，可以提高性能，但是会带来一定的数据风险。

这三种方式的对比，我们可以通过下面的表来判断：

总结来说，就是：

如果要高性能，就选择 No 策略；
如果要高可靠，就选择 Always 策略；
如果允许数据丢失一点，但又想性能高，就选择 Everysec策略。

1.4. AOF 文件的重写

Redis AOF 文件在长时间运行后可能会变得非常大，不仅占用磁盘空间，还会影响 Redis 的性能。为了解决这个问题，Redis 提供了 AOF 文件重写机制，可以将 AOF 文件中的写命令进行压缩，生成一条等效的命令序列，从而减少 AOF 文件的大小。

AOF 文件重写机制的实现原理如下：

（1）Redis 会启动一个新的子进程，用于执行 AOF 文件重写操作。

（2）Redis 主进程会将所有写命令发送到子进程中，子进程会执行这些命令，并生成一条等效的命令序列。

（3）子进程会将等效命令序列写入到一个新的 AOF 文件中，同时在写入过程中进行同步操作，保证数据的可靠性。

（4）当子进程完成 AOF 文件的重写操作后，Redis 主进程会将新的 AOF 文件重命名为原来的 AOF 文件，并删除旧的 AOF 文件。

需要注意的是，AOF 文件重写操作只会对已经执行过的写命令进行压缩，新的写命令仍然会被追加到 AOF 文件的末尾。Redis 会周期性地检查 AOF 文件的大小，并在满足一定条件时触发 AOF 文件重写操作。

1.5. AOF 文件的恢复

AOF 的数据恢复过程设计很巧妙，它模拟一个 Redis 的服务过程。Redis 首先虚拟一个客户端，读取 AOF 文件恢复 Redis 命令和参数；接着过程就和服务客户端一样执行命令相应的函数，从而恢复数据，这样做的目的无非是提高代码的复用率。这些过程主要在 loadAppendOnlyFile() 中实现。我们可以理解为假的重放。

真实的过程当 Redis 重启时，会根据 AOF 文件中记录的命令重构数据库状态。具体来说，Redis 会按照 AOF 文件中记录的命令顺序，逐个执行命令，并在执行过程中重建数据库状态。需要注意的是，AOF 文件的恢复过程可能会比较耗时，因此需要在 Redis 配置文件中设置 AOF 文件的恢复方式，可以选择同步方式（always、everysec）或异步方式（no）。

所以，Redis AOF 持久化机制，其实说白了就是redis启动的时候创建一个server.aof_buf的文件，通过一个文件，实现了将写命令追加到 AOF 文件中，并在需要时同步到磁盘中，从而保证了数据的可靠性和持久性。当异常宕机需要恢复数据的时候又通过读取文件，回放之前的命令，进行数据还原。
由此大家也可以推断出它存在的弊端。

1.6. 小结

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。

在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

到此我们学完了 Redis 的持久化方式 RDB 和AOF 。那么我们对比一下。整理出如下表格：

	RDB	AOF
启动优先级	低	高
体积	比 AOF 小	比 RDB 大
恢复速度	比 AOF 快	比 RDB 慢
数据安全性	在定时备份时可能会丢失一定量的数据	根据同步策略决定，相对更安全
数据一致性	RDB 持久化的数据可能不是最新的，但数据一致性较高	AOF 持久化的数据较新，但数据一致性较低
运维复杂度	相对简单，只需要定期备份 RDB 文件即可	相对复杂，需要配置 AOF 缓冲区大小、同步策略等参数
写入性能	相对较高，因为 RDB 只需要生成一次快照文件即可完成持久化操作	相对较低，因为 AOF 需要将每一次写操作都写入到 AOF 文件中
读取性能	相对较高，因为 RDB 文件读取速度快	相对较低，因为需要将 AOF 文件中的所有写操作都执行一遍才能恢复
文件格式	二进制格式，比较紧凑	文本格式，可读性好
恢复方式	通过加载 RDB 文件来恢复数据库	通过加载 AOF 文件并执行其中的写操作来恢复数据库
文件重写方式	通过 BGSAVE 命令生成新的 RDB 文件来实现文件重写	通过执行 BGREWRITEAOF 命令来生成新的 AOF 文件实现文件重写