4.1 RDB (Redis Database)

文档摘要

4.1 RDB (Redis Database) Redis 持久化：RDB (Redis Database) 详解与实践 Redis 作为高性能的内存数据库，其数据存储在内存中以实现快速读写。然而，内存中的数据在服务器重启或宕机后会丢失。为了解决数据持久化问题，Redis 提供了两种主要的持久化机制：RDB (Redis Database) 和 AOF (Append Only File)。本文将深入探讨 RDB 持久化，包括其原理、配置、实践操作以及优缺点分析，帮助您全面理解和应用 RDB 持久化技术。 4.

4.1 RDB (Redis Database)

Redis 持久化：RDB (Redis Database) 详解与实践

Redis 作为高性能的内存数据库，其数据存储在内存中以实现快速读写。然而，内存中的数据在服务器重启或宕机后会丢失。为了解决数据持久化问题，Redis 提供了两种主要的持久化机制：RDB (Redis Database) 和 AOF (Append Only File)。本文将深入探讨 RDB 持久化，包括其原理、配置、实践操作以及优缺点分析，帮助您全面理解和应用 RDB 持久化技术。

4.1 RDB (Redis Database)

RDB 持久化是 Redis 默认采用的持久化方式，它通过**快照（snapshotting）**的方式将某一时刻的内存数据保存到磁盘上的一个二进制文件中，这个文件被称为 RDB 文件，通常命名为 dump.rdb。当 Redis 服务器重启时，可以重新加载 RDB 文件中的数据，从而实现数据恢复。

4.1.1 RDB 工作原理

RDB 的核心原理是 Redis 会定期或在特定事件触发时，将内存中的数据集快照写入到磁盘。这个过程通常由 SAVE 或 BGSAVE 命令触发。

SAVE 命令 (阻塞式)：SAVE 命令会同步地执行快照操作，即 Redis 主进程会阻塞，直到 RDB 文件创建完成。在 SAVE 执行期间，Redis 服务器将停止处理所有客户端请求。由于阻塞主进程，SAVE 命令在生产环境中应谨慎使用，尤其是在数据集较大时，阻塞时间会较长，影响 Redis 的性能。
BGSAVE 命令 (非阻塞式)：BGSAVE 命令是 Redis 推荐的快照方式。当执行 BGSAVE 命令时，Redis 主进程会 fork 一个子进程，由子进程负责将数据写入 RDB 文件。主进程仍然可以继续处理客户端请求，不会被阻塞。BGSAVE 的执行过程如下：
1. 主进程接收到 BGSAVE 命令。
2. 主进程 fork 出一个子进程。
3. 子进程负责遍历内存中的数据，并将数据写入到临时的 RDB 文件中 (例如 dump.rdb.tmp)。
4. 主进程继续处理客户端请求。
5. 当子进程完成 RDB 文件写入后，它会通知主进程。
6. 主进程将临时的 RDB 文件重命名为最终的 RDB 文件 (dump.rdb)，并替换旧的文件（如果存在）。

Copy-On-Write (COW) 机制： BGSAVE 命令之所以能够实现非阻塞，得益于操作系统的 Copy-On-Write (COW) 机制。当子进程 fork 时，子进程和父进程共享相同的内存空间。只有当父进程或子进程需要修改共享内存中的数据时，操作系统才会为修改的数据创建一份新的副本。对于 RDB 快照过程，子进程在生成快照期间只进行读操作，而主进程可能继续处理写操作。由于 COW 机制，只有主进程修改的数据页会被复制，子进程读取的仍然是 fork 时刻的内存数据快照，保证了快照的一致性。

4.1.2 RDB 的触发方式

RDB 快照的触发方式主要有两种：自动触发 和 手动触发。

1. 自动触发 (配置方式)

Redis 配置文件 redis.conf 中可以通过 save 指令配置 RDB 自动触发条件。可以配置多个 save 指令，每个指令定义了在指定时间内如果发生了至少指定次数的键值对修改操作，则自动触发 BGSAVE 命令。

save 指令的语法如下：


save <seconds> <changes>

