redis架构系列——redis的持久化机制策略选择方案

吴代庄

已于 2024-03-03 18:53:47 修改

阅读量1.1k

点赞数 28

分类专栏： # 组件文章标签： redis 架构

于 2024-01-30 13:31:48 首次发布

本文链接：https://blog.csdn.net/Luck_gun/article/details/135930302

版权

组件专栏收录该内容

21 篇文章 0 订阅

订阅专栏

本文详细介绍了Redis的两种主要持久化策略：RDB（快照）和AOF（仅追加文件），讨论了它们的优缺点、配置方法以及在生产环境中的应用。强调了在实际配置时如何平衡性能和数据完整性。

摘要由CSDN通过智能技术生成

redis持久化简介

持久性是指将数据写入持久存储。Redis 提供了一系列持久性选项。这些包括：

RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
AOF（仅追加文件）：AOF 持久性记录服务器收到的每个写入操作。然后，可以在服务器启动时再次重放这些操作，从而重建原始数据集。命令使用与 Redis 协议本身相同的格式进行记录。
无持久性：可以完全禁用持久性。这有时在缓存时使用。
RDB + AOF：您还可以将 AOF 和 RDB 组合到同一个实例中。

RDB

优势

RDB 是 Redis 数据的非常紧凑的单文件时间点表示形式。RDB 文件非常适合备份。

RDB 非常适合灾难恢复，它是一个紧凑的文件，可以传输到远程数据中心。

RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作是分叉一个子进程，该子进程将完成所有剩余的工作。父进程永远不会执行磁盘 I/O 或类似操作。

与 Aof 相比，RDB 允许更快地重启大型数据集。

在副本上，RDB 支持在重启和故障转移后进行部分重新同步。

缺点

如果需要在 Redis 停止工作（例如停电后）时将数据丢失的可能性降至最低，RDB则不适合

RDB 需要经常 fork()才能使用子进程在磁盘上持久化。如果数据集很大，fork()可能会很耗时，并且可能会导致 Redis 停止为客户端提供服务几毫秒，如果数据集非常大且 CPU 性能不是很好，则可能会停止为客户端提供服务一秒钟。

配置

默认情况下，Redis 将数据集的快照以二进制形式保存在磁盘上名为dump.rdb。可以配置 Redis 以使其保存数据集每 N 秒一次，如果数据集中至少有 M 个变化，或者您可以手动调用 SAVE 或 BGSAVE 命令。命令如下：

# 同步间隔60秒执行，至少 1000 个键发生更改
save 60 1000
# 异步间隔60秒执行，至少 1000 个键发生更改
bgsave 60 1000

运行流程

每当 Redis 需要将数据集转储到磁盘时，就会发生以下情况：

Redis fork，建立一个子线程；
子线程开始将数据集写入临时 RDB 文件；
当子线程完成新的 RDB 文件编写完后，它将替换旧的备份文件；

AOF

优势

可以有不同的 fsync 策略：完全没有 fsync，每秒 fsync，每次查询 fsync。使用默认的每秒 fsync 策略，写入性能仍然很好。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程会努力执行写入，因此能只丢失一秒钟的写入。

AOF 日志是仅追加日志，因此在断电时不会出现寻道或损坏问题。即使由于某种原因（磁盘已满或其他原因）日志以半写命令结尾，redis-check-aof 工具也能够轻松修复它。

Redis 能够在 AOF 变得太大时在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续追加到旧文件时，会生成一个全新的文件，只需创建当前数据集所需的最少操作集，一旦第二个文件准备就绪，Redis 就会切换两者并开始追加到新文件。
AOF以易于理解和解析的格式一个接一个地包含所有操作的日志。

缺点

对于同一数据集，AOF 文件通常大于等效的 RDB 文件。

AOF 可能比 RDB 慢，具体取决于确切的 fsync 策略。一般来说，将 fsync 设置为每秒一次，性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下，它也应该和 RDB 一样快。尽管如此，即使在写入负载巨大的情况下，RDB 也能够为最大延迟提供更多保证。

配置

在配置文件中打开 AOF：

appendonly yes

从现在开始，每次 Redis 收到更改数据集（例如 SET），它会将其附加到 AOF。重新启动时 Redis 它将重播 AOF 以重建状态。

同步策略主要是有以下三种：

appendfsync always：每次将新命令附加到 AOF 时。非常非常慢，非常安全。请注意，这些命令是在执行来自多个客户端或管道的一系列命令后附加到 AOF 的，因此这意味着一次写入和一次 fsync（在发送回复之前）
appendfsync everysec：每一秒。足够快（因为 2.4 版可能与快照一样快），如果发生灾难，您可能会丢失 1 秒的数据。
appendfsync no：从不，只需将您的数据交到操作系统手中即可。更快、更不安全的方法。通常，Linux 会使用此配置每 30 秒刷新一次数据，但这取决于内核的确切调整。

日志重写

随着写入操作的进行，AOF 变得越来越大执行。重写是完全安全的。当 Redis 继续追加到旧文件时，使用创建当前数据集所需的最少操作集生成一个全新的数据集，一旦第二个文件准备就绪，Redis 将两者切换并开始附加到新文件。

如何使用持续化策略？

如果可以忍受几分钟的发生灾难时数据丢失，可以单独使用RDB。

可以单独使用 AOF，但不建议这样做。因为有一个不时进行 RDB 快照,能在AOF引擎出现错误时更快的进行重启。

AOF 和 RDB 持久性之间的交互

Redis >= 2.4 确保避免在 RDB 时触发 AOF 重写快照操作已在进行中，或者允许 BGSAVE 而 AOF重写正在进行中。这样可以防止两个 Redis 后台进程从同时执行繁重的磁盘 I/O 开始。

如果同时启用了AOF和RDB持久性，并且 Redis 重新启动了AOF文件将用于重建原始数据集，因为它是保证是最完整的。

生产实际使用配置

# 开启aof备份
appendonly yes
# aof备份文件
appendfilename "appendonly.aof"
# aof每秒钟备份
appendfsync everysec

# 设置多次rdb备份策略，例如900秒至少同步1次变更
save 900 1
save 300 10
save 60 10000
save 1200 2