Redis AOF&RDB持久化机制介绍

Redis的数据全部存储在内存，如果机器突然宕机，那么数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。Redis为我们提供了两种持久化方案，一种是基于快照RDB（Redis DataBase），另外一种是基于 AOF （Append Only File）日志 。Redis也可以同时支持 AOF 持久化和 RDB 持久化。在这种情况下，当 AOF 重启时，会优先使用 AOF 文件去恢复原始数据。因为 AOF 中保存的数据通常比 RDB 中保存的数据更加完整。

AOF（Append Only File）

AOF ：Redis 默认不开启。它的目的是为了解决生成RDB后数据不能实时一致的问题，所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

Redis每次执行写指令时都会向AOF文件中添加一条日志，但新的记录不会立即写入磁盘(fsync)而是缓存在写入缓冲区中。

我们可以配置将缓冲区中的数据写入磁盘的策略，避免数据丢失。

将缓冲区中数据写入磁盘是一个耗时操作，频繁写磁盘会对性能造成影响但是Redis崩溃丢失数据也较少，因此我们需要根据应用场景进行权衡。

日志重写

AOF中可能会记录多余的指令，若我们对同一个key执行了100次set指令, AOF文件中就会有100条记录但只仅保留最后一条set指令即可恢复数据。AOF重写会整理AOF文件清理不必要的指令日志（如删除被覆盖的set指令），减少AOF文件大小。

redis 采用后台重写的策略，即 fork 一个子进程把整理后的 AOF 写入到临时文件中。使用BGREWRITEAOF可以手动触发后台重写操作。

实际上AOF重写不会读取原来的AOF文件，子进程会带有一份当前数据的副本，并根据该副本直接生成新的AOF文件。

主进程在重写期间将新增的写操作写入原来的 AOF文件 和 AOF重写缓存 中，即使重写失败原来的AOF文件仍保存了完整的数据。当子进程完成AOF重写后会向主进程发送信号，主进程收到该信号后会将AOF重写缓存中的内容写入新的AOF文件，然后用新的AOF文件覆盖原有文件。

工作原理

AOF 日志记录 Redis 的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

命令追加 当 AOF 持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。

文件写入和同步 关于何时将 aof_buf 缓冲区的内容写入 AOF 文件中，Redis 提供了三种写回策略：

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

• Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

AOF持久化优点：

1. 数据安全性：AOF持久化记录了每个写操作的命令，因此在发生故障或重启时，可以通过重新执行AOF文件中的命令来还原数据库的状态。

2. 灵活性：AOF持久化记录了每个写操作的命令，而不仅仅是数据的快照，这使得在数据恢复时更加灵活，可以更细粒度地控制恢复的过程。

3. 增量持久化：AOF持久化是以追加的方式记录写命令，因此对性能的影响相对较小。

 AOF持久化缺点：

1. 文件较大：相对于RDB持久化而言，AOF文件通常会更大，因为AOF文件记录了每个写命令的详细信息。

2. 恢复时间较长：当AOF文件较大时，在Redis重启后，需要将AOF文件中的命令逐个执行以还原数据库的状态，这会导致恢复的时间相对较长，尤其是在AOF文件很大的情况下

RDB（Redis DataBase）

RDB 是 Redis 默认的持久化方案。RDB通过快照的形式将数据保存到磁盘中。所谓快照，可以理解为在某一时间点将数据集的一个快照。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

RDB的原理 

在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发。

针对RDB方式的持久化，手动触发可以使用：

• save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。 

• bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。 

而自动触发的场景主要是有以下几点：

• 根据我们的 save m n 配置规则自动触发； 

• 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave； 

• 执行 debug reload 时； 

• 执行 shutdown时，如果没有开启aof，也会触发。 

由于 save 基本不会被使用到，我们重点看看 bgsave 这个命令是如何完成RDB的持久化的。

RDB持久化优点

Redis RDB机制只需要一个文件dump.rdb即可对Redis的内存数据进行持久化存储，并且具有容灾性好的特点，因为该文件可以保存到安全的磁盘上。

RDB持久化缺点

相对于AOF机制而言，RDB机制的数据安全性可能会稍差一些。

因为RDB机制是间隔一定时间进行一次持久化，如果在两次持久化之间Redis发生故障，可能会导致数据的丢失。

因此，RDB机制更适合对数据安全性要求不高的场景。