NoSQL数据库Redis（二）：Redis持久化详解

Redis持久化详解

1. 持久化的必要性

Redis 是一个基于内存的键值数据库，其高性能很大程度上得益于将所有数据存储在内存中。然而，内存的易失性也带来了风险：如果服务器意外宕机、进程崩溃或断电，内存中的数据将会丢失。持久化机制就是为了解决这个问题而设计的，它通过将内存中的数据以某种形式写入磁盘，从而在服务器重启后能够重新加载这些数据，恢复服务状态。

2. 主要的持久化方式

Redis 提供了两种主要的持久化策略：

RDB (Redis Database): 在指定的时间间隔内，将内存中的数据集快照（Snapshot）写入磁盘。生成的 RDB 文件是一个经过压缩的二进制文件。
AOF (Append Only File) : 记录服务器收到的每一个写操作命令（如 SET, LPUSH, SADD 等），并在服务器启动时通过重新执行这些命令来重建数据状态。AOF 文件是一个纯文本文件（虽然可以通过配置进行重写以压缩体积）。

3. RDB 持久化详解

3.1 RDB 的工作原理

RDB 的核心是创建数据的快照。当满足预设的触发条件时（例如，达到指定的时间间隔且有指定数量的键被修改），Redis 会 fork 出一个子进程。这个子进程负责将当前内存中的所有数据写入到一个临时的 RDB 文件中。写入完成后，这个临时文件会替换旧的 RDB 文件（如果有的话）。

关键点：

Fork 子进程: 主进程继续处理客户端请求。子进程拥有父进程内存数据的副本（得益于操作系统的 Copy-On-Write 机制），因此可以安全地写入快照，不会阻塞主进程。
二进制格式: RDB 文件是紧凑的二进制格式，通常比内存中的数据占用更少的空间。
触发条件: 可配置，例如每 N 秒如果至少有 M 个键被修改。

3.2 RDB 的优点

高性能: 由于 RDB 文件是数据的紧凑快照，且写入过程由子进程完成，对主进程性能影响相对较小。恢复大数据集时速度也很快。
文件紧凑: RDB 文件是压缩的二进制文件，占用磁盘空间较小。
适合备份: 单个文件的形式非常适合定时备份（例如，每天备份一次 RDB 文件到其他服务器或云存储）。
最大程度减少数据丢失: 在配置得当的情况下（例如，每 5 分钟保存一次），最多只会丢失最近 5 分钟的数据。

3.3 RDB 的缺点

数据丢失风险: 如果 Redis 在两次快照之间意外停止，那么最后一次快照之后的所有数据修改将会丢失。快照周期越长，丢失数据的风险越大。
Fork 潜在阻塞: 虽然 fork 通常很快，但当数据集非常大（例如几十 GB）时，fork 操作本身可能会消耗较多 CPU 时间，并在短时间内导致主进程阻塞（取决于系统性能和配置）。内存占用也会暂时翻倍（父进程内存 + 子进程内存副本）。
版本兼容性: 不同 Redis 大版本生成的 RDB 文件格式可能不完全兼容。

3.4 RDB 持久化配置 (OpenEuler)

RDB 的配置主要在 Redis 的配置文件 redis.conf 中（通常位于 /etc/redis/redis.conf 或 /usr/local/etc/redis.conf）。以下是关键配置项：

启用/禁用 RDB : 默认是启用的。如果设置了 save "" 或者将所有 save 指令注释掉，则禁用 RDB 快照。

触发条件 : 使用 save <seconds> <changes> 指令配置。可以有多个 save 指令。例如：

conf 复制代码

save 900 1  # 900秒（15分钟）内至少有1个键被修改，则触发bgsave
save 300 10 # 300秒（5分钟）内至少有10个键被修改，则触发bgsave
save 60 10000 # 60秒内至少有10000个键被修改，则触发bgsave