<seconds>: 时间间隔，单位为秒。
<changes>: 在 <seconds> 时间内，至少发生了 <changes> 次键值对修改操作（例如 SET, DEL, INCR, LPUSH 等）。

示例配置：


save 900 1          # 900 秒 (15 分钟) 内，至少 1 个 key 被修改，则触发 BGSAVE
save 300 10         # 300 秒 (5 分钟) 内，至少 10 个 key 被修改，则触发 BGSAVE
save 60 10000       # 60 秒 (1 分钟) 内，至少 10000 个 key 被修改，则触发 BGSAVE

解释：

上述配置表示 Redis 会根据这三个条件，任何一个条件满足时都会自动执行 BGSAVE。
例如，如果 Redis 运行了 800 秒，期间只修改了 0 个 key，那么不会触发 RDB 快照。但是如果再过 100 秒，总共 900 秒，期间修改了 1 个 key，那么就会触发 RDB 快照。
又如，如果 Redis 运行了 200 秒，期间修改了 15 个 key，虽然满足了第二个条件（300秒内至少10个修改），但时间未到 300 秒，所以不会触发。必须等到 300 秒，且修改次数达到或超过 10 次才会触发。

禁用 RDB 自动触发：

如果想完全禁用 RDB 自动触发，可以将所有 save 指令注释掉或者清空。


# save 900 1
# save 300 10
# save 60 10000

或者


save ""

2. 手动触发 (命令方式)

可以通过 Redis 客户端手动执行 SAVE 或 BGSAVE 命令来触发 RDB 快照。

SAVE 命令：
```
redis-cli save
```
执行 SAVE 命令会立即开始同步执行 RDB 快照，Redis 主进程会阻塞，直到快照完成。
BGSAVE 命令：
```
redis-cli bgsave
```
执行 BGSAVE 命令会异步执行 RDB 快照，Redis 主进程不会阻塞，可以继续处理客户端请求。

实际应用建议：

在生产环境中，强烈建议使用 BGSAVE 命令进行 RDB 快照，并结合 redis.conf 中的 save 指令进行自动触发配置。避免使用 SAVE 命令，除非在非常特殊的情况下，例如需要立即备份且可以接受短暂的服务不可用。

4.1.3 RDB 相关配置选项

除了 save 指令，redis.conf 文件中还有其他一些与 RDB 持久化相关的配置选项，可以进一步控制 RDB 的行为。

stop-writes-on-bgsave-error <yes|no>
- 默认值： yes
- 作用： 当 BGSAVE 过程中发生错误时（例如磁盘空间不足、IO 错误等），是否停止 Redis 的写操作。
- yes: 当 BGSAVE 出错时，Redis 会停止接受新的写操作，只允许读操作。这可以防止在持久化失败的情况下继续写入数据，导致数据丢失或不一致。
- no: 当 BGSAVE 出错时，Redis 会继续接受写操作。这可能会导致部分数据没有被持久化，但可以保证 Redis 服务的持续可用性。
- 建议： 在生产环境中，强烈建议设置为 yes，以确保数据安全性。如果 BGSAVE 出错，应该优先解决错误，而不是冒着数据丢失的风险继续运行。
rdbcompression <yes|no>
- 默认值： yes
- 作用： 是否对 RDB 文件进行压缩。
- yes: 使用 LZF 算法对 RDB 文件进行压缩，可以减小 RDB 文件的大小，节省磁盘空间，并加快 RDB 文件的传输速度（例如主从复制）。但压缩和解压缩会消耗 CPU 资源。
- no: 不对 RDB 文件进行压缩。RDB 文件会更大，但可以节省 CPU 资源。
- 建议： 默认开启压缩 (yes) 通常是合理的选择。在大多数情况下，磁盘空间比 CPU 资源更宝贵。如果 Redis 服务器 CPU 负载非常高，并且 RDB 文件生成速度成为瓶颈，可以考虑关闭压缩 (no)。
rdbchecksum <yes|no>
- 默认值： yes
- 作用： 是否在 RDB 文件中添加 CRC64 校验和。
- yes: 在 RDB 文件的末尾添加 CRC64 校验和。在加载 RDB 文件时，Redis 会校验校验和，以检测 RDB 文件是否损坏。如果校验失败，Redis 会拒绝加载 RDB 文件，防止加载损坏的数据。
- no: 不在 RDB 文件中添加校验和。加载 RDB 文件时不会进行校验。
- 建议： 强烈建议开启校验和 (yes)，以提高数据可靠性。虽然校验和计算会增加少量开销，但可以有效防止加载损坏的 RDB 文件，避免数据错误。
dir <directory>
- 默认值： 通常为 Redis 启动目录或配置文件所在目录。
- 作用： 指定 RDB 文件和 AOF 文件（如果启用）的存储目录。
- 建议： 建议配置一个专门用于存储持久化文件的目录，方便管理和备份。确保该目录具有足够的磁盘空间和写入权限。
dbfilename <filename>
- 默认值： dump.rdb
- 作用： 指定 RDB 文件的文件名。
- 建议： 可以使用默认文件名 dump.rdb，或者根据需要自定义文件名。如果在一台服务器上运行多个 Redis 实例，建议使用不同的文件名来区分不同实例的 RDB 文件。

