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

redis数据结构-11（了解 Redis 持久性选项：RDB 和 AOF）

news 来源：原创 2025/6/21 17:52:45

了解 Redis 持久性选项：RDB 和 AOF

Redis 提供了多个持久性选项，以确保数据持久性并防止在服务器发生故障或重启时丢失数据。了解这些选项对于为您的特定使用案例选择正确的策略、平衡性能和数据安全至关重要。本章节将深入探讨 Redis 中的两种主要持久性机制：Redis 数据库（RDB）快照和仅附加文件（AOF）。我们将探讨它们的工作原理、优点和缺点以及如何配置它们。

了解 RDB 快照

RDB（Redis 数据库）持久性按指定的时间间隔执行数据集的时间点快照。这些快照表示 Redis 数据库在特定时刻的整个状态。

RDB 的工作原理

当指示 Redis 创建 RDB 快照时，它会执行以下步骤：

**分叉：**Redis 使用 fork（） 系统调用创建子进程。此子进程是父进程（Redis 服务器）的精确副本。
数据转储： 然后，子进程遍历内存中的整个数据集，并将其写入磁盘上的临时文件。
文件压缩（可选）： 默认情况下，Redis 使用 LZF 压缩来压缩 RDB 文件以减小其大小。这可以进行配置。
原子替换： 子进程完成 RDB 文件的写入后，它会以原子方式将旧的 RDB 文件（如果存在）替换为新的 RDB 文件。这可确保 RDB 文件始终处于一致状态。
子进程终止： 然后，子进程将退出，从而释放系统资源。

在整个过程中，父进程继续为客户端请求提供服务，从而最大限度地减少停机时间。但是，fork（） 作可能会占用大量资源，尤其是对于大型数据集，因为它暂时需要双倍的内存。

配置 RDB 快照

您可以使用 redis.conf 文件中的 save 指令配置 RDB 快照。save 指令采用两个参数：秒数和在这些秒内必须发生的更改数才能触发快照。

例如：

save 900 1       # Save the DB if at least 1 key changed in 900 seconds
save 300 10      # Save the DB if at least 10 keys changed in 300 seconds
save 60 10000    # Save the DB if at least 10000 keys changed in 60 seconds

redis.conf 中的这些行定义了三个不同的保存点。如果满足_这些条件中的任何一个_ ，Redis 将触发 RDB 快照。您可以通过注释掉所有保存行来完全禁用 RDB 快照。

您还可以使用 redis-cli 中的 SAVE 或 BGSAVE 命令手动触发 RDB 快照。

SAVE： 此命令执行同步保存，阻止 Redis 服务器，直到快照完成。通常不建议将其用于生产环境。
BGSAVE： 此命令使用上述相同的分叉机制执行异步保存。它允许 Redis 服务器在创建快照时继续为客户端请求提供服务。

RDB 的优势

**压实度：**RDB 文件非常紧凑，非常适合用于备份和灾难恢复。
**性能：**RDB 快照的创建（尤其是压缩）和还原速度相对较快。
**灾难恢复：**RDB 非常适合灾难恢复，因为单个文件代表整个数据集。
**数据可移植性：**RDB 文件易于移植，可以传输到其他服务器或存档以进行长期存储。

RDB 的缺点

**数据丢失可能性：**RDB 快照是时间点备份，因此在快照之间写入的任何数据在服务器发生故障时都将丢失。可能的数据丢失量取决于配置的存储间隔。
分叉开销：fork（） 作可能会占用大量资源，尤其是对于大型数据集，这可能会导致暂时的性能下降。

RDB 配置选项

除了 save 指令之外，redis.conf 中其他与 RDB 相关的配置选项还包括：

stop-writes-on-bgsave-error：如果设置为 yes（默认值），则当 BGSAVE 命令失败时，Redis 将停止接受写入作。这可以防止在出现磁盘错误或磁盘空间不足时损坏数据。
rdbcompression：如果设置为 yes（默认值），Redis 将使用 LZF 压缩 RDB 文件。将其设置为 no 可以提高 CPU 性能，但会导致 RDB 文件变大。
rdbchecksum：如果设置为 yes（默认值），Redis 将在 RDB 文件中包含一个校验和，以检测数据损坏。将其设置为 no 可以提高性能，但会降低数据完整性。
dbfilename：指定 RDB 文件的名称（默认值：dump.rdb）。
dir：指定 RDB 文件的存储目录（默认：Redis 工作目录）。

了解 AOF（仅追加文件）

AOF（仅附加文件）持久性为 RDB 快照提供了更持久的替代方案。AOF 不会定期拍摄快照，而是记录服务器收到的每个写入作。

AOF 的工作原理

启用 AOF 后，Redis 会将每个写入作（例如 SET、HSET、``LPUSH）附加到 AOF 文件中。此文件实质上包含对数据库执行的所有写入作的完整历史记录。

