2.1 Redis 中的持久化选项

如果一个只将数据存储在 RAM 中的 Redis 服务器重新启动，所有数据都会丢失。为了防止此类数据丢失，需要有某种机制将数据持久化到磁盘；Redis 提供了两种机制： 快照（snapshotting） 和 追加只写文件（append-only file），或称为 AOF。您可以将 Redis 实例配置为使用其中任何一种，或两者结合使用。

创建快照时，整个数据集的时间点视图会以紧凑的 .rdb 文件形式写入持久存储。您可以设置定期备份，例如每 1、12 或 24 小时一次，并使用这些备份在发生灾难时轻松恢复不同版本的数据集。您还可以使用这些快照创建服务器克隆，或者 simply leave them in place for a future restart。

创建 .rdb 文件需要大量的磁盘 I/O。如果在主 Redis 进程中执行此操作，会降低服务器性能。这就是为什么这项工作由派生的子进程来完成。但即使是 fork 操作，如果数据集很大，也可能很耗时。这可能会导致性能下降，或者 Redis 在几毫秒甚至对于超大型数据集长达一秒钟内无法服务客户端。理解这一点有助于您决定此解决方案是否符合您的需求。

您可以通过 redis.conf 文件或通过 redis-cli（如第一部分第二单元中所述）通过 dbfilename 和 dir 配置指令来配置 .rdb 文件的名称和位置。当然，您可以配置创建快照的频率。以下是 redis.conf 文件中显示默认值的一个示例节选。

举例来说，此配置将使 Redis 在 60 秒内至少有 1000 个键发生更改时自动将数据集转储到磁盘。虽然快照对于上述用例来说是一个很好的策略，但它存在巨大的数据丢失可能性。您可以将快照配置为每隔几分钟或在对数据库进行 X 次写入后运行，但如果服务器崩溃，您将丢失自上次快照以来进行的所有写入。在许多用例中，这种数据丢失是可以接受的，但在许多其他用例中则绝对不可接受。对于所有这些其他用例，Redis 提供了 AOF 持久化选项。

AOF（即 append-only file）通过将每个传入的写入命令发生时记录到磁盘上来工作。然后在服务器启动时可以重播这些命令，以重建原始数据集。命令以与 Redis 协议本身相同的格式记录，以追加方式进行。AOF 方法比快照提供了更高的耐久性，并允许您配置文件同步的频率。

根据您的耐久性要求（或您可以承受的数据丢失量），您可以选择最适合您的用例的 fsync 策略

• •每次写入都 fsync：最安全的策略：写入仅在已写入 AOF 文件并刷新到磁盘后才向客户端确认。由于在这种方法中，我们同步写入磁盘，因此预计延迟会比平时高得多。
• •每秒 fsync：默认策略。fsync 在后台线程中异步执行，因此写入性能仍然很高。如果您需要高性能并且可以承受丢失最多一秒钟的写入数据，请选择此选项。
• •不 fsync：在这种情况下，Redis 会将命令记录到文件描述符，但不会强制 OS 将数据刷新到磁盘。如果 OS 崩溃，我们可能会丢失几秒钟的数据（通常 Linux 在此配置下每 30 秒刷新一次数据，但这取决于内核的具体调优。）。

屏幕上显示了与 AOF 相关的配置指令。AOF 包含所有修改数据库的操作日志，其格式易于理解和解析。当文件过大时，Redis 可以在后台自动重写文件，对其进行压缩，只保留数据的最新状态。