配置示例：


save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dir /var/lib/redis/data
dbfilename dump.rdb

4.1.4 RDB 文件结构 (简要概述)

RDB 文件是 Redis 数据在磁盘上的二进制表示形式。其文件结构主要包含以下几个部分（更详细的结构涉及 Redis 内部实现，此处仅作简要概述）：

REDIS 魔数 (Magic Number) 和版本号: 文件开头几个字节是固定的 "REDIS" 字符串和一个版本号，用于标识 RDB 文件类型和版本。
数据库选择: RDB 文件可以包含多个数据库的数据。文件中会标识当前数据属于哪个数据库 (DB 0, DB 1, etc.)。
键值对数据: 这是 RDB 文件的核心部分，存储了 Redis 数据库中的所有键值对数据。数据以特定的编码格式进行序列化，包括数据类型 (String, List, Set, Hash, ZSet 等)、键名、值等信息。
EOF (End Of File) 标识: 文件末尾通常会有一个 EOF 标识，表示文件结束。
校验和 (Checksum, 可选): 如果 rdbchecksum 配置为 yes，则 RDB 文件末尾还会包含一个 CRC64 校验和，用于数据完整性校验。

注意： RDB 文件格式是 Redis 内部实现细节，通常不需要直接解析或操作 RDB 文件。Redis 服务器会负责 RDB 文件的生成和加载。

4.1.5 RDB 的优势与劣势

RDB 的优势：

紧凑的文件大小： RDB 文件是二进制压缩文件，文件体积相对较小，更利于备份和传输。
快速的恢复速度： 由于 RDB 文件是某一时刻的快照，加载 RDB 文件恢复数据时，速度比 AOF 快得多。特别是在数据集非常大的情况下，RDB 的恢复优势更加明显。
性能影响较小： BGSAVE 操作通过子进程进行，主进程几乎不受影响，只在 fork 子进程时会有短暂的停顿。
适用于灾难恢复： RDB 非常适合用于定期备份，以应对灾难性故障导致的数据丢失。

RDB 的劣势：

数据丢失风险： RDB 是定时快照，如果在两次快照之间 Redis 服务器发生故障，那么从上次快照到故障时刻之间的数据将会丢失。数据丢失的量取决于 save 指令的配置频率。如果 save 指令配置频率较低，数据丢失风险会增大。
实时性不高： RDB 不是实时持久化，无法做到数据的实时备份。
fork 开销： BGSAVE 操作需要 fork 子进程，fork 过程在数据集非常大的情况下，可能会比较耗时，并且会占用一定的内存空间（虽然有 COW 机制，但父子进程仍然需要共享页表等资源）。

4.1.6 RDB 代码实践 (配置与操作)

以下是一些 RDB 相关的代码实践示例，包括配置和常用操作。

1. 修改 redis.conf 配置文件：

打开 Redis 配置文件 redis.conf (通常位于 /etc/redis/redis.conf 或 Redis 安装目录下)，找到 RDB 相关的配置项，根据需要进行修改。

示例配置 (已在 4.1.3 节中给出)：


