4.3 RDB 和 AOF 的选择与混合使用

4.3 RDB 和 AOF 的选择与混合使用

Redis 持久化：RDB 与 AOF 的选择与混合使用详解

4.3 RDB 和 AOF 的选择与混合使用

在深入代码实践之前，我们先来回顾一下 RDB 和 AOF 的基本概念和特性，以便更好地理解它们的选择与混合使用策略。

4.3.1 RDB (Redis Database Backup)

概念: RDB 持久化是通过快照（snapshotting）的方式来保存 Redis 在某个时间点的数据到硬盘上的二进制文件。当 Redis 需要恢复数据时，可以直接加载 RDB 文件到内存中。

工作原理:

• Redis 会根据配置的策略（例如，每隔一段时间或当满足一定条件时）触发 RDB 快照操作。

• 触发快照操作后，Redis 主进程会 fork 出一个子进程。

• 子进程负责将内存中的数据写入到一个临时的 RDB 文件中。

• 当子进程完成 RDB 文件的写入后，会将临时文件替换旧的 RDB 文件，完成快照操作。

优点:

• 性能优势: RDB 快照是在子进程中完成的，主进程可以继续处理客户端请求，对 Redis 的性能影响较小，尤其是在数据量较大时，RDB 的性能优势更为明显。

• 恢复速度快: RDB 文件是二进制压缩文件，体积小，加载速度快，适用于快速恢复大数据集。

• 灾难恢复: RDB 文件是单一文件，易于备份和传输，非常适合用于灾难恢复。

缺点:

• 数据丢失风险: RDB 是定时快照，如果在两次快照之间 Redis 服务宕机，那么这段时间内的数据将会丢失。数据丢失的量取决于快照的频率。

• Fork 开销: 虽然快照操作由子进程完成，但 fork 子进程本身也需要一定的开销，尤其是在内存占用较大的情况下，fork 过程可能会阻塞主进程一段时间。

配置详解 (redis.conf):

# RDB 持久化配置
# save <seconds> <changes>
# 在 <seconds> 秒内，如果至少有 <changes> 个键被修改，则执行 BGSAVE
save 900 1       # 900 秒 (15 分钟) 内至少有 1 个 key 被修改则触发
save 300 10      # 300 秒 (5 分钟) 内至少有 10 个 key 被修改则触发
save 60 10000    # 60 秒 (1 分钟) 内至少有 10000 个 key 被修改则触发
stop-writes-on-bgsave-error yes  # 当 BGSAVE 发生错误时，停止写入操作 (保护数据一致性)
rdbcompression yes              # 存储 RDB 文件时是否压缩 (节省磁盘空间，但会增加 CPU 开销)
rdbchecksum yes                 # 存储 RDB 文件时是否校验和 (检测文件损坏)
dir ./                           # RDB 文件和 AOF 文件存储的目录
dbfilename dump.rdb                # RDB 文件名
​

代码实践 (redis-cli):

• 手动触发 RDB 快照:

  redis-cli bgsave
  ​

  这条命令会异步执行 RDB 快照操作，Redis 会返回 Background saving started 表示快照已开始。

• 同步执行 RDB 快照 (会阻塞 Redis 服务):

  redis-cli save
  ​

  这条命令会同步执行 RDB 快照操作，在快照完成之前，Redis 服务将阻塞，无法处理客户端请求。通常不建议在生产环境中使用 save 命令。

4.3.2 AOF (Append Only File)

概念: AOF 持久化是将 Redis 服务器执行的每个写命令（如 SET, HSET, SADD 等）追加到 AOF 文件的末尾。当 Redis 需要恢复数据时，会重新执行 AOF 文件中的命令来重建数据。

工作原理:

• 当 Redis 接收到写命令后，除了执行命令外，还会将该命令以 Redis 协议格式追加到 AOF 文件的末尾。

• Redis 会根据配置的 appendfsync 策略，决定何时将 AOF 文件内容同步到磁盘。

• AOF 文件会随着时间的推移不断增大，为了控制 AOF 文件的大小，Redis 提供了 AOF 重写机制。

优点:

• 数据安全性高: 根据 appendfsync 的配置，AOF 可以提供更高的数据安全性，即使在 Redis 服务宕机的情况下，也只会丢失少量数据，甚至可以做到零数据丢失（always 策略）。

• 可读性好: AOF 文件是文本文件，内容是 Redis 命令，可读性较好，方便人工检查和修复数据。

• 灵活的恢复策略: AOF 文件可以手动编辑，可以移除错误的命令，进行更灵活的数据恢复。

缺点:

• 性能开销: AOF 需要记录每个写命令，并且根据 appendfsync 策略同步到磁盘，相比 RDB，AOF 的性能开销更高，尤其是在高写入负载的情况下。

• 文件体积较大: AOF 文件会记录所有写命令，随着时间的推移，文件体积会变得很大，占用更多的磁盘空间。

• 恢复速度较慢: 恢复数据时需要重新执行 AOF 文件中的所有命令，如果 AOF 文件很大，恢复速度会比 RDB 慢。

配置详解 (redis.conf):

