Redis 如何将数据写入磁盘

持久性是指将数据写入持久存储，例如固态磁盘 （SSD）。Redis 提供了一系列持久性选项。其中包括：

• RDB（Redis 数据库）：RDB 持久性按指定的时间间隔执行数据集的时间点快照。

• AOF（仅追加文件）：AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作，重建原始数据集。命令的记录格式与 Redis 协议本身相同。

• No persistence：可以完全禁用持久性。这有时在缓存时使用。

• RDB + AOF：您还可以在同一实例中组合 AOF 和 RDB。

一、RDB

1、RDB优势

• RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示形式。RDB 文件非常适合备份。例如，您可能希望每隔 24 小时存档一次 RDB 文件，并将 RDB 快照每天保存 30 天。这使您可以在发生灾难时轻松还原数据集的不同版本。

• RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或 Amazon S3（可能加密）的单个紧凑文件。

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

• 与 AOF 相比，RDB 允许更快地重新启动大数据集。

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

2、RDB 缺点

• 如果您需要在 Redis 停止工作（例如停电后）将数据丢失的可能性降至最低，则 RDB 不好。您可以在生成 RDB 的位置配置不同的保存点（例如，在至少 100 分钟和针对数据集写入 <> 次后，您可以有多个保存点）。但是，您通常会每五分钟或更长时间创建一个 RDB 快照，因此，如果 Redis 因任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新几分钟的数据。

• RDB 经常需要 fork（） 才能使用子进程持久化在磁盘上。如果数据集很大，fork（） 可能会很耗时，如果数据集非常大且 CPU 性能不是很好，则可能会导致 Redis 停止为客户端提供服务几毫秒甚至一秒钟。AOF 还需要 fork（），但频率较低，您可以调整重写日志的频率，而无需牺牲持久性。

二、AOF

1、AOF优势

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

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

• Redis 能够在 AOF 变得太大时在后台自动重写它。重写是完全安全的，因为当 Redis 继续追加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始追加到新文件。

• AOF 以易于理解和解析的格式包含所有操作一个接一个的日志。您甚至可以轻松导出 AOF 文件。例如，即使您使用 FLUSHALL 命令意外刷新了所有内容，只要在此期间没有重写日志，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存数据集。

2、AOF缺点

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

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

三、快照

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

例如，如果至少更改了1000个键，此配置将使Redis每60秒自动将数据集转储到磁盘：

save 60 1000

四、工作原理

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

• Redis分叉。我们现在有了一个子进程和一个父进程。

• 子项开始将数据集写入临时 RDB 文件。

• 当孩子写完新的RDB文件时，它会替换旧的 一。

该方法允许Redis从写时复制语义中获益。

五、仅追加文件

快照不太耐用。如果运行Redis的计算机停止运行，电源线发生故障，或者意外杀死了-9个实例，则写入Redis的最新数据将丢失。虽然这对某些应用程序来说可能不是什么大问题，但也有完全持久性的用例，在这些情况下，仅使用Redis快照是不可行的。

仅附加文件是Redis的一种完全持久的替代策略。它在1.1版中可用。

您可以在配置文件中打开AOF：

appendonly yes

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

从 Redis 7.0.0 开始，Redis 使用多部分 AOF 机制。 也就是说，原始的单个 AOF 文件被拆分为基本文件（最多一个）和增量文件（可能有多个）。 基本文件表示重写 AOF 时存在的数据的初始（RDB 或 AOF 格式）快照。 增量文件包含自上次创建基本 AOF 文件以来的增量更改。所有这些文件都放在一个单独的目录中，并由清单文件跟踪

六、日志重写

随着写入操作的出现，AOF变得越来越大 执行。例如，如果要将计数器递增 100 倍， 您最终会在数据集中获得一个包含最终 值，但 AOF 中有 100 个条目。其中 99 个条目不需要 以重建当前状态。

重写是完全安全的。 当 Redis 继续追加到旧文件时， 使用创建当前数据集所需的最少操作集生成一个全新的， 一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新文件。

所以 Redis 支持一个有趣的功能：它能够重建 AOF 在后台，而不会中断对客户端的服务。每当 你发出一个BGREWRITEAOF，Redis会写最短的序列 在内存中重建当前数据集所需的命令。如果你是 将 AOF 与 Redis 2.2 一起使用，您需要不时运行 BGREWRITEAOF 时间。由于 Redis 2.4 能够自动触发日志重写（请参阅 示例配置文件以获取更多信息）。

从 Redis 7.0.0 开始，当计划进行 AOF 重写时，Redis 父进程会打开一个新的增量 AOF 文件以继续写入。 子进程执行重写逻辑并生成新的基本 AOF。 Redis 将使用临时清单文件来跟踪新生成的基本文件和增量文件。 准备就绪后，Redis 将执行原子替换操作以使此临时清单文件生效。 为了避免在 AOF 重写重复失败和重试的情况下创建许多增量文件的问题， Redis 引入了 AOF 重写限制机制，以确保以越来越慢的速度重试失败的 AOF 重写。

七、仅追加文件的持久性如何？

您可以配置 Redis 在磁盘上同步数据的次数。有 三个选项：

• appendfsync always：每次向AOF附加新命令时，都会执行fsync。非常慢，非常安全。请注意，在执行来自多个客户机或管道的一批命令后，这些命令会附加到AOF中，因此这意味着（在发送回复之前）进行一次写入和一次fsync。

• appendfsync everysec：fsync每秒钟一次。足够快（因为2.4版可能与快照一样快），如果发生灾难，您可能会丢失1秒的数据。

• appendfsync no:永远不要fsync，只需将数据交给操作系统即可。更快、更不安全的方法。通常情况下，Linux使用此配置每30秒刷新一次数据，但这取决于内核的精确调整。

建议的（也是默认的）策略是每秒fsync一次。它既快速又相对安全。always策略在实践中非常缓慢，但它支持组提交，因此如果存在多个并行写入，Redis将尝试执行单个fsync操作。

八、AOF 和 RDB 持久性之间的交互

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

当快照正在进行并且用户显式请求日志时 使用 BGREWRITEA 的重写操作服务器将回复 OK 状态代码告诉用户操作已计划，并重写 将在快照完成后开始。

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

官网：Doker 多克; 官方旗舰店：首页-Doker 多克 多克创新科技企业店-淘宝网全品优惠

?