Redis持久化：RDB和AOF

绝地灬酷狼 2024-03-22 15:02 4阅读 0赞

## Redis持久化：RDB和AOF ##

> Redis 数据存储在内存中，如果不想办法将数据保存到硬盘上，一旦Redis重启(退出/故障)，内存的数据将会全部丢失。我们肯定不想 Redis 里的数据由于某些故障全部丢失(导致所有请求都走 MySQL)，即便发生了故障也希望可以将Redis原有的数据恢复过来，这就是持久化的作用。
> 
>   Redis 提供了两种不同的持久化方法来将数据存储到硬盘里边：
> 
>  *  **RDB(Redis Database)** ，将某一时刻的所有数据保存到一个 RDB 文件中。
>  *  **AOF(append-only-file)** ，当Redis服务器执行写命令的时候，将执行的写命令保存到 AOF 文件中。

### RDB内存快照，让宕机快速恢复 ###

#### 1.什么是RDB内存快照？ ####

> 在 Redis 执行“写”指令的过程中，内存数据一直会变化，所谓**内存快照**，指的就是 Redis 内存中数据在某一时刻的状态数据，好比时间定格在某一时刻。当我们拍照时，通过照片就能把某一时刻的瞬间画面完全记录下来。Redis 跟这个类似，就是把某一刻的数据以文件的形式拍下来，写到磁盘上，这个快照文件叫做 RDB 文件，RDB 就是 Redis Database 的缩写。

![format_png][]

#### 2.生成RDB的策略 ####

> Redis 并不会在每次执行“写”指令的时候都触发 RDB 写磁盘，只需要在执行内存快照的时候写磁盘，这样既保证了唯快不破，还实现了持久化，宕机快速恢复。
> 
> 我们知道 Redis 的单线程模型决定了我们要尽可能的避免会阻塞主线程的操作，所以就需要尽可能的避免 RDB 文件生成阻塞主线程。为此Redis提供了两个指令用于生成 RDB 文件：
> 
>  *  **SAVE**：会阻塞 Redis 服务器进程，服务器不能接收任何请求，直到 RDB 文件创建完毕为止。
>  *  **BGSAVE**：fork 出一个子进程，由子进程来负责创建 RDB 文件，服务器进程可以继续接收请求。
> 
> 除了手动调用 SAVE 或者 BGSAVE 命令生成 RDB 文件之外，我们可以使用配置的方式来定期执行：在默认的配置下，如果以下的条件被触发，就会执行 BGSAVE 命令。

save 900 1              #在900秒(15分钟)之后，至少有1个key发生变化，
    save 300 10             #在300秒(5分钟)之后，至少有10个key发生变化
    save 60 10000           #在60秒(1分钟)之后，至少有10000个key发生变化
    复制代码

#### 3.RDB实现原理 ####

> 在RDB执行期间为了保证快照的数据一致性，只能处理读操作，不能修改正在执行快照的数据，这种场景，Redis 是允许的。那 Redis 是如何实现一边处理写请求，同时生成RDB文件的呢？
> 
> Redis 使用操作系统的多进程**写时复制技术 COW（Copy On Write）** 来实现快照的持久化。
> 
> Redis 在持久化是会调用 **glibc 的函数（linux系统中最底层的api）fork产生一个子进程**，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段，这时可以将父子进程想象成一个连体婴儿，共享身体。这是Linux操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来，在进程分离的一瞬间，内存的增长几乎没有明显的变化。
> 
> BGSAVE 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。当主线程执行写指令修改数据的时候，这个数据就会复制一份副本，BGSAVE 子进程读取这个副本数据写到 RDB 文件。
> 
> 在执行 SAVE 或 BGSAVE 命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB 文件中。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

![format_png 1][]

#### 4.RDB的优缺点 ####

**优点**

>  *  RDB 文件是一个很简洁的单文件，采用 二进制 + 数据压缩 的方式写磁盘，文件体积小，数据恢复速度快。
>  *  RDB 的性能很好，需要进行持久化时，主进程会 fork 一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。

**缺点**