RDB 文件名 : 由 dbfilename 指令设置，默认是 dump.rdb。
conf 复制代码
```
dbfilename dump.rdb
```
RDB 文件存储目录 : 由 dir 指令设置。这个目录也用于 AOF 文件（如果启用）和工作目录。在 OpenEuler 上，确保此目录存在且 Redis 进程有读写权限。
conf 复制代码
```
dir /var/lib/redis
```
压缩 : 默认启用压缩。由 rdbcompression 指令控制。
conf 复制代码
```
rdbcompression yes
```
校验和 : 默认在 RDB 文件末尾存储 CRC64 校验和。由 rdbchecksum 指令控制。加载时会校验，有助于发现损坏的文件。
conf 复制代码
```
rdbchecksum yes
```

3.5 手动触发 RDB

除了自动触发，也可以通过命令手动创建 RDB 快照：

SAVE: 在主进程中执行快照保存，会阻塞所有客户端请求。生产环境不推荐使用。
BGSAVE: 后台异步执行快照保存（fork 子进程）。主进程继续响应请求。这是推荐的方式。
bash 复制代码
```
redis-cli BGSAVE
```
可以查看 LASTSAVE 命令获取上次成功保存的时间戳。

4. AOF 持久化详解

4.1 AOF 的工作原理

AOF 的核心是记录写操作日志。当 AOF 持久化开启时：

记录命令: 每一个会修改数据集的 Redis 命令，在执行后都会被追加到 AOF 缓冲区的末尾。
写入磁盘 : 根据配置的 appendfsync 策略，Redis 会以不同的频率将 AOF 缓冲区的内容写入（write）到操作系统的文件缓冲区。
同步到磁盘 : 操作系统通常会将文件缓冲区的数据暂存一段时间再写入物理磁盘。根据 appendfsync 策略，Redis 会调用 fsync 或 fdatasync 系统调用，强制将文件缓冲区的数据刷到物理磁盘上，确保数据持久化。
文件重写 (Rewrite) : 随着时间推移，AOF 文件会不断增大（例如，对一个计数器键执行 100 次 INCR，会产生 100 条记录）。为了解决文件膨胀问题，Redis 可以在后台（fork 子进程）创建新的 AOF 文件。这个新文件包含了重建当前数据集所需的最少命令集合（例如，用一条 SET counter 100 代替 100 条 INCR counter）。

4.2 AOF 的优点

更高的数据持久性 : 根据 appendfsync 策略的配置，可以将数据丢失的风险降到最低（例如 appendfsync always 几乎不丢失数据，但性能最低）。
文件可读性: AOF 文件是一个纯文本文件（命令日志），便于人工理解和解析（尽管通常不需要）。
重写机制: AOF 重写过程是安全的，由后台子进程完成，不会阻塞主进程。重写后的文件更小。
容错性 : 如果 AOF 文件在追加过程中因某种原因（如磁盘满）只写入了一半命令，可以使用 redis-check-aof 工具进行修复，尝试恢复尽可能多的数据。

4.3 AOF 的缺点

文件体积: 通常 AOF 文件会比同数据集的 RDB 文件大很多（即使重写后）。虽然重写可以压缩，但初始记录的是命令。
性能影响 : 根据 appendfsync 策略的不同，AOF 可能比 RDB 慢。always 策略会严重降低性能（每个命令都要同步磁盘），everysec 策略通常性能尚可，但理论上可能丢失最后一秒的数据。no 策略依赖操作系统刷新，不可控。
恢复速度: 恢复大数据集时，需要逐条执行 AOF 文件中的命令，速度通常比加载 RDB 文件慢。
历史兼容性: 随着 Redis 版本演进，新命令可能被添加。在罕见情况下，使用旧版本 Redis 加载包含新命令的 AOF 文件可能出错（但通常 Redis 会忽略无法识别的命令）。

4.4 AOF 持久化配置 (OpenEuler)

AOF 的配置也在 redis.conf 文件中。

