谈一谈Redis持久化这个容灾恢复机制

谈一谈Redis持久化这个容灾恢复机制

服务器“闹情绪”宕机可以说是非常常见的情况了，要想“哄好”服务器，Redis是如何保证服务器挂掉重启之后，能够恢复数据的呢？这就是本篇文章要讲的Redis持久化机制。

所谓的持久化就是将内存中的数据写入到磁盘当中去，这样一旦服务器发生故障宕机，重启服务器之后可以从磁盘中读取之前的数据来恢复数据。Redis不同于Memcached的很重要一点就是Redis 支持持久化，而且支持两种不同的持久化操作，RDB方式和AOF方式。谁敢说我家的服务器绝对不会宕机？所以持久化机制对于一个服务器来说是必不可少。接下来我们就来介绍Redis的两种持久化机制。

RDB持久化

可能好多人连RDB是什么的缩写都不知道，RDB是redis database的缩写。我们使用RDB方式进行持久化，可以选择手动执行，也可以设置redis的配置文件，让它定期执行。RDB持久化可以将某一个时间点上的数据库状态，也就是数据库在内存中的数据，保存到一个RDB文件中。这个RDB文件是一个经过压缩的二进制文件，服务器重启时可以读入这个RDB文件还原之前的数据。

这种RDB持久化的方式也称为快照，接下来就讲讲这个RDB是如何生成的，以及启动服务器是如何读入RDB文件的

RDB文件的创建

我们可以手动执行生成RDB文件的命令：SAVE和BGSAVE，这两个命令底层源码中都是调用的同一个函数rdbSave()

• SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求
• BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理命令请求

在执行BGSAVE命令期间，服务器会拒绝客户端发送的SAVE命令，服务器**禁止SAVE命令和BGSAVE同时执行是为了避免服务器进程和子进程同时执行两个rdbSave()函数，防止产生竞争条件。**同样，在BGSAVE命令执行期间，服务器也会拒绝客户端发送的BGSAVE命令。

在执行BGSAVE命令期间，BGREWRITEAOF也不能同时执行。如果BGSAVE正在执行，那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完成之后再执行。如果BGREWRITEAOF正在执行，那么客户端发送的BGSAVE命令会被服务器拒绝。因为这两个命令的实际工作都是由子进程执行，虽然这两个命令在操作方面没有什么冲突，但是出于性能考虑，不允许这两个子进程都同时执行大量的磁盘写入操作。

RDB文件的读取

关于加载RDB文件，Redis并没有提供相应的命令，这是因为RDB文件的加载是在服务器启动的时候自动执行的，底层实现实际上是调用的rdbLoad()函数。如果服务器开启了AOF持久化功能，会优先使用AOF文件来还原数据库状态，如果没有开启AOF持久化功能，则会使用RDB文件来还原数据库状态。服务器在加载RDB文件期间，会一直处于阻塞状态，直到加载工作完成为止。

配置文件设置定期执行

除了手动调用命令来执行RDB持久化操作，我们还可以在redis的配置文件中设置触发自动保存的条件

Redis服务器状态结构体定义中有一个saveparams数组属性，来保存触发条件

Redis服务器状态结构体定义除了保存触发条件，还有一个dirty属性，记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库进行了多少次修改，增加对应的修改次数；和一个lastsave属性，是一个时间戳，记录服务器上一次成功执行SAVE命令或者BGSAVE命令的时间

redis服务器周期性操作函数serverCron()默认每隔100ms就会执行一次，它会检查save选项设置的保存条件是否已经满足，如果满足就会执行BGSAVE命令。

AOF持久化

与RDB快照持久化相比，RDB持久化是保存数据库中所有的键值对数据，而AOF是保存redis服务器所执行过的写命令。

AOF持久化的实现可以分为命令追加、文件写入、文件同步3个步骤

当开启AOF持久化，服务器在执行完一个写命令之后，会将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾

我们说生成的AOF文件是一个命令追加文件，那么这就涉及到什么时候把aof_buf缓冲区里的写命令写入到AOF文件中。

实际上Redis服务器进程就是一个事件循环，服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以服务器每次结束一个事件循环之前，都会将缓冲区里的内容写入到AOF文件中。

我们要知道为了提高文件的写入效率，操作系统都是当用户调用write函数的时候，将一些数据写入到文件的时候，操作系统通常会将写入的数据暂时保存在一个内存缓冲区里面。等到缓冲区的空间被填满，或者超过了指定的时间限制之后，才真正的将缓冲区中的数据写入到磁盘里面。注意，这里的操作系统内存缓冲区和aof_buf缓冲区不是一个东西！一个是底层操作系统层面的东西，一个是C语言数据结构层面的东西！操作系统先写缓冲区的操作虽然提高了效率，但是同时也带来了安全问题，因为如果在内存缓冲区里面的数据还没有及时的刷到磁盘时候，发生故障宕机，那么保存在内存缓冲区里面数据就会丢失掉。为了解决这个安全问题，操作系统提供了同步函数，调用同步函数可以强制将内存缓冲区里面的数据立即写入到磁盘中，这个刷盘的行为也称为数据同步。

当aof_buf缓冲区将内容写入到AOF文件时，可以提供设置appendfsync选项来决定什么进行文件同步：

• 设置为always：将aof_buf内容写入AOF文件的同时进行文件同步
• 设置为everysec：如果距离上一次同步时间超过1秒，就再次对AOF文件进行同步
• 设置为no：不对AOF文件进行同步，什么时候同步交给操作系统说了算

接下来再来继续讲讲AOF文件的加载和数据还原

我们说AOF本质上是一个追加命令的文件，也就是说里面包含了重建数据库状态所需的所有写命令，所以服务器只要读取并重新执行一遍AOF文件里面保存的所有写命令，就可以还原服务器关闭之前的数据库状态。

随着Redis服务器不断的执行写命令，AOF文件面临着体积膨胀的问题。Redis提供了AOF文件重写功能。重写并不是对现有的AOF文件进行读取、分析或者写入操作，而是通过读取服务器当前的数据库状态来实现的。它会从当前数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。相当于保证数据库状态一致性的前提下，对AOF文件中所记录的写命令进行了删减和压缩。

AOF重写会进行大量的写入操作，所以调用这个重写的线程将被长时间阻塞，因此redis会执行BGREWRITEAOF命令创建一个子进程来执行AOF重写操作。子进程在进行AOF重写期间，服务器进程可以继续处理命令请求，同时子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

在子进程执行AOF重写期间，服务器进程仍然会继续处理命令请求，这就可能会对现有的数据库状态进行修改，从而导致服务器当前数据库状态和重写后的AOF文件保存的数据库状态不一致。为了解决这种数据不一致问题，redis服务器设置了一个AOF重写缓冲区，这个AOF重写缓冲区在服务器创建子进程之后开始使用，当redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。

当子进程完成AOF重写之后，会向服务器进程发送一个信号，服务器进程在接收到这个信号之后，它会将AOF重写缓冲区中的所有内容写入到新的AOF文件中，这时新的AOF文件所保存的数据库状态就会和服务器当前数据库状态一致。

RDB持久化和AOF持久化并不是对立的，RDB持久化加载时会阻塞服务器进行，加载缓慢，而AOF实时性比较高，加载快，但容易导致AOF重写。我们可以使用混合持久化方式，同时支持RDB和AOF，结合RDB和AOF 的优点, 快速加载同时避免丢失过多的数据。