Redis的持久化：RDB和AOF

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

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

RDB优势

• RDB 是 Redis 数据的一个非常紧凑压缩的二进制文件。RDB 文件非常适合备份。例如，您可能希望每隔 24 小时存档一次 RDB 文件，并将 RDB 快照保存 30 天。这使您可以在发生灾难时轻松还原数据集的不同版本。
• RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或 Amazon S3（可能加密）的单个紧凑文件。
• RDB 最大限度地提高了 Redis 性能，因为 Redis 父进程为了持久化而需要做的唯一工作是分叉一个子进程，该子进程将完成所有其余工作。父进程永远不会执行磁盘 I/O 或类似操作。
• 与 AOF 相比，RDB 允许更快地重新启动大数据集。
• 在副本上，RDB 支持重新启动和故障转移后的部分重新同步。

RDB 缺点

• 如果您需要在 Redis 停止工作（例如停电后）将数据丢失的可能性降至最低，则 RDB 不好。您可以在生成 RDB 的位置配置不同的保存点（例如，在至少 100 分钟和针对数据集写入 <> 次后，您可以有多个_保存点_）。但是，您通常会每五分钟或更长时间创建一个 RDB 快照，因此，如果 Redis 因任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新几分钟的数据。
• RDB 经常需要 fork（） 才能使用子进程持久化在磁盘上。如果数据集很大，fork（） 可能会很耗时，如果数据集非常大且 CPU 性能不是很好，则可能会导致 Redis 停止为客户端提供服务几毫秒甚至一秒钟。AOF 还需要 fork（），但频率较低，您可以调整重写日志的频率，而无需牺牲持久性。

AOF优势

• 更及时：您可以拥有不同的 fsync 策略：完全没有 fsync，每秒 fsync 一次，每次查询时 fsync。使用每秒 fsync 的默认策略，写入性能仍然很高。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
• AOF 日志是仅追加日志，因此在断电时不会有寻道或损坏问题。即使由于某种原因（磁盘已满或其他原因）日志以半写命令结束，redis-check-aof 工具也可以轻松修复它。
• Redis 能够在 AOF 变得太大时在后台自动重写它。重写是完全安全的，因为当 Redis 继续追加到旧文件时，会使用当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始追加到新文件。
• AOF 以易于理解和解析的格式包含所有操作一个接一个的日志。您甚至可以轻松导出 AOF 文件。例如，即使您使用 FLUSHALL 命令意外刷新了所有内容，只要在此期间没有重写日志，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存数据集。

AOF缺点

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

两种持久化机制如何选择

如果您非常关心您的数据，但仍然可以忍受几分钟 的数据丢失 在发生灾难时，您可以简单地单独使用RDB。
有许多用户单独使用 AOF，但我们不鼓励这样做，因为有一个 不时使用RDB快照是进行数据库备份的好主意， 以加快重新启动速度，并在 AOF 引擎中出现错误时。

混合持久化

aof-use-rdb-preamble yes
混合持久化的加载流程如下：

1. 判断是否开启 AOF 持久化，开启继续执行后续流程，未开启执行加载 RDB 文件的流程；
2. 判断 appendonly.aof 文件是否存在，文件存在则执行后续流程；
3. 判断 AOF 文件开头是 RDB 的格式, 先加载 RDB 内容再加载剩余的 AOF 内容；
4. 判断 AOF 文件开头不是 RDB 的格式，直接以 AOF 格式加载整个文件。

快照原理

• Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）
• 子进程开始将数据集写入临时 RDB 文件。
• 当子进程写完新的RDB文件时，它会替换旧的RDB文件。

在执行 fork 的时候操作系统（类 Unix 操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

配置

创建：生成RDB文件有两个命令： save 和 bgsave;
save命令会阻塞redis进程，直到RDB文件创建完为止，期间服务器不能处理命令；
bgsave会创建一个子进程，异步生成RDB文件；不影响服务器处理命令；
载入： redis启动后会自动载入RDB文件；载入文件期间，服务处于阻塞状态；
自动间隔性保存：
举个例子，如果我们向服务器提供以下配置：

save 900 1
save 300 10
save 60 10000

那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行：
❑服务器在900秒之内，对数据库进行了至少1次修改。
❑服务器在300秒之内，对数据库进行了至少10次修改。
❑服务器在60秒之内，对数据库进行了至少10000次修改。

仅追加文件

快照间隔时间较大；
您可以配置 Redis 在磁盘上同步数据的次数。有 三个选项：

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

建议（默认）策略是每秒。是的 既快速又相对安全。该政策非常缓慢 实践，但它支持组提交，所以如果有多个并行 写入 Redis 将尝试执行单个操作。

重写

重写： 直接读取数据库中的值；
子进程重写时，服务器会将主进程执行的命令追加到AOF缓冲区，保证重写期间执行的命令也能同步；