启用/禁用 AOF : 默认是禁用的。设置 appendonly yes 启用 AOF。
conf 复制代码
```
appendonly yes
```
AOF 文件名 : 由 appendfilename 指令设置，默认是 appendonly.aof。
conf 复制代码
```
appendfilename "appendonly.aof"
```
AOF 文件存储目录 : 与 RDB 共享 dir 指令设置的目录。
fsync 策略 : 这是 AOF 的核心配置，由 appendfsync 指令控制。它决定了 AOF 缓冲区内容写入磁盘的时机和方式。
- always: 每个写命令都立即写入 AOF 文件并调用 fsync 同步到磁盘。数据最安全，性能最差（可能导致 Redis 每秒只能处理几百个请求）。
- everysec: 默认策略 。每秒执行一次 fsync。将缓冲区内容写入文件，并调用 fsync。性能相对较好（通常接近 RDB），最多丢失 1 秒的数据（实际丢失窗口通常小于 1 秒）。
- no: 将缓冲区内容写入文件，但不主动调用 fsync。何时将数据同步到磁盘由操作系统决定（通常是 30 秒左右）。性能最好，但数据丢失风险最高（操作系统崩溃可能导致丢失更多数据）。
conf 复制代码
```
appendfsync everysec # 推荐配置
```
AOF 重写触发条件 : 自动重写由两个参数控制：
- auto-aof-rewrite-percentage <percent>: 当前 AOF 文件大小相对于上次重写后大小的增长百分比阈值（例如 100 表示增长一倍）。
- auto-aof-rewrite-min-size <size>: 允许重写的最小 AOF 文件大小（例如 64mb），避免文件很小时频繁重写。
conf 复制代码
```
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
```
AOF 重写期间的文件同步 : 由 no-appendfsync-on-rewrite 控制。如果设置为 yes，在后台进行 AOF 重写时，主进程对 AOF 文件的 fsync 操作会被推迟。这可以减少重写时的磁盘 I/O 压力，但可能增加重写期间数据丢失的风险（如果重写期间服务器崩溃）。如果设置为 no（默认），则主进程的 fsync 照常进行，可能造成阻塞。
conf 复制代码
```
no-appendfsync-on-rewrite no # 保守选择，保证安全
```

4.5 手动触发 AOF 重写

可以使用 BGREWRITEAOF 命令手动触发 AOF 重写过程。

bash 复制代码

redis-cli BGREWRITEAOF

5. RDB 与 AOF 的区别与选择

5.1 主要区别

特性	RDB (快照)	AOF (日志)
持久化方式	定时数据快照	记录每次写操作命令
文件格式	压缩二进制	文本 (可重写压缩)
数据安全性	可能丢失最后一次快照后的数据	根据 `appendfsync` 策略，可接近零丢失
恢复速度	通常较快 (加载二进制快照)	通常较慢 (逐条执行命令)
文件大小	通常较小 (压缩二进制)	通常较大 (记录命令，重写后可减小)
性能影响	对主进程影响较小 (子进程写)	根据 `appendfsync` 策略，可能影响较大
可读性	差 (二进制)	好 (文本命令)

5.2 如何选择？

选择哪种持久化方式（或组合）取决于应用的需求：

追求最佳性能，能容忍少量数据丢失 : 只使用 RDB，并配置合理的快照频率（例如 save 300 10）。适合缓存等场景。
要求数据高可靠，几乎不能丢失 : 只使用 AOF，并将 appendfsync 设置为 always。注意这会显著降低性能。或者使用 everysec，接受最多 1 秒的数据丢失。
平衡性能和数据安全 (推荐) : 同时启用 RDB 和 AOF (appendonly yes + 配置 save)。这是 Redis 官方推荐的配置。这样你可以获得 RDB 的快速备份和恢复优势，同时获得 AOF 更高的数据安全性。在 Redis 4.0 及以上版本，重启时默认优先加载 AOF 文件（因为 AOF 通常数据更完整）。在 Redis 7.0 及以上版本，还可以考虑使用新的 appendonly yes + aof-use-rdb-preamble yes（默认）配置，这会在 AOF 重写时在文件开头写入 RDB 格式的全量数据，后面再追加增量命令（混合持久化），结合了两者的优点（加载更快，文件相对更小）。
完全不关心数据丢失 : 可以关闭持久化 (appendonly no + save "")。仅适用于纯缓存且数据可重建的场景。

