众所周知，Redis是内存数据库，它将自己的数据库状态存储在内存里面，所以如果不想办法将存储在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。
      为了解决这个问题，Redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。
      RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。
      RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。
请输入图片描述

RDB文件的创建和载入

      有两个命令可以用于生成RDB文件：SAVE和BGSAVE。SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程(父进程)继续处理命令请求。
      创建RDB文件的函数为rdb.c/rdbSave，SAVE和BGSAVE命令会以不同的方式调用这个函数。

def SAVE():
    #创建RDB文件
    rdbSave()

def BGSAVE():
    #创建子进程
    pid=fork()
    if pid == 0:
        #子进程负责创建RDB文件
        rdbSave()
        #完成之后向父进程发送信号
        signal parent()
    elif pid > 0:
        #父进程继续处理命令请求，并通过轮询等待子进程的信号
        handle_request_and_wait_signal()
    else:
        #处理出错情况
        handle_fork_error()

      和使用命令创建RDB文件不同，RDB文件的载入工作室在服务器启动时自动执行的，所以Redis没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件的存在，它就会自动载入RDB文件。

因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：

  • 如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态
  • 只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态

请输入图片描述

BGSAVE命令执行时的服务器状态

      因为BGSAVE命令的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，Redis服务器仍然可以继续处理客户端的命令请求，但是，在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会和平时有所不同。

  • 首先，在BGSAVE命令执行期间，客户端发送的SAVE命令会被服务器拒绝，服务器禁止SAVE命令和BGSAVE命令同时执行是为了避免父进程和子进程同时执行两个rdbSave调用，防止竞争条件。
  • 其次，在执行BGSAVE期间，客户端发送的BGSAVE命令会被服务器拒绝，因为同时执行两个BGSAVE命令也会产生竞争条件

  • 最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行：

    • 如果BGSAVE命令正在执行，那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行
    • 如果BGREWRITEAOF命令正在执行，那么客户端发送的BGSAVE命令会被服务器拒绝

      因为BGREWRITEAOF和BGSAVE两个命令的实际工作都由子进程执行，所以这两个命令在操作方面并没有什么冲突的地方，不能同时执行它们只是一个性能方面的考虑——并发出两个子进程，并且这两个子进程都同时执行大量的磁盘写入操作，这怎么想都不会是一个好主意。

RDB文件加入时的服务器状态

      服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

自动间隔保存

      因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis运行用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

################################ SNAPSHOTTING  ################################
#
# 保存数据到磁盘:
#
#   save <seconds> <changes>
#
#   如果距离上一次保存数据库的时间(seconds)发生了指定的写操作次数(changes)则将保存数据库。
#
#   在下面默认配置的示例中，将会保存数据：
#   在900秒中发生了至少1次数据变化
#   在300秒中发生了至少10次数据变化
#   在60秒中发生了至少10000次数据变化
#
#   注意：您可以通过注释掉所有"保存"行来完全禁用保存。
#
#   也可以通过添加带有单个空字符串参数的save指令来删除所有先前配置的保存点，如以下示例所示：
#
#   save ""

save 900 1
save 300 10
save 60 10000

设置保存条件

      当Redis服务器启动时，用户可以通过指定配置文件或者传入启动参数的方式设置save选项，如果用户没有主动设置save选项，那么服务器会为save选项设置默认条件。接着，服务器程序会根据save选项所设置的保存条件，设置服务器状态redis.h/redisServer结构的saveparams属性：

struct redisServer{
    ...
    //记录保存条件的数组
    struct saveparam *saveparams;   /* Save points array for RDB */
    ...
}

      每个saveparam结构都保存了一个save选项设置的保存条件：

struct saveparam{
    //秒数
    time_t seconds;
    //修改次数
    int changes;
}

      比如上述的save选项表示的数组如图所示：
请输入图片描述

dirty计数器和lastsave属性

      除了saveparams数组之外，服务器状态还维持着一个dirty计数器，以及一个lastsave属性。

  • dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态(服务器中的所有数据库)进行了多少次修改(包括写入、删除、更新等操作)
  • lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间

      当服务器成功执行一个数据库修改命令之后，程序就会对dirty计数器进行更新。

检查保存条件是否满足

      Redis的服务器周期性操作函数redis.c/serverCron默认每隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。伪代码如下：

def serverCron():
    #...
    #遍历所有保存条件
    for saveparam in server.saveparams:
        #计算距离上次执行保存操作有多少秒
        save interval=unixtime_now()-server.lastsave

        #如果数据库状态的修改次数超过条件所设置的次数
        #并且距离上次保存的时间超过条件所设置的时间
        #那么执行保存操作
        if server.dirty >= saveparam.changes and\
           save interval>saveparam.seconds:
               BGSAVE()
    #...

      程序会遍历并检查saveparams数组中的所有保存条件，只要有任意一个条件被满足，那么服务器就会执行BGSAVE命令。

