Redis RDB & AOF

17 October 2025   1303 words   ~3 mins
#Redis #持久化 #后端开发 #Concurrency

RDB

RDB是对 Redis 某一瞬间 保存的全量快照,本质上是一份二进制文件,用来在 Redis 重启或丢失数据后进行恢复,通常用作数据恢复、主从全量同步以及定期备份.

执行方式

1.手动

可以通过 `SAVE` 与 `BGSAVE` 手动执行 RDB 备份, `SAVE` 命令会在主线程内进行备份操作,此时Redis主线程会被堵塞直到写入 RDB 完成.
使用 `BGSAVE` 时 则是通过 `fork` 一个子线程进行写时复制写入硬盘,不会造成 Redis 主线程堵塞.

Copy-On-Write（写时复制） 是一种 优化内存使用和提升性能的系统级技术，广泛用于操作系统（如 Linux）、数据库、虚拟化等领域。

多个进程/线程共享同一份物理内存，只有当某个进程试图“修改”数据时，才真正复制一份私有副本。

  • 读操作：直接共享原始数据，无需复制；
  • 写操作：触发复制，之后修改的是副本，不影响原数据。

2. 自动(通过配置文件)

Redis 支持通过在 redis.conf 文件中配置 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。save 选项可以设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

【示例】redis.conf 中自动保存配置

# 900 秒内，至少对数据库进行了 1 次修改
save 900 1
# 300 秒内，至少对数据库进行了 10 次修改
save 300 10
# 60 秒内，至少对数据库进行了 10000 次修改
save 60 10000

只要满足以上任意条件，Redis 服务就会执行 BGSAVE 命令。

RDB 优缺点

优点

  1. 重启后加载快, 相比 AOF 命令执行式恢复, RDB本质就是压缩过的二进制文件,只需要将其全部读入内存即可.
  2. 相比 AOF RDB空间利用率更高.

缺点

  1. 备份频率较低,每次只能全量备份,如果在备份开始前发生故障,会导致丢失大量数据,无法满足强一致性.
  2. 备份时间长,如果数据量很大，保存快照的时间会很长.

AOF（Append Only File）

AOF 是 Redis 的另一种持久化机制，它通过记录服务器接收到的每一个写命令，以日志形式追加到文件末尾。在 Redis 重启时，通过重新执行 AOF 文件中的命令来恢复数据。AOF 文件是可读的文本格式，通常用于对数据安全性要求较高的场景。

执行方式

1. 手动

  • 开启 AOF：默认关闭，需在 redis.conf 中设置 appendonly yes。
  • 重写 AOF：执行 BGREWRITEAOF 命令，Redis 会 fork 一个子进程，根据当前数据库状态生成一个更紧凑的新 AOF 文件（利用 Copy-On-Write 机制，不阻塞主线程）。

2. 自动（通过配置文件）

AOF 的同步策略由 appendfsync 配置项控制，决定写命令何时从缓冲区刷入磁盘：

# 每次写操作都同步到磁盘（最安全，性能最差）
appendfsync always

# 每秒同步一次（默认推荐，平衡安全与性能）
appendfsync everysec

# 由操作系统决定何时同步（性能最好，但可能丢失较多数据）
appendfsync no

此外，AOF 重写也可自动触发，通过以下配置：

# 当 AOF 文件大小超过上一次重写后大小的指定百分比时，自动触发重写
auto-aof-rewrite-percentage 100
# AOF 文件至少达到指定大小（字节）才触发自动重写
auto-aof-rewrite-min-size 64mb

AOF 优缺点

优点

  1. 数据更安全：everysec 模式下最多丢失 1 秒数据，always 模式可做到几乎零丢失。
  2. 可读可编辑：AOF 是纯文本格式，若误操作（如误删 key），可手动修改文件删除对应命令后恢复。
  3. 自动压缩：通过重写机制，可将冗余命令（如多次 INCR）合并为一条 SET，减小文件体积。

缺点

  1. 文件体积大：相比 RDB，AOF 通常更大（尽管重写可优化）。
  2. 恢复速度慢：需逐条重放命令，大数据集下恢复时间远长于 RDB。
  3. 性能开销：尤其在 always 模式下，每次写操作都需同步磁盘，影响吞吐量。
← prev next →