当前位置：首页 > news >正文

Redis 持久化机制详解：RDB 与 AOF 原理与实践

news 2025/9/22 7:08:15

Redis 持久化机制详解：RDB 与 AOF 原理与实践

Redis 作为一款高性能的内存键值数据库，广泛应用于缓存、会话存储、消息队列等场景。然而，由于其数据主要存储在内存中，一旦服务器宕机或重启，数据就会丢失。为了解决这个问题，Redis 提供了两种主要的持久化机制：RDB（Redis Database） 和 AOF（Append Only File）。本文将深入解析这两种机制的原理、优缺点以及配置建议，帮助你更好地在生产环境中使用 Redis。

一、为什么需要持久化？

Redis 将数据存储在内存中，读写速度极快，但这也带来了数据易失性的问题。持久化机制的核心目标是：在系统重启或崩溃后，能够恢复之前的数据状态。通过将内存中的数据写入磁盘，Redis 实现了数据的持久保存。

二、RDB 持久化（快照模式）

1. 基本原理

RDB 是 Redis 默认的持久化方式。它通过生成数据集的时间点快照（point-in-time snapshot），将某一时刻的所有数据保存到一个二进制文件中，文件名为 dump.rdb。

RDB 的触发方式主要有两种：

手动触发：通过 SAVE 或 BGSAVE 命令。
- SAVE：阻塞主线程，直到 RDB 文件创建完成。不推荐在生产环境使用。
- BGSAVE：由子进程执行快照操作，主线程继续处理请求，是推荐方式。

自动触发：通过配置文件中的 save 指令，例如：

save 900 1      # 900秒内至少有1个键被修改
save 300 10     # 300秒内至少有10个键被修改
save 60 10000   # 60秒内至少有10000个键被修改

2. 优点

文件紧凑：RDB 文件是二进制格式，体积小，适合备份和灾难恢复。
恢复速度快：重启时加载 RDB 文件比 AOF 更快。
性能影响小：BGSAVE 由子进程完成，对主线程影响较小。

3. 缺点

可能丢失数据：RDB 是定时快照，若在两次快照之间发生宕机，这段时间的数据将丢失。
大实例耗时长：当数据量非常大时，BGSAVE 可能会耗费较长时间，影响性能。

三、AOF 持久化（追加日志模式）

1. 基本原理

AOF 持久化通过记录每一个写操作命令，以文本格式追加到日志文件 appendonly.aof 中。当 Redis 重启时，通过重新执行 AOF 文件中的命令来恢复数据。

AOF 的写入策略由 appendfsync 配置项控制：

策略	说明	数据安全性	性能
`always`	每个写命令都同步到磁盘	最高	最低
`everysec`	每秒同步一次（默认）	较高	推荐
`no`	由操作系统决定同步时机	低	高

2. AOF 重写（AOF Rewrite）

随着写操作增多，AOF 文件会不断膨胀。Redis 提供了 AOF 重写机制，通过创建一个更小的 AOF 文件来替换原文件。重写过程不会读取旧的 AOF 文件，而是读取当前数据库状态，生成精简的写命令。

触发方式：

手动：BGREWRITEAOF

自动：通过配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

3. 优点

数据安全性高：最多丢失 1 秒的数据（使用 everysec 策略）。
可读性强：AOF 文件是文本格式，便于排查问题和手动修复。

4. 缺点

文件体积大：相比 RDB，AOF 文件通常更大。
恢复速度慢：重放大量命令耗时较长。
I/O 压力：频繁的磁盘写入可能影响性能。

四、RDB 与 AOF 对比

特性	RDB	AOF
持久化方式	快照	日志追加
文件大小	小	大
恢复速度	快	慢
数据安全性	低（可能丢失几分钟数据）	高（最多丢失1秒）
性能影响	小（BGSAVE）	中等（取决于 fsync 策略）
适用场景	备份、灾难恢复	数据安全性要求高的场景

五、混合持久化（Redis 4.0+）

为兼顾 RDB 的快速恢复和 AOF 的高数据安全性，Redis 4.0 引入了 混合持久化 机制。

启用方式：

aof-use-rdb-preamble yes

工作原理：

开启后，AOF 文件的前半部分是 RDB 格式的数据快照。
后半部分是增量的 AOF 日志。

混合持久化主要在 AOF 重写（AOF Rewrite）或 BGREWRITEAOF 执行时被触发。以下是其底层执行流程：

步骤 1：触发 AOF 重写

当满足以下任一条件时，Redis 会自动触发 AOF 重写：
- AOF 文件大小超过 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 阈值
- 手动执行 BGREWRITEAOF 命令
此时，Redis 会 fork 一个子进程来执行重写。

步骤 2：子进程开始重写（关键区别）

在 未开启混合持久化 时，子进程会读取当前数据库中的每个键值对，转换为 SET、HSET 等原始命令，写入新的 AOF 文件。

而在 开启混合持久化 后，子进程的行为完全不同：
1. 调用 RDB 的快照生成逻辑
  子进程调用 rdbSaveRio() 函数（与 BGSAVE 使用的底层函数相同），将当前数据库的完整数据状态以 RDB 二进制格式 写入到新的 AOF 临时文件中。
  
  这部分就是所谓的 “RDB preamble（RDB 前导）”
2. 切换为 AOF 增量追加模式
  RDB 数据写入完成后，子进程并不会结束，而是继续工作：
  - 记录从 fork 之后到重写完成之间，主进程产生的新写命令（这些命令会被写入一个缓冲区 aof_rewrite_buf）。
  - 将这些增量命令以 AOF 文本格式 追加到同一个 AOF 文件的末尾。