# AOF 持久化配置
appendonly no                     # 默认关闭 AOF 持久化，设置为 yes 开启 AOF
appendfilename "appendonly.aof"    # AOF 文件名
# appendfsync always              # 每次写入都同步到磁盘，数据安全性最高，性能最差
# appendfsync everysec              # 每秒同步一次到磁盘，数据安全性和性能的折中方案 (默认)
appendfsync no                    # 由操作系统决定何时同步，性能最好，数据安全性最差 (不推荐)
no-appendfsync-on-rewrite no      # 在 AOF 重写期间是否禁止 fsync 操作 (yes: 禁止，减少磁盘 I/O 压力，但可能丢失数据; no: 不禁止，数据更安全，但可能影响重写性能)
auto-aof-rewrite-percentage 100    # AOF 文件大小增长百分比达到该值时触发自动重写
auto-aof-rewrite-min-size 64mb    # AOF 文件最小大小达到该值时才触发自动重写
​

代码实践 (redis-cli):

• 开启 AOF 持久化 (修改 redis.conf 并重启 Redis 服务):

  修改 redis.conf 文件，将 appendonly no 改为 appendonly yes，然后重启 Redis 服务。

• 手动触发 AOF 重写:

  redis-cli bgrewriteaof
  ​

  这条命令会异步执行 AOF 重写操作，Redis 会返回 Background append only file rewriting started 表示重写已开始。AOF 重写会创建一个新的 AOF 文件，只包含重建当前数据集所需的最小命令集合，从而减小 AOF 文件的大小。

4.3.3 RDB 和 AOF 的选择

选择 RDB 还是 AOF，或者两者都使用，需要根据具体的应用场景和需求来权衡。

选择 RDB 的场景:

• 追求高性能: 如果对数据丢失不敏感，或者可以容忍一定程度的数据丢失，并且对 Redis 的性能要求非常高，可以选择 RDB 持久化。

• 大数据集快速恢复: 如果需要快速恢复大数据集，RDB 文件加载速度快，是更好的选择。

• 灾难备份: RDB 文件易于备份和传输，适合用于定期备份和灾难恢复。

选择 AOF 的场景:

• 追求高数据安全性: 如果对数据安全性要求非常高，不能容忍任何数据丢失（或者只能容忍极少量的数据丢失），应该选择 AOF 持久化，并配置 appendfsync always 或 appendfsync everysec。

• 审计和日志: AOF 文件记录了所有写命令，可以用于审计和日志分析。

• 灵活的数据恢复: AOF 文件可读性好，可以手动编辑，进行更灵活的数据恢复。

RDB vs AOF 对比总结:

4.3.4 RDB 和 AOF 的混合使用 (推荐)

在实际生产环境中，强烈推荐同时开启 RDB 和 AOF 持久化。这种混合使用的方式可以结合两者的优点，在数据安全性和性能之间取得最佳平衡。

混合使用的工作原理:

• 当 Redis 重启时，优先加载 AOF 文件 进行数据恢复，因为 AOF 文件通常包含更完整的数据。

• 如果 AOF 文件不存在或者损坏，Redis 会尝试加载 RDB 文件进行数据恢复。

混合使用的优点:

• 数据更安全: AOF 保证了较高的数据安全性，即使在意外宕机的情况下，也只会丢失最后几秒的数据（取决于 appendfsync everysec 配置）。

• 启动速度更快: RDB 文件加载速度快，可以加快 Redis 重启速度，尤其是在大数据集的情况下。

• 备份和恢复更灵活: 可以使用 RDB 文件进行快速备份和灾难恢复，同时使用 AOF 文件进行更精细的数据恢复和审计。

混合使用的配置 (redis.conf):

要开启 RDB 和 AOF 的混合使用，只需要在 redis.conf 文件中同时配置 RDB 和 AOF 相关的参数即可。

# 开启 RDB 持久化 (根据需求配置 save 策略)
save 900 1
save 300 10
save 60 10000
# 开启 AOF 持久化
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
​

代码实践 (redis-cli):

• 无需额外操作: 一旦在 redis.conf 文件中配置了 RDB 和 AOF，Redis 服务启动后会自动同时使用这两种持久化方式。用户无需在 redis-cli 中进行额外的操作。

最佳实践建议:

• 生产环境强烈建议同时开启 RDB 和 AOF 持久化。

• 根据数据安全性要求选择合适的 appendfsync 策略。 通常 appendfsync everysec 是一个不错的折中方案。

• 定期备份 RDB 文件，用于灾难恢复。

• 监控 AOF 文件大小，并根据实际情况调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数。

• 在 Redis 运行期间，尽量避免使用 save 命令，而使用 bgsave 命令进行 RDB 快照。

• 在 Redis 运行期间，尽量避免使用阻塞式的命令，例如 sync 和 flushall，这些命令可能会影响持久化性能。

• 定期检查 RDB 和 AOF 文件的完整性，确保持久化机制正常工作。

总结

RDB 和 AOF 是 Redis 提供的两种重要的持久化机制，它们各有优缺点，适用于不同的场景。RDB 性能好，恢复速度快，但可能丢失数据；AOF 数据安全性高，但性能开销较大。**最佳实践是在生产环境中同时开启 RDB 和 AOF 持久化，充分利用两者的优势，在数据安全性和性能之间取得平衡。