0%

Redis 设计与实现-RDB 持久化

发表于 更新于 分类于 ， 阅读次数： Valine：
本文字数： 7.2k 阅读时长 ≈ 7 分钟

本文首先介绍Redis服务器保存和载人RDB文件的方法,重点说明 SAVE 命令和 BGSAVE 命令的实现方式。之后,本章会继续介绍Redis服务器自动保存功能的实现原理。

在介绍完关于保存和载入RDB文件方面的内容之后,我们会详细分析RDB文件中的各个组成部分,并说明这些部分的结构和含义。

1. RDB 文件的创建与载入

有两个Redis命令可以用于生成RDB文件,一个是SAVE ,另一个是 BGSAVE 。SAVE 命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。和BGSAVE 命令直接阻塞服务器进程的做法不同,BGSAVE 命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程(父进程)继续处理命令请求。

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

另外值得一提的是,因为AOF文件的更新频率通常比RDB文件的更新频率高,所以:

  • 如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据库状态。

  • 只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

服务器判断该用哪个文件来还原数据库状态的流程如图10-4所示

1.1 SAVE 命令执行时的服务器状态

前面提到过,当SAVE 命令执行时,Redis服务器会被阻塞,所以当SAVE 命令正在执行时、客户端发送的所有命令请求都会被拒绝。

只有在服务器执行完SAVE 命令、重新开始接受命令请求之后,客户端发送的命令才会被处理。

1.2 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 两个命令的实际工作都由子进程执行,所以这两个命令在操作方面并没有什么冲突的地方,不能同时执行它们只是一个性能方面的考虑一一并发出两个子进程,并且这两个子进程都同时执行大量的磁盘写人操作,这怎么想都不会是一个好主意。

1.3 RDB文件载入时的服务器状态

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

2. 自动间隔性保存

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

用户可以通过save选项设置多个保存条件,但只要其中任意一个条件被满足,服务器就会执行BGSAVE命令。

举个例子,如果我们向服务器提供以下配置:

1
2
3
save 900 1
save 300 10
save 60 10000

那么只要满足以下三个条件中的任意一个,BGSAVE命令就会被执行:

  • 服务器在900秒之内,对数据库进行了至少1次修改。
  • 服务器在300秒之内,对数据库进行了至少10次修改。
  • 服务器在60秒之内,对数据库进行了至少10000次修改。

2.1 设置保存条件

服务器程序会根据save选项所设置的保存条件,设置服务器状态redisServer结构的saveparams属性:

saveparams 属性是一个数组,数组中的每一个元素都是一个saveparam结构，每个saveparam结构都保存了一个save选项设置的保存条件:

那么服务器状态中的saveparams数组将会是图10-6所示的样子。

2.2 dirty 计数器和 lastsave 属性

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

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

2.3 检查保存条件是否满足

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

3. RDB 文件结构

RDB文件的最开头是RRDIS部分,这个部分的长度为5字节,保存着“REDIS“五个字符。通过这五个字符,程序可以在载入文件时,快速检查所载人的文件是否RDB文件。

adb_version长度为4字节,它的值是一个字符串表示的整数,这个整数记录了RDB 文件的版本号,比如“0006“就代表RDB文件的版本为第六版。

databases部分包含着零个或任意多个数据库,以及各个数据库中的键值对数据:

  • 如果服务器的数据库状态为空(所有数据库都是空的),那么这个部分也为空,长度为0字节。

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

EOF常量的长度为1字节,这个常量标志着RDB文件正文内容的结束,当读入程序遇到这个值的时候,它知道所有数据库的所有键值对都已经载人完毕了。

check_sum是一个8字节长的无符号整数,保存着一个校验和,这个校验和是程序通过对REDIS、db_version、adatabases、EOF四个部分的内容进行计算得出的。服务器在载入RDB文件时,会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比,以此来检查RDB文件是否有出错或者损坏的情况出现。

3.1 database 部分

一个RDB文件的databases部分可以保存任意多个非空数据库。

例如,如果服务器的0号数据库和3号数据库非空,那么服务器将创建一个如图10-12所示的RDB文件, 图中的daatabase 0代表0号数据库中的所有键值对数据,而database 3则代表3号数据库中的所有键值对数据。

每个非空数据库在RDB文件中都可以保存为SELECTDB、db_number、keyValue_Pairs三个部分,如图10-13所示。

SELECTDB 常量的长度为1字节,当读人程序遇到这个值的时候,它知道接下来要读人的将是一个数据库导码。

