谈一谈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 的优点, 快速加载同时避免丢失过多的数据。