Redis RDB & AOF

Fri, 17 Oct 2025 00:00:00 +0000

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 优缺点

优点

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

缺点

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

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 优缺点

优点

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

缺点

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

持久化 on pipo's site

Redis RDB & AOF

RDB

执行方式

1.手动

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

RDB 优缺点

优点

缺点

AOF（Append Only File）

执行方式

1. 手动

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

AOF 优缺点

优点

缺点