db_numbeI 保存着一个数据库号码,根据号码的大小不同，这个部分的长度可以是 1 字节、2字节或者5字节。当程序读人db_number部分之后,服务器会调用SELECT命令,根据读入的数据库号码进行数据库切换,使得之后读入的键值对可以载人到正确的数据库中。

key_value_pairs 部分保存了数据库中的所有键值对数据,如果键值对带有过期时间,那么过期时间也会和键值对保存在一起。根据键值对的数量、类型、内容以及是否有过期时间等条件的不同,key_value_pairs部分的长度也会有所不同。另外,图10-15则展示了一个完整的RDB文件,文件中包含了0号数据库和3号数据库。

3.2 key_value_pairs 部分

RDB文件中的每个key_value_pairs部分都保存了一个或以上数量的键值对,如果键值对带有过期时间的话,那么键值对的过期时间也会被保存在内。不带过期时间的键值对在RDB文件中由TYPE、key、value三部分组成,如图10-16所示。

TYPE记录了value的类型,长度为1字节,值可以是以下常量的其中一个:

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

  • 其中key总是一个字符串对象,它的编码方式和REDIS_RDB_TYPE_STRING类型的value一样。根据内容长度的不同,key的长度也会有所不同。
  • 根据TYPE类型的不同,以及保存内容长度的不同,保存value的结构和长度也会有所不同,稍后会详细说明每种TYPE类型的value结构保存方式。

带有过期时间的键值对在RDB文件中的结构如图10-17所示。

带有过期时间的键值对中的TYPE、key、value三个部分的意义,和前面介绍的不带过期时间的键值对的TYPE、key、value三个部分的意义完全相同,至于新增的EXPIRETIME_MS和ms,它们的意义如下:

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

图10-19展示了一个带有过期时间的集合键值对、其中键的过期时间为1388556000000(2014年1月1日零时)

3.3 value 编码

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

3.3.1 字符串对象

如果TYPE的值为REDIS_RDB_TYPE_STRING,那么value保存的就是一个字符串对象,字符串对象的编码可以是RERDIS_ENCODING_INT或者REDIS_ENCODING_RRW。

如果字符串对象的编码为RERDIS_ENCODING_INT,那么说明对象中保存的是长度不超过32位的整数,这种编码的对象将以图10-20所示的结构保存。

其中,ENCODING 的值可以是REDIS_RDB_ENC_INT8、REDIS_RDB_ENC_INT16或者REDIS_RDB_ENC_INT32三个常量的其中一个,它们分别代表RDB文件使用8位(bit)、16位或者32位来保存整数值integer。

如果字符串对象的编码为RERDIS_ENCODING_RAW,那么说明对象所保存的是一个字符串值,根据字符串长度的不同,有压缩和不压缩两种方法来保存这个字符串:

  • 如果字符串的长度小于等于20字节,那么这个字符串会直接被原样保存。

  • 如果字符串的长度大于20字节,那么这个字符串会被压缩之后再保存。

对于没有被压缩的字符串,RDB程序会以图10-22所示的结构来保存该字符串。其中,string部分保存了字符串值本身,而len保存了字符串值的长度。

对于压缩后的字符串,RDB程序会以图10-23所示的结构来保存该字符串。

其中,REDIS_RDB_ENC_LZF常量标志着字符串已经被LZF算法压缩过了,读入程序在碰到这个常量时,会根据之后的compressed_len、origin_len和compressed_string三部分,对字符串进行解压缩:其中compressed_len记录的是字符串被压缩之后的长度,而origin_len记录的是字符串原来的长度,compressed_string记录的则是被压缩之后的字符串。

3.3.2 列表对象

如果TYPF的值为REDIS_RDB_TYPE5_LIST,那么value保存的就是一个REDIS_ENCODING_LINKEDLIST编码的列表对象,RDB文件保存这种对象的结构如图10-26所示。

list_length 记录了列表的长度,它记录列表保存了多少个项(item),读入程序可以通过这个长度知道自己应该读人多少个列表项。图中以item开头的部分代表列表的项,因为每个列表项都是一个字符串对象,所以程序会以处理字符串对象的方式来保存和读人列表项。作为示例,图10-27展示了一个包含三个元素的列表。

结构中的第一个数字3是列表的长度,之后跟着的分别是第一个列表项、第二个列表项和第三个列表项,其中:

  • 第一个列表项的长度为5,内容为字符串“hello“。

  • 第二个列表项的长度也为5,内容为字符串“world“。

  • 第三个列表项的长度为1,内容为字符串“!“。

