Redis

本文集文档发布于灏天文库

4.2 AOF (Append Only File)

文档摘要

4.2 AOF (Append Only File) Redis 持久化之 AOF (Append Only File) 详解与代码实践 4.2 AOF (Append Only File) 持久化详解 AOF (Append Only File) 持久化，顾名思义，是以追加写入的方式记录 Redis 服务器接收到的每一条写命令（包括 , , , 等），并将这些命令以 Redis 协议格式 (RESP) 追加到 AOF 文件的末尾。当 Redis 服务器重启时，它会重新执行 AOF 文件中记录的所有写命令，以此来恢复数据库的状态。

4.2 AOF (Append Only File)

Redis 持久化之 AOF (Append Only File) 详解与代码实践

4.2 AOF (Append Only File) 持久化详解

AOF (Append Only File) 持久化，顾名思义，是以追加写入的方式记录 Redis 服务器接收到的每一条写命令（包括 SET, HSET, SADD, DEL 等），并将这些命令以 Redis 协议格式 (RESP) 追加到 AOF 文件的末尾。当 Redis 服务器重启时，它会重新执行 AOF 文件中记录的所有写命令，以此来恢复数据库的状态。

与 RDB 持久化定期生成数据集快照的方式不同，AOF 持久化提供了更强的持久性保证，因为它可以配置为在每次写命令执行后立即将命令写入磁盘，最大限度地减少数据丢失的风险。

4.2.1 AOF 的优势与劣势

优势：

  • 更高的数据安全性: AOF 可以配置为每秒或每次写命令都进行 fsync 操作，将数据写入磁盘，因此在系统崩溃时，数据丢失的风险更低，尤其是在 appendfsync always 模式下，理论上只会在最后一次 fsync 前的操作系统缓冲区中丢失数据。

  • 可读性高: AOF 文件内容是 Redis 命令的文本格式，易于理解和分析。这使得 AOF 文件在进行数据恢复、调试甚至数据迁移时更加方便。

  • 易于修复: 由于 AOF 文件是命令追加的方式，即使 AOF 文件在写入过程中损坏（例如，服务器突然断电导致写入不完整），Redis 仍然可以利用 redis-check-aof 工具进行修复，尽可能地恢复数据。

  • 灵活的 fsync 策略: AOF 提供了多种 fsync 策略，允许用户根据自身需求在数据安全性和性能之间进行权衡。

劣势：

  • 文件体积通常大于 RDB: 由于 AOF 记录的是每一条写命令，随着时间的推移，AOF 文件通常会比 RDB 快照文件更大。尤其是在写入操作频繁的场景下，AOF 文件增长速度更快。

  • 恢复速度通常慢于 RDB: Redis 服务器在启动时，需要重新执行 AOF 文件中的所有命令来恢复数据，这通常比加载 RDB 快照文件需要更长的时间，尤其是在 AOF 文件非常大的情况下。

  • 在某些极端情况下，性能可能略低于 RDB: 虽然现代操作系统和磁盘的性能已经很高，但在某些高并发、写密集型的场景下，频繁的 fsync 操作可能会对 Redis 的写入性能产生一定的影响，尤其是在 appendfsync always 模式下。

AOF 与 RDB 的选择：

在实际应用中，AOF 和 RDB 并非互斥的关系，它们可以同时启用，共同为数据安全提供保障。如果同时启用了 AOF 和 RDB，Redis 启动时会优先使用 AOF 文件进行数据恢复，因为 AOF 通常包含更完整的数据。

一般来说：

  • 追求更高的数据安全性，可以优先选择 AOF，并采用 appendfsync always 或 appendfsync everysec 策略。

  • 追求更快的恢复速度，可以优先选择 RDB。

  • 为了兼顾数据安全性和恢复速度，可以同时启用 AOF 和 RDB，并根据实际业务场景选择合适的 fsync 策略。

4.2.2 AOF 的配置详解与代码实践