RDB文件结构

      一个完整的RDB文件包含的各个部分如下所示：
请输入图片描述

      RDB文件的最开头是REDIS部分，这个部分的长度为5字节，保存着"REDIS"五个字符。通过这五个字符，程序可以在载入文件时，快速检查所载入的文件是否RDB文件。有点class字节码文件魔数的味道。
      db_version长度为4字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件的版本号。
      databases部分包含零个或任意多个数据库，以及各个数据库中的键值对数据：

  • 如果服务器的数据库状态为空(所有数据库都是空)，那么这个部分也为空，长度为0字节；
  • 如果服务器的数据库状态Wie非空(至少一个数据库非空)，那么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容不同，这个部分的长度也会有所不同

      EOF常量的长度为1字节，这个常量标志着RDB文件正文内容的结束。当读入程序遇到这个值的时候，它知道所有数据库的所有键值对都已经载入完毕了。
      check_sum是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序对REDIS、db_version、databases、EOF四个部分的内容进行计算得出的。服务器在载入RDB文件时，会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比，以此检查RDB文件是否有出错或者损坏的情况出现。

database部分

      一个RDB文件的databases部分可以保存任意多个非空数据库。每个非空数据库在RDB文件中都可以保存为SELECTDB、db_number、key_value_pairs三个部分。
请输入图片描述

      SELECTDB常量的长度为1字节，当读入程序遇到这个值的时候，它知道接下来要读入的哪一个数据库。
      db number保存着一个数据库号，根据数据库号的大小不同，这个部分的长度可以是1字节、2字节或者5字节。当程序读入db number部分之后，服务器会调用SELECT命令，根据读入的数据库号码进行数据库切换，使得之后读入的键值对可以载入到正确的数据库中。
      key value_pairs部分保存了数据库中的所有键值对数据，如果键值对带有过期时间，那么过期时间也会和键值对保存在一起。根据键值对的数量、类型、内容以及是否有过期时间等条件的不同，key_value_pairs部分的长度也会有所不同。
请输入图片描述

key_value_pair部分

      RDB文件中的每个key_value_pairs部分都保存了一个或以上数量的键值对，如果键值对带有过期时间的话，那么键值对的过期时间也会被保存在内。
      不带过期时间的键值对在RDB文件中由TYPE、key、value三部分组成，TYPE记录了value的类型，长度为一字节：

  • REDIS_RDB_TYPE_STRING
  • REDIS_RDB_TYPE_LIST
  • REDIS_RDB_TYPE_SET
  • REDIS_RDB_TYPE_ZSET
  • REDIS_RDB_TYPE_HASH
  • REDIS_RDB_TYPE_LIST_ZIPLIST
  • REDIS_RDB_TYPE_SET_INTSET
  • REDIS_RDB_TYPE_ZSET_ZIPLIST
  • REDIS_RDB_TYPE_HASH_ZIPLIST

      以上列出的每个TYPE常量都代表了一种对象类型或者底层编码，当服务器读入RDB文件中的键值对数据时，程序会根据TYPE的值来决定如何读入和解释value的数据。key和value分别保存了键值对的键对象和值对象：

  • 其中key总是一个字符串对象，它的编码方式和REDIS RDBTYPE
    STRING类型的value一样。根据内容长度的不同，key的长度也会有所不同。
  • 根据TYPE类型的不同，以及保存内容长度的不同，保存value的结构和长度也会有所不同。

      带有过期时间的键值对在RDB文件中的结构如图所示：
请输入图片描述

      新增的EXPIRETIME MS和ms，它们的意义如下：

  • EXPTRETIMEMS常量的长度为1字节，它告知读入程序，接下来要读入的将是一个以毫秒为单位的过期时间。
  • ms是一个8字节长的带符号整数，记录着一个以毫秒为单位的UNIX时间戳，这个时间戳就是键值对的过期时间。

value部分

      RDB文件中的每个value部分都保存了一个值对象，每个值对象的类型都由与之对应的TYPE记录，根据类型的不同，value部分的结构、长度也会有所不同。

重点回顾

  • RDB文件用于保存和还原Redis服务器所有数据库中的所有键值对数据。
  • SAVE命令由服务器进程直接执行保存操作，所以该命令会阻塞服务器。
  • BGSAVE令由子进程执行保存操作，所以该命令不会阻塞服务器。
  • 服务器状态中会保存所有用save选项设置的保存条件，当任意一个保存条件被满足时，服务器会自动执行BGSAVE命令。
  • RDB文件是一个经过压缩的二进制文件，由多个部分组成。
  • 对于不同类型的键值对，RDB文件会使用不同的方式来保存它们。

版权属于：带翅膀的猫

本文链接：https://www.chengpengper.cn/archives/121/

转载时须注明出处及本声明

Last modification：September 18th, 2020 at 03:24 pm
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