>  *  RDB 容易造成数据的丢失。假设每5分钟保存一次快照，如果 Redis 因为某些原因不能正常工作，那么从上次产生快照到 Redis 出现问题这段时间的数据就会丢失了。
>  *  RDB 使用 fork() 产生子进程进行数据的持久化，会阻塞主线程，如果数据比较大的话可能就会花费点时间，造成 Redis 停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。

> 另外，过于频繁的执行全量数据快照，有两个严重的性能开销：
> 
>  *  频繁生成 RDB 文件写入磁盘，磁盘压力过大。可能会出现上一个 RDB 还未完成，下一个又开始生成，陷入死循环。
>  *  fork 出 BGSAVE 子进程这个动作本身会阻塞主线程，主线程的内存越大，阻塞时间越长。

### AOF写后日志，避免宕机数据丢失 ###

#### 1.什么是AOF写后日志？ ####

> AOF（Append Only File）写后日志，AOF 持久化就是将修改数据库状态的命令保存到 AOF 文件中，被写入的命令都是以 Redis 的**命令请求协议格式**保存的，Redis 的命令请求协议是纯文本格式。
> 
> 假设 AOF 日志记录了 Redis 实例创建以来所有的修改指令序列，那么就可以通过一个空的 Redis 实例顺序执行所有的指令，也就是“**重放**”，来恢复Redis当前实例的内存数据结构的状态。

**写后日志和写前日志的对比**

> **写前日志（WAL，Write Ahead Log）** ：在实际写数据之前，将修改的数据写到日志文件中，故障恢复得以保证。比如 MySQL Innodb 存储引擎中的 redo log（重做日志）便是记录修改的数据日志，在实际修改数据前先记录修改日志再执行修改数据。
> 
> **写后日志**：先执行“写”指令请求，将数据写入内存，再记录日志。

![format_png 2][]

**日志格式**

> 当 Redis 接收到 “set key value” 命令将数据写入到内存之后，会按照如下格式写入 AOF 文件：
> 
>  *  \*3：表示当前指令分为三个部分，每部分都是 “$ + 数字” 开头，紧跟后面是该部分具体的命令、键、值
>  *  数字：表示这部分的命令、键、值占用的字节大小。比如 “$3” 表示这部分包含三个字节，也就是 set 指令。

![format_png 3][]

**写后日志的好处**

> 写后日志避免了额外的检查开销，不需要对执行的命令进行语法检查。如果使用写前日志的话，就需要先检查语法是否有误，否则日志记录了错误的命令，在使用日志恢复的时候就会报错。另外，写后记录日志，避免了阻塞当前“写”指令的执行。

#### 2.写回策略 ####

> 使用 AOF 也不是万无一失的，假如 Redis 刚执行完指令，还没记录日志就宕机了，就有可能丢失这个命令的相关数据；还有， **AOF 避免了当前命令的阻塞，但是可能会给下一个命令带来阻塞的风险。** AOF 日志是主线程执行的，将日志写入磁盘过程中，如果磁盘压力过大就会导致磁盘写操作很慢，导致后续的“写”指令阻塞。
> 
> 发现了没，这两个问题与磁盘写回有关，如果能合理控制“写”指令执行完后 AOF 日志写回磁盘的时机，问题就可以迎刃而解。

> 为了提高文件的写入效率，当用户调用 write 函数，将一些数据写入到文件时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里，等到缓冲区的空间被填满或者超过了制定的限制之后，才真正将缓冲区中的数据写入到磁盘里面。
> 
> 这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里的写入数据将会丢失。为此系统提供了 fsync 和 fdatasync 两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。
> 
> 与之相对应 Redis 提供了 AOF 配置项 appendfsync 写回策略来控制 AOF 持久化功能的效率和安全性。

appendfsync always     # 同步写回，写指令执行完毕立即将 aof_buf 缓冲区中的内容写到 AOF 文件。
    appendfsync everysec   # 每秒写回，写指令执行完毕，把日志写到 aof_buf 缓冲区，每隔一秒同步到磁盘，该策略为AOF的默认策略。
    appendfsync no         # 操作系统控制，写指令执行完毕，把日志写到 aof_buf 缓冲区，由操作系统决定何时写回磁盘。
    复制代码