save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dir /var/lib/redis/data
dbfilename dump.rdb

修改完成后，需要重启 Redis 服务器使配置生效。

2. 使用 redis-cli 手动触发 RDB 快照：

执行 BGSAVE 命令 (推荐):
```
redis-cli bgsave
```
执行后，Redis 服务器会返回 "Background saving started" 表示 BGSAVE 任务已启动。可以使用 INFO persistence 命令查看 BGSAVE 的状态。
执行 SAVE 命令 (不推荐生产环境使用):
```
redis-cli save
```
执行后，redis-cli 会阻塞，直到 RDB 快照完成。期间 Redis 服务器也会阻塞，无法处理其他请求。

3. 查看 RDB 快照状态：

使用 INFO persistence 命令可以查看 RDB 快照的执行状态和相关信息。


redis-cli info persistence

输出信息中会包含以下 RDB 相关字段：


# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0      # 是否正在执行 BGSAVE，1 表示正在执行，0 表示未执行
rdb_last_save_time:1678886400  # 上次成功执行 RDB 快照的时间戳
rdb_last_bgsave_status:ok     # 上次 BGSAVE 的状态，ok 表示成功，error 表示失败
rdb_last_bgsave_time_sec:-1   # 上次 BGSAVE 耗时 (秒)
rdb_current_bgsave_time_sec:-1 # 当前 BGSAVE 已耗时 (秒)，如果 rdb_bgsave_in_progress 为 1，则显示耗时
rdb_last_cow_size:0           # 上次 BGSAVE 的 COW (Copy-On-Write) 内存消耗
rdb_current_cow_size:0          # 当前 BGSAVE 的 COW 内存消耗

通过这些信息，可以监控 RDB 快照的执行情况，例如是否正在执行、上次快照是否成功、耗时等。

4. 模拟 RDB 数据恢复：

停止 Redis 服务器:
```
redis-cli shutdown
```
删除或清空 Redis 数据目录下的 RDB 文件 dump.rdb (可选，模拟数据丢失):
```
rm /var/lib/redis/data/dump.rdb  # 假设 RDB 文件目录为 /var/lib/redis/data
```
启动 Redis 服务器:
```
redis-server /path/to/redis.conf  # 使用配置文件启动 Redis
```
Redis 服务器启动时，会自动检查数据目录下是否存在 dump.rdb 文件。如果存在，则会加载 RDB 文件中的数据进行恢复。如果删除了 dump.rdb 文件，则 Redis 启动后将是空数据库。

5. 编写脚本自动化 RDB 备份 (示例 Bash 脚本):

可以编写脚本定期执行 BGSAVE 命令，并将 RDB 文件备份到其他位置，例如远程服务器或云存储。


#!/bin/bash
# Redis 客户端路径
REDIS_CLI="/usr/local/bin/redis-cli"
# RDB 文件目录 (根据实际配置修改)
RDB_DIR="/var/lib/redis/data"
RDB_FILE="dump.rdb"
BACKUP_DIR="/mnt/backup/redis/rdb"
# 当前日期作为备份目录
DATE=$(date +%Y%m%d)
BACKUP_DATE_DIR="${BACKUP_DIR}/${DATE}"
# 创建备份日期目录
mkdir -p "${BACKUP_DATE_DIR}"
# 执行 BGSAVE 命令
echo "执行 BGSAVE..."
"${REDIS_CLI}" bgsave
# 等待 BGSAVE 完成 (可选，可以根据需要添加等待机制，例如轮询 INFO persistence)
sleep 5
# 检查 BGSAVE 状态
BGSAVE_STATUS=$("${REDIS_CLI}" info persistence | grep rdb_last_bgsave_status | awk -F':' '{print $2}')
if [ "${BGSAVE_STATUS}" == "ok" ]; then
  echo "BGSAVE 成功"
  # 复制 RDB 文件到备份目录
  cp "${RDB_DIR}/${RDB_FILE}" "${BACKUP_DATE_DIR}/${RDB_FILE}.${DATE}.bak"
  echo "RDB 文件备份到 ${BACKUP_DATE_DIR}"