命令附加： 每次执行写入作时，Redis 都会将相应的命令附加到 AOF 文件中。该命令以 Redis 协议格式编写。
**文件同步：**AOF 文件会定期同步到磁盘，以保证数据的持久性。此同步的频率是可配置的。
AOF 重写： 随着时间的推移，AOF 文件可能会变得非常大，因为它包含所有写入作的历史记录。为了减小文件大小，Redis 可以执行 AOF 重写。AOF 重写会创建一个新的、更小的 AOF 文件，其中包含重新创建当前数据集所需的最少命令集。这与 RDB 快照的工作方式类似，但结果仍然是 AOF 文件。

配置 AOF

AOF 在 redis.conf 文件中配置。关键配置选项包括：

appendonly：设置为 yes 以启用 AOF 持久化。设置为 no 可禁用它（默认）。
appendfilename：指定 AOF 文件的名称（默认：appendonly.aof）。
appendfsync：指定 Redis 应将 AOF 文件同步到磁盘的频率。它可以具有以下值之一：
- always：在每次写入作后同步。这提供了最高级别的数据持久性，但也提供了最低的性能。
- everysec：每秒同步一次。这是数据持久性和性能之间的良好平衡（推荐）。
- no：让作系统决定何时同步。这提供了最佳性能，但数据持久性级别最低。

AOF 重写配置

使用以下选项配置 AOF 重写：

auto-aof-rewrite-percentage：指定在触发重写之前 AOF 文件必须增长的百分比。例如，值 100 表示 AOF 文件的大小必须翻倍才能触发重写。
auto-aof-rewrite-min-size：指定触发重写之前 AOF 文件的最小大小。这可以防止重写非常小的 AOF 文件。

您还可以使用 redis-cli 中的 BGREWRITEAOF 命令手动触发 AOF 重写。

AOF 的优势

**高数据持久性：**AOF 提供比 RDB 更高的数据持久性，尤其是在使用 appendfsync always 或 appendfsync everysec 时。
减少数据丢失： 如果服务器发生故障，AOF 可确保将数据丢失降至最低，因为只有最后几个尚未同步到磁盘的命令会丢失。
**人类可读格式：**AOF 文件采用人类可读格式（Redis 协议），因此可以更轻松地在需要时手动调试和恢复数据。

AOF 的缺点

**较大的文件大小：**AOF 文件通常比 RDB 文件大，因为它们包含所有写入作的历史记录。
**性能开销：**AOF 可能会带来性能开销，尤其是在始终使用 appendfsync 时。
**重写开销：**AOF 重写可能是资源密集型的，尽管它是在后台执行的。

RDB 与 AOF：比较

特征	RDB	AOF
数据持久性	较低（可能丢失数据）	更高（最小数据丢失）
文件大小	较小	较大
性能	更快	更慢（尤其是 `always`）
恢复时间	更快	较慢（需要重放命令）
配置	`save` 指令	`appendonly`， `appendfsync` 指令
使用案例	备份、灾难恢复、缓存	需要高数据持久性的应用程序

选择正确的持久性选项

RDB 和 AOF 之间的选择取决于您的具体要求：

RDB： 如果您需要快速备份和恢复，并且可以容忍一些数据丢失，请使用 RDB。它适用于数据丢失不严重的缓存方案。
主干： 如果您需要高数据持久性并且无法承受丢失数据，请使用 AOF。它适用于数据完整性至关重要的应用程序，例如金融系统或存储关键用户信息的数据库。
混合方法： 您还可以同时使用 RDB 和 AOF。在这种情况下，Redis 将使用 AOF 来恢复数据，因为它提供了最完整的数据集。RDB 仍可用于非关键情况下的备份和更快的恢复。

实例

示例 1：为缓存服务器配置 RDB

假设您使用 Redis 作为网站的缓存服务器。数据丢失是可以接受的，因为可以从主数据库中检索数据。在这种情况下，您可以配置具有相对不频繁的保存间隔的 RDB：

save 600 100      # Save if at least 100 keys changed in 600 seconds
save 300 1000     # Save if at least 1000 keys changed in 300 seconds
save 60 10000     # Save if at least 10000 keys changed in 60 seconds

此配置为缓存服务器提供了性能和数据持久性之间的良好平衡。

示例 2：为会话存储配置 AOF

假设您使用 Redis 作为电子商务网站的会话存储。数据丢失是不可接受的，因为它可能导致用户丢失购物车或被注销。在这种情况下，您应该每 sece 使用 appendfsync 配置 AOF：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

此配置可确保每秒将每个会话更改写入磁盘，从而最大限度地降低数据丢失的风险。

示例 3：同时使用 RDB 和 AOF

对于假设的财务应用程序，您可以同时使用 RDB 和 AOF。每 squad 使用 appendfsync 的 AOF 可确保将事务记录的数据丢失降至最低。RDB 快照每天在非高峰时段拍摄，为灾难恢复和报告目的提供方便的备份。如果服务器发生故障，Redis 将使用 AOF 文件进行恢复。如果 AOF 文件已损坏或不可用，则可以将每日 RDB 快照用作回退，从而承认自上次快照以来可能会丢失数据。