#### 3.AOF重写机制 ####

> 由于 AOF 记录的是一个个指令的内容，这就会导致保存的文件太大，另外，故障恢复的时候需要执行每一个指令，如果日志文件太大，整个恢复过程就会非常慢。为此，Reids 设计了 **AOF 重写机制**，提供了 **bgrewriteaof** 命令用于对 AOF 文件进行瘦身。
> 
> 其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中，序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后立即替换旧的 AOF 日志文件。瘦身工作就完成了。
> 
> 重写机制有“多变一”的功能，将旧日志中的多条指令，在重写后就变成了一条指令。如下所示：三条 lpush 命令，经过 AOF 重写后生成一条，对于多次修改的场景，缩减效果明显。

![format_png 4][]

**重写过程**

> 和 AOF 日志由主线程写回不同，重写过程实际是由后台子进程 bgrewriteof 完成的，这也是为了避免阻塞主线程，导致性能下降。
> 
> 总的来说，一共出现**两个日志，一次内存数据拷贝**，分别是**旧的 AOF 日志**和**新的 AOF 重写日志**和**Redis 数据拷贝**。大致流程如下图所示：

![format_png 5][]

> 在上图中，Redis 会将重写过程中接收到的“写”指令操作同时记录到旧的 AOF 缓冲区和新的 AOF 重写缓冲区，这样重写日志也保存了最新的操作，等到拷贝数据的所有操作记录重写完成后，重写缓冲区记录的最新操作也会写到新的 AOF 文件中。
> 
> 每次 AOF 重写时，Redis 会先执行一次内存拷贝，用于遍历数据生成重写记录。防止 AOF 重写过程失败，导致原 AOF 文件被污染，无法做恢复使用。
> 
> 使用两个日志可以保证在重写过程中，新写入的数据不会丢失，并且保持数据的一致性。

#### 4.AOF 的优点和缺点 ####

**优点**

>  *  AOF比RDB可靠。可以灵活制定不同的fsync策略。
>  *  AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。
>  *  当AOF文件过大时，Redis会自动在后台进行重写。
>  *  AOF以命令格式存储于文件中，在数据恢复时，AOF文件比RDB文件更容易让开发人员看懂，并加以修改。

**缺点**

>  *  在相同的数据集下，AOF文件的大小一般会比RDB文件大。
>  *  在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。

### 混合日志模型 ###

> 重启 Redis 时，我们很少使用 RDB 来恢复内存状态，因为可能丢失大量数据。通常采用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB 来说要慢很多，在Redis实例很大的情况下，启动需要花费很长时间。
> 
> Redis 4.0 为了解决这个问题，提供了一个新的持久化选项--**混合持久化**，将 RDB 文件的内容和增量 AOF 日志文件存放到一起，这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分日志很小。

![format_png 6][]

> 在 Redis 重启的时候，先加载 RDB 的内容，然后再重放增量 AOF 日志，这样的操作既保证了 Redis 重启速度，又降低数据丢失风险。

### 总结 ###

>  *  Redis 提供 RDB 快照持久化方案，记录某一时刻数据状态
>  *  Redis 通过写时复制技术设计了**BGSAVE**，避免执行快照期间对读写指令的影响。
>  *  Redis 提供了 AOF 写后日志持久化方案，记录每一条操作指令。
>  *  Redis 通过 AOF 重写方案，避免 AOF文件过大。
>  *  Redis 提供了混合持久化的方案，RDB + AOF 实现持久化保证数据可靠性，同时支持故障后的数据快速恢复。

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/9231c943c4444c20af48bd72c4d2a287.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/758de9c53aea443e919c944486ecd4ba.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/68e4cdd6ea89458082309c893f5c5f6b.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/03f11791e33f4022bf0115c891b8c35a.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/9d0d93a8496e47e68c1b63dbcba8ef41.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/5f43b17380cd47d5a16e4d874b930795.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/e2f9ac2908744220a655266622c40127.png