else
  echo "BGSAVE 失败，请检查 Redis 日志"
fi
echo "备份完成"

可以将此脚本添加到 crontab 定时任务中，例如每天凌晨执行一次。

6. 使用 Python 脚本触发 RDB 备份 (示例 Python 脚本，需要安装 redis-py 库):


import redis
import datetime
import os
# Redis 连接信息
REDIS_HOST = "localhost"
REDIS_PORT = 6379
REDIS_PASSWORD = None  # 如果有密码，请设置密码
# RDB 文件目录 (根据实际配置修改)
RDB_DIR = "/var/lib/redis/data"
RDB_FILE = "dump.rdb"
BACKUP_DIR = "/mnt/backup/redis/rdb"
# 连接 Redis
try:
    r = redis.Redis(host=REDIS_HOST, port=REDIS_PORT, password=REDIS_PASSWORD)
    r.ping() # 检查连接是否成功
except redis.exceptions.ConnectionError as e:
    print(f"Redis 连接失败: {e}")
    exit(1)
# 当前日期作为备份目录
date_str = datetime.datetime.now().strftime("%Y%m%d")
backup_date_dir = os.path.join(BACKUP_DIR, date_str)
# 创建备份日期目录
os.makedirs(backup_date_dir, exist_ok=True)
# 执行 BGSAVE 命令
print("执行 BGSAVE...")
try:
    r.bgsave()
except redis.exceptions.ResponseError as e:
    print(f"BGSAVE 执行失败: {e}")
    exit(1)
# 等待 BGSAVE 完成 (可选，可以根据需要添加等待机制，例如轮询 INFO persistence)
import time
time.sleep(5)
# 检查 BGSAVE 状态
info = r.info('persistence')
bgsave_status = info.get('rdb_last_bgsave_status')
if bgsave_status == 'ok':
    print("BGSAVE 成功")
    # 复制 RDB 文件到备份目录
    rdb_src_path = os.path.join(RDB_DIR, RDB_FILE)
    rdb_dst_path = os.path.join(backup_date_dir, f"{RDB_FILE}.{date_str}.bak")
    import shutil
    shutil.copy2(rdb_src_path, rdb_dst_path) # copy2 保留元数据
    print(f"RDB 文件备份到 {backup_date_dir}")
else:
    print("BGSAVE 失败，请检查 Redis 日志")
print("备份完成")

同样可以将此 Python 脚本添加到定时任务中。

4.1.7 RDB 最佳实践

合理配置 save 指令： 根据业务数据的重要性、数据更新频率和可接受的数据丢失量，合理配置 save 指令。重要数据可以设置更频繁的快照间隔，但也会增加 RDB 生成的频率和资源消耗。
监控 BGSAVE 状态： 定期使用 INFO persistence 命令监控 BGSAVE 的执行状态，确保 RDB 快照能够正常生成。
定期备份 RDB 文件： 编写脚本自动化备份 RDB 文件到安全可靠的位置，例如远程服务器、云存储或磁带库。
考虑 RDB 和 AOF 的组合使用： RDB 和 AOF 可以结合使用，充分发挥各自的优势。例如，可以使用 RDB 进行定期备份和快速恢复，同时启用 AOF 记录每次写操作，以最大限度地减少数据丢失。
注意 fork 开销： 在数据集非常大的情况下，BGSAVE 的 fork 操作可能会比较耗时，并可能导致短暂的 Redis 性能抖动。可以监控 Redis 的 fork 耗时，并根据情况调整 save 指令的频率。
测试 RDB 恢复： 定期进行 RDB 数据恢复测试，验证 RDB 文件的有效性和恢复流程的正确性，确保在需要时能够快速可靠地恢复数据。

4.1.8 RDB 总结

RDB 持久化是 Redis 重要的数据持久化机制，它以快照的方式将内存数据保存到磁盘，具有文件体积小、恢复速度快等优点，适用于备份和灾难恢复。但 RDB 也存在数据丢失风险和 fork 开销等缺点。在实际应用中，需要根据业务需求和数据重要性，合理配置 RDB，并结合其他持久化方式（如 AOF）和备份策略，以确保数据的安全性和可靠性。