3.3.3 集合对象

如果TYPF的值为REDIS_RDB_TYPE_SET,那么value保存的就是一个REBDIS_ENCODING_HT编码的集合对象,RDB文件保存这种对象的结构如图10-28所示。

其中,set_size是集合的大小,它记录集合保存了多少个元素,读人程序可以通过这个大小知道自己应该读入多少个集合元素。图中以elem开头的部分代表集合的元素,因为每个集合元素都是一个字符串对象,所以程序会以处理字符串对象的方式来保存和读人集合元素。作为示例,图10-29展示了一个包含四个元素的集合。

结构中的第一个数字4记录了集合的大小,之后跟着的是集合的四个元素:

  • 第一个元素的长度为5,值为“apple“。

  • 第二个元素的长度为6,值为“banana“。

  • 第三个元素的长度为3,值为“cat“。

  • 第四个元素的长度为3,值为“dog“。

3.3.4 哈希表对象

如果TYPE的值为REDIS_RDB_TYPE_HASH,那么value保存的就是一个RERDIS_ENCODING_HT编码的集合对象,RDB文件保存这种对象的结构如图10-30所示:

  • hash_size记录了哈希表的大小,也即是这个哈希表保存了多少键值对,读入程序可以通过这个大小知道自己应该读人多少个键值对。
  • 以key_value_pair开头的部分代表哈希表中的键值对,键值对的键和值都是字符串对象,所以程序会以处理字符串对象的方式来保存和读入键值对。

结构中的每个键值对都以键紧挨着值的方式排列在一起,如图10-31所示。

作为示例,图10-33展示了一个包含两个键值对的哈希表。

3.3.5 有序集合对象

如 TYPE 的值为REDIS_RDB_TYPE_ZSET,那么value保存的就是一个REDIS_ENCODING_SKIPLTIST编码的有序集合对象,RDB文件保存这种对象的结构如图10-34所示。

sorted_set_size记录了有序集合的大小,也即是这个有序集合保存了多少元素,读人程序需要根据这个值来决定应该读人多少有序集合元素。以element开头的部分代表有序集合中的元素,每个元素又分为成员(member)和分值(score)两部分,成员是一个字符串对象,分值则是一个double类型的浮点数,程序在保存RDB文件时会先将分值转换成字符串对象,然后再用保存字符串对象的方法将分值保存起来。

有序集合中的每个元素都以成员紧挨着分值的方式排列,如图10-35所示。

作为示例,图10-37展示了一个带有两个元素的有序集合。

3.3.6 INTSET 编码的集合

如果TYPE的值为REDIS_RDB_TYPE_SET_INTSET,那么value保存的就是一个整数集合对象,RDB文件保存这种对象的方法是,先将整数集合转换为字符串对象,然后将这个字符串对象保存到RDB文件里面。如果程序在读入RDB文件的过程中,碰到由整数集合对象转换成的字符串对象,那么程序会根据TYPE值的指示,先读人字符串对象,再将这个字符串对象转换成原来的整数集合对象。

3.3.7 ZIPLIST 编码的列表、哈希表或者有序集合

如果TYPF的值为RRDIS_RDR_TYPE_LIST_ZIPLIST、RRDIS_RDR_TYPE_HASH_ZIPLIST或者RRDIS_RDR_TYPE_ZST_ZIPLIST,那么value保存的就是一个压缩列表对象,RDB文件保存这种对象的方法是:

  • 将压缩列表转换成一个字符串对象。

  • 将转换所得的字符串对象保存到RDB文件。

如果程序在读人RDB文件的过程中,碰到由压缩列表对象转换成的字符串对象,那么程序会根据7YPEF值的指示,执行以下操作:

  • 读人字符串对象,并将它转换成原来的压缩列表对象。
  • 根据7YPE的值,设置压缩列表对象的类型:如果TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST,那么压缩列表对象的类型为列表;如果TYXPE的值为REDIS_RDB_TYPE_HASH_ZIPLIST,那么压缩列表对象的类型为哈希表;如果TYPE的值为RRDIS_RDR_TYPE_ZST_ZIPLIST,那么压缩列表对象的类型为有序集合。

从步骤2可以看出,由于TYPE的存在,即使列表、哈希表和有序集合三种类型都使用压缩列表来保存,RDB读入程序也总可以将读人并转换之后得出的压缩列表设置成原来的类型。

------ 本文结束------