AOF 的配置主要在 Redis 的配置文件 redis.conf 中进行。以下是 AOF 相关的关键配置项及其详解：

  1. appendonly <yes|no>:

    • 作用: 启用或禁用 AOF 持久化。

    • 默认值: no (默认禁用 AOF)。

    • 代码实践:

      # 启用 AOF 持久化
appendonly yes
# 禁用 AOF 持久化 (默认)
# appendonly no
​

    • 说明: 要启用 AOF 持久化，必须将 appendonly 设置为 yes。

  2. appendfilename "appendonly.aof":

    • 作用: 指定 AOF 文件的名称。

    • 默认值: "appendonly.aof"

    • 代码实践:

      # 使用默认 AOF 文件名
appendfilename "appendonly.aof"
# 自定义 AOF 文件名
# appendfilename "my_redis_data.aof"
​

    • 说明: 可以自定义 AOF 文件的名称，但通常使用默认值即可。AOF 文件默认存储在 Redis 服务器的工作目录中。

  3. appendfsync <always|everysec|no>:

    • 作用: 配置 AOF 文件同步 (fsync) 策略，决定何时将 AOF 缓冲区的数据写入磁盘。

    • 默认值: everysec

    • 可选值:

      • always: 每次有新的写命令追加到 AOF 文件后，立即执行 fsync 操作，将数据写入磁盘。数据安全性最高，但性能开销最大，写入速度最慢。

      • everysec: 每秒执行一次 fsync 操作。将多个写命令累积到 AOF 缓冲区，然后每秒统一写入磁盘。数据安全性较高，性能开销适中，是推荐的平衡方案。即使系统崩溃，最多丢失 1 秒的数据。

      • no: 不强制执行 fsync 操作，而是由操作系统决定何时将 AOF 缓冲区的数据写入磁盘。数据安全性最低，性能开销最小，写入速度最快。但数据丢失风险最高，系统崩溃时可能丢失较多数据。

    • 代码实践:

      # 每次写命令都 fsync (数据安全最高，性能最低)
appendfsync always
# 每秒 fsync (推荐的平衡方案)
appendfsync everysec
# 不强制 fsync，由操作系统决定 (数据安全最低，性能最高)
# appendfsync no
​

    • 说明: appendfsync 是 AOF 持久化最重要的配置项之一，直接影响数据安全性和性能。根据业务对数据安全性的要求选择合适的策略。生产环境中强烈建议使用 everysec 或 always。

  4. no-appendfsync-on-rewrite <yes|no>:

    • 作用: 配置在 AOF 重写期间是否禁用 fsync 操作。

    • 默认值: no

    • 可选值:

      • yes: 在 AOF 重写期间，禁用 fsync 操作。目的是减少磁盘 I/O 压力，提高重写效率。但可能会降低数据安全性，因为在重写期间如果系统崩溃，可能会丢失更多数据。

      • no: 在 AOF 重写期间，不禁用 fsync 操作。保持正常的 fsync 策略，确保数据安全性。但可能会影响重写效率，增加重写所需的时间。

    • 代码实践:

      # AOF 重写期间禁用 fsync (可能降低数据安全，提高重写效率)
no-appendfsync-on-rewrite yes
# AOF 重写期间不禁用 fsync (保证数据安全，可能降低重写效率)
# no-appendfsync-on-rewrite no
​

    • 说明: AOF 重写是一个 I/O 密集型操作。为了减少重写对性能的影响，可以考虑在重写期间禁用 fsync。但需要权衡数据安全性和重写效率。通常建议使用默认值 no，保证数据安全性。

  5. AOF 重写相关的配置:

    • auto-aof-rewrite-percentage <percentage>:

      • 作用: 设置 AOF 文件大小增长百分比，触发自动 AOF 重写。

      • 默认值: 100 (当 AOF 文件大小比上次重写后的大小增长 100% 时，触发重写)

      • 代码实践:

        # AOF 文件大小增长 100% 时触发重写