6. 混合持久化 (Redis 4.0+)

从 Redis 4.0 开始，AOF 重写机制得到了增强。在重写时，Redis 可以创建一个新的 AOF 文件，该文件在开头是 RDB 格式的完整数据集快照，后面追加的是从快照点开始到重写完成期间接收到的写命令（AOF 格式）。这种混合格式结合了 RDB 和 AOF 的优点：

加载更快: 因为前半部分是 RDB，加载速度比纯 AOF 快。
文件更小: 相比纯 AOF，文件通常更小。
数据安全: 保留了 AOF 的增量记录特性。

在 Redis 7.0 中，这是默认行为（aof-use-rdb-preamble yes）。生成的 AOF 文件扩展名仍然是 .aof，但文件内容格式发生了变化。在配置上，只需启用 AOF (appendonly yes) 即可使用混合持久化。

7. 数据恢复流程

当 Redis 服务器启动时，它会按照以下顺序尝试加载持久化数据来恢复状态：

AOF 文件存在: 优先加载 AOF 文件（执行其中的命令重建数据）。
AOF 文件不存在，但 RDB 文件存在: 加载 RDB 文件（加载快照）。
两者都不存在: 启动一个空数据集。

8. 持久化相关的运维命令

INFO PERSISTENCE: 查看持久化相关的详细统计信息，包括最后一次 RDB/AOF 重写的时间、状态、大小等。
CONFIG GET dir/dbfilename/appendonly/appendfsync/...: 动态获取持久化相关的配置参数。
CONFIG SET appendonly yes/no: 运行时动态 开启或关闭 AOF 持久化（立即生效，但不会修改 redis.conf 文件）。
BGSAVE: 手动触发后台 RDB 快照。
BGREWRITEAOF: 手动触发后台 AOF 重写。
LASTSAVE: 获取上次成功执行 SAVE 或 BGSAVE 的时间戳。

9. 性能调优与注意事项

磁盘 I/O: 无论是 RDB 的 fork 写盘还是 AOF 的 fsync，都会产生磁盘 I/O。确保磁盘性能足够好（SSD 推荐），避免 Redis 和磁盘 I/O 密集型应用部署在同一服务器。
内存: RDB 的 fork 操作可能导致内存使用量短暂翻倍。确保系统有足够的空闲内存。
监控 : 监控持久化相关的指标（INFO PERSISTENCE），关注 aof_delayed_fsync (延迟的 fsync 次数)、aof_rewrite_in_progress (是否正在重写)、rdb_bgsave_in_progress (是否正在 bgsave)、rdb_last_save_time 等。
备份: 定期备份 RDB 和 AOF 文件到安全的异地位置。RDB 文件非常适合冷备份。
OpenEuler 文件系统 : 确保 dir 配置的目录位于性能良好的文件系统上（如 XFS, ext4），并具有足够的空间。检查文件系统挂载参数（如 noatime）。
权限 : 确保 Redis 进程用户（如 redis）对 dir 目录有读写权限。
测试恢复: 定期在测试环境验证备份文件的恢复流程是否有效。

10. 总结

Redis 的持久化机制（RDB 和 AOF）是保证数据可靠性的基石。在 OpenEuler 系统上部署 Redis 服务时，必须根据业务需求（数据重要性、性能要求）仔细选择和配置持久化策略。理解 RDB 的快照原理、AOF 的日志记录和重写机制，以及它们各自的优缺点和适用场景，是进行有效配置的关键。对于大多数生产环境，推荐同时启用 RDB 和 AOF，并利用 Redis 4.0+ 的混合持久化特性来获得性能和安全性之间的最佳平衡。持续的监控、调优和备份也是运维工作中不可或缺的部分。通过合理的配置和管理，Redis 可以在 OpenEuler 上提供高性能且可靠的数据存储服务。