auto-aof-rewrite-percentage 100
# AOF 文件大小增长 50% 时触发重写 (更频繁的重写)
# auto-aof-rewrite-percentage 50
​

      • 说明: 当 AOF 文件大小增长到一定程度时，需要进行重写，减小文件体积。auto-aof-rewrite-percentage 控制增长百分比的阈值。设置为 0 则禁用自动重写。

    • auto-aof-rewrite-min-size <size>:

      • 作用: 设置触发自动 AOF 重写的最小 AOF 文件大小。

      • 默认值: 64mb (当 AOF 文件大小至少达到 64MB 时，才会考虑触发重写)

      • 代码实践:

        # AOF 文件大小至少 64MB 时才触发重写
auto-aof-rewrite-min-size 64mb
# AOF 文件大小至少 32MB 时才触发重写 (更早触发重写)
# auto-aof-rewrite-min-size 32mb
​

      • 说明: 即使 AOF 文件大小增长百分比达到阈值，如果文件大小还未达到 auto-aof-rewrite-min-size，也不会触发重写。这个配置项是为了避免在 AOF 文件很小时频繁进行重写，浪费资源。

    • 代码实践示例：启用 AOF 并配置 everysec fsync 策略和自动重写

      appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
​

代码实践：通过 redis-cli 查看 AOF 配置信息

连接到 Redis 服务器后，可以使用 INFO persistence 命令查看 AOF 持久化的相关信息：

redis-cli
127.0.0.1:6379> INFO persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1678886400
rdb_last_bgsave_status:ok
rdb_children_active:0
rdb_last_cow_size:0
aof_enabled:1  # aof_enabled:1 表示 AOF 已启用
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_children_active:0
aof_last_cow_size:0
aof_current_size:345
aof_base_size:345
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0
​

在 INFO persistence 的输出中，可以关注以下关键字段：

  • aof_enabled: 1 表示 AOF 已启用，0 表示未启用。

  • appendonly: 显示配置的 appendonly 值 (yes 或 no)。

  • appendfsync: 显示配置的 appendfsync 值 (always, everysec, no)。

  • aof_current_size: 当前 AOF 文件的大小 (字节)。

  • aof_base_size: 上次 AOF 重写后 AOF 文件的大小 (字节)。

  • aof_rewrite_in_progress: 1 表示正在进行 AOF 重写，0 表示未进行。

4.2.3 AOF 的工作流程详解

  1. 命令追加 (Append): 当 Redis 服务器接收到客户端的写命令时 (例如 SET key value)，首先会执行该命令，更新内存数据库。然后，将该命令以 Redis 协议格式 (RESP) 追加到 AOF 缓冲区 (append buffer) 中。

  2. 文件同步 (fsync): 根据配置的 appendfsync 策略，Redis 会将 AOF 缓冲区的数据同步到磁盘上的 AOF 文件中。

    • always: 每次写命令后立即 fsync。

    • everysec: 每秒 fsync 一次。

    • no: 由操作系统决定何时 fsync。

  3. AOF 重写 (Rewrite): 随着时间的推移，AOF 文件会越来越大，其中包含了很多冗余的命令 (例如，多次修改同一个 key，最终只需要保留最后一次修改的命令)。为了减小 AOF 文件体积，Redis 提供了 AOF 重写机制。

    • 手动重写: 可以通过 BGREWRITEAOF 命令手动触发 AOF 重写。

    • 自动重写: 根据 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 配置，当 AOF 文件大小满足条件时，Redis 会自动触发重写。

    AOF 重写的过程：

    • Redis 会创建一个子进程 (fork)，由子进程负责进行 AOF 重写，主进程继续处理客户端请求，不会被阻塞。

    • 子进程会扫描内存数据库，将数据库的当前状态转换为一系列 Redis 命令 (例如，如果 key mykey 的值为 myvalue，则会生成 SET mykey myvalue 命令)。

    • 子进程将生成的命令写入到一个新的临时 AOF 文件中 (例如 appendonly.aof.rewrite.pid)。

    • 在重写期间，主进程接收到的新的写命令仍然会追加到旧的 AOF 文件和重写缓冲区 (rewrite buffer) 中，确保数据不丢失。

    • 当子进程完成重写后，会将重写缓冲区中的数据也追加到新的 AOF 文件中，保证新 AOF 文件包含最新的数据。

    • Redis 会原子性地替换旧的 AOF 文件为新的 AOF 文件，完成重写。

    • 重写完成后，新的写命令将继续追加到新的 AOF 文件中。

  4. 数据恢复 (Recovery): 当 Redis 服务器重启时，如果启用了 AOF 持久化，Redis 会执行以下步骤进行数据恢复：

    • 读取 AOF 文件: Redis 会读取 AOF 文件中的所有命令。

    • 命令重放 (Replay): Redis 会顺序执行 AOF 文件中记录的所有写命令，重建内存数据库的状态。

    • 完成恢复: 当 AOF 文件中的所有命令执行完毕后，Redis 数据库就恢复到了重启前的状态。

代码实践：手动触发 AOF 重写

可以使用 BGREWRITEAOF 命令手动触发 AOF 重写：

redis-cli
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
​

执行 BGREWRITEAOF 后，Redis 会在后台启动 AOF 重写进程。可以使用 INFO persistence 命令查看 aof_rewrite_in_progress 字段来确认重写是否正在进行。

4.2.4 AOF 的数据安全性和一致性

AOF 持久化通过记录每一条写命令，并提供不同的 fsync 策略，来保证数据安全性和一致性。

  • 数据安全性: appendfsync always 策略提供了最高的数据安全性，理论上只会在最后一次 fsync 前的操作系统缓冲区中丢失数据。appendfsync everysec 策略在数据安全性和性能之间取得了较好的平衡，即使系统崩溃，最多丢失 1 秒的数据。

  • 数据一致性: AOF 文件中记录的是 Redis 命令，Redis 在启动时通过顺序执行这些命令来恢复数据，保证了数据的一致性。即使 AOF 文件在写入过程中损坏，Redis 也能通过 redis-check-aof 工具进行修复，最大程度地恢复数据。

AOF 文件损坏修复：redis-check-aof 工具

如果 AOF 文件在写入过程中损坏 (例如，服务器断电)，可以使用 redis-check-aof 工具进行检查和修复。

redis-check-aof --fix appendonly.aof
​

redis-check-aof --fix 命令会尝试修复 AOF 文件中的错误，并生成一个新的 AOF 文件 appendonly.aof.fix。修复后的 AOF 文件可能丢失部分数据，但可以保证 Redis 服务器能够正常启动并加载数据。

4.2.5 AOF 的最佳实践

  • 选择合适的 appendfsync 策略: 生产环境中强烈建议使用 appendfsync everysec 或 appendfsync always 策略，以确保数据安全。根据业务对数据安全性和性能的要求进行权衡。

  • 定期监控 AOF 文件大小: 监控 AOF 文件的大小增长情况，合理配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，确保及时进行 AOF 重写，减小文件体积。

  • 定期备份 AOF 文件: 定期备份 AOF 文件，例如每天备份一次，以防止 AOF 文件损坏或丢失导致的数据丢失。

  • 结合 RDB 使用: 可以同时启用 AOF 和 RDB 持久化，RDB 可以作为一种额外的备份手段，在某些情况下可以提供更快的恢复速度。

  • 了解 no-appendfsync-on-rewrite 的影响: 默认情况下，no-appendfsync-on-rewrite 设置为 no，保证数据安全性。如果需要提高 AOF 重写效率，可以设置为 yes，但需要权衡数据安全性。

总结

AOF (Append Only File) 持久化是 Redis 提供的一种重要的数据持久化机制。它通过追加写入写命令的方式记录数据变更，提供了比 RDB 更高的数据安全性。合理配置 AOF 的相关参数，选择合适的 fsync 策略，并结合 AOF 重写机制，可以有效地保障 Redis 数据的安全性和可靠性。在实际应用中，应根据业务场景和数据安全要求，选择合适的持久化方案，甚至可以同时启用 AOF 和 RDB，构建更完善的数据保障体系。理解 AOF 的工作原理和配置，并进行充分的代码实践，能够帮助我们更好地利用 Redis 的持久化功能，构建更健壮的应用系统。

发布者: 作者: 转发
评论区 (0)
U
0/500