本文内容均来自《Redis设计与实现》一书
数据库状态:Redis是一个键值对数据库服务器,服务器中通常包含着任意个非空数据库,而每个非空数据库中又可以包含任意个键值对,我们将服务器中的非空任意数据库以及它们的键值对统称为数据库状态。
1. 抛砖引玉
因为Redis是内存数据库,它将自己的数据库状态储存在内存里面,所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面,那么一旦服务器进程退出,服务器中的数据库状态也会消失不见。
为了解决这个问题,Redis提供了RDB持久化功能,这个功能可以将Redis在内存中的数据库状态保存到磁盘里面,避免数据意外丢失。
RDB持久化既可以手动执行,也可以根据服务器配置选项定期执行,该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。
RDB持久化生成的RDB文件是一个经过压缩的二进制文件,通过该文件可以还原生成RDB文件时的数据库状态。
2.RDB文件的创建与载入
RDB文件创建
SAVE和BGSAVE命令可用于生成RDB文件。
- SAVE命令会阻塞Redis服务器进程,知道RDB文件创建完成为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。
- BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程继续处理命令请求。
创建RDB文件的实际工作由rdb.c/rdbSave函数完成,SAVE命令和BGSAVE命令会以不同的方式调用这个函数,相应的伪代码如下:
// SAVE命令
def SAVE() {
// 创建RDB文件
rdbSave()
}
// BGSAVE命令
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文件来还原数据库装态。
RDB文件的载入工作由rdb.c/rdbLoad函数完成。
SAVE命令执行时的服务器状态
当SAVE命令执行时,Redis服务器会被阻塞,所以当SAVE命令正在执行时,客户端发送的所有命令请求都会被阻塞。只有在服务器执行玩SAVE命令、重新开始接受命令请求之后,客户端发送的命令才会被处理。
BGSAVE命令执行时的服务器状态
因为BGSAVE命令的工作是由子进程完成的,所以在子进程创建RDB文件的过程中,Redis服务器仍然可以继续处理客户端的命令请求。但是BGSAVE命令在执行期间,服务器器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会有所不同:
- 在BGSAVE命令执行期间,客户端发送的SAVE命令会被服务器拒绝,服务器禁止SAVE和BGSAVE命令同时执行是为了避免服务器进程和子进程同时执行两个rdbSave调用,防止产生竞争条件。
- 在BGSAVE命令执行期间,客户端发送的BGSAVE命令会被服务器拒绝,因为同时执行两个BGSAVE命令也会产生竞争条件。
- BGSAVE和BGREWRITEAOF两个命令也不能同时执行。如果BGSAVE命令正在执行,那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行。如果BGREWRITEAOF命令正在执行,那么客户端发送的BGSAVE命令会被服务器拒绝
RDB文件载入时的服务器状态
服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止。
3.自动间隔性保存
因为BGSAVE命令可以在不阻塞服务器进程的情况下执行,所以Redis允许用户通过设置服务器配置的save选项,让服务器每隔一段时间自动执行一次BGSAVE命令。
设置保存条件
当Redis服务器启动时,用户可以通过指定配置文件或者传入启动参数的方式设置save选项,如果用户没有主动设置save选项,那么服务器会为save选项设置默认条件:
- save 900 1 (服务器在900秒之内,对数据库进行了至少1次修改)
- save 300 10 (服务器在300秒之内,对数据库进行了至少10次修改)
- save 60 10000 (服务器在60秒之内,对数据库进行了至少10000次修改)
服务器会根据save选项所设置的保存条件,设置服务器状态redisServer结构的saveparams属性;saveparams属性是一个数组,数组中的每个元素都是一个saveparam结构,每个saveparam结构都保存了一个save选项设置的保存条件。
struct redisServer {
// ······
// 记录了保存条件的数组
struct saveparam *saveparams;
// ······
};
struct saveparam {
// 秒数
time_t seconds;
// 修改数
int changes;
}
服务器状态中的保存条件 :
dirty计数器和lastsave属性
除了saveparams数组之外,服务器状态还维持着一个dirty计数器,以及一个lastsave属性:
- dirty计数器:记录距离上一次成功执行SAVE命令或者BGSAVE命令之后,服务器对数据库状态(所有的数据库)进行了多少次修改(写入、删除、更新等操作)。
- lastsave属性:是一个UNIX时间戳,记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间。
当服务器成功执行一次数据库修改命令之后,程序就会对dirty计数器进行更新,命令修改了多少次数据库,dirty计数器的值就增加多少。
检查保存条件是否满足
Redis的服务器周期性操作函数serverCron默认每隔100毫秒就会执行一次,该函数用于对正在运行的服务器进行维护,它的其中一项检查工作就是检查save选项所设置的保存条件是否已经满足,如果满足的话,就执行BGSAVE命令。
伪代码
程序会遍历并检查saveparams数组中的所有保存条件,只要由任意一个条件被满足,那么服务器就会执行BGSAVE命令。
def serverCron {
// ······
// 遍历所有保存条件
for saveparam in saveparams :
// 计算距离上次执行保存操作由多少秒
save_interval = unixtime_now() - server.lastsave
// 如果数据库状态的修改次数超过条件所设置的次数,并且距离上次保存的时间超过条件所设置的时间,那么执行保存操作
if server.dirty >= saveparam.changes and save_interval > saveparam.seconds :
BGSAVE()
// ······
}
4.RDB文件结构
为了区分变量、数据、常量,全大写表示常量,全小写表示变量和数据。
结构
REDIS:长度5字节,保存着“REDIS”五个字符。通过这五个字符,程序在载入文件时,快速检查所载入的文件是否是RDB文件。注意:RDB保存的是二进制数据,而不是C字符串,所以不是以‘\0’结尾的C字符串。
db_version:长度4字节,它的值是一个字符串表示的整数,这个整数记录了RDB文件的版本号。
database:包含零个或任意个数据库,以及数据库中的键值对数据。如果服务器的数据库状态为空,那么这个部分也为空,长度为0字节;如果服务器的数据库状态为非空,那么这个部分也为非空,根据数据库所保存键值对的数量、类型和内容不同,这部分的长度也会有所不同。
EOF:长度1字节,标志着RDB文件正文内容结束,当读入程序遇到这个值的时候,它就知道所有数据库的所有键值对都已经载入完毕。
check_sum:长度8字节,无符号整数。保存着一个校验和,这个校验和是程序通过对REDIS、db_version、database、EOF四个部分的内容进行计算得出的。服务器在载入RDB文件时,会将载入数据计算出的校验和与check_sum所记录的校验和进行对比,以此来检查RDB文件是否有出错或者损坏的情况。
database部分
一个RDB文件的database部分可以保存任意多个非空数据库。
带有两个非空数据库的RDB文件示例
RDB文件数据库的结构
SELECTDB:长度1字节,当读入程序遇到这个值时,它知道接下来要读入的将是一个数据库号码。
db_number:保存着一个数据库号码,根据号码的大小不同,这个部分的长度可以是1字节、2字节或者5字节。当程序读入db_number部分之后,服务器会调用SELECT命令,根据读入的数据库号码进行数据库切换,使得之后读入的键值对可以载入到正确的数据库中。
key_value_pairs:保存了数据库中的所有键值对数据,如果键值对带有过期时间,那么过期时间也会和键值对保存在一起。根据键值对的数量、类型、内容以及是否有过期时间等条件的不同,key_value_pairs部分的长度也会有所不同。
RDB文件中的数据库结构示例
key_value_pairs部分
RDB文件中的每个key_value_pairs部分都保存了一个或者以上数量的键值对,如果键值对带有过期时间的话,那么键值对的过期时间也会被保存在内。
带过期时间(左)和不带过期时间(右)的键值对示例
EXPIRETIME_MS:长度1字节的常量,它告知读入程序,接下来要读入的将是一个以毫秒为单位的过期时间。
ms:长度8字节的带符号整数,记录一个以毫秒为单位的UNIX时间戳,这个时间戳就是键值对的过期时间。
TYPE:长度1字节的常量,记录了value的类型。每个TYPE常量代表一种对象类型或者底层编码,当程序读到RDB文件中的键值对数据时,程序会根据TYPE的值来决定如何读入和解释value的数据。
key:总是一个字符串对象,它的编码方式和REDIS_RDB_TYPE_STRING类型的value一样。根据内容长度的不同,key的长度也会有所不同。
value:根据TYPE类型的不同,以及保存内容长度的不同,保存value的结构和长度也会有所不同。
TYPE常量
- 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
value的编码--字符串对象
TYPE的值为REDIS_RDB_TYPE_STRING,那么value保存的就是一个字符串对象,字符串对象的编码可以时REDIS_ENCODING_INT或者REDIS_ENCODING_RAW。
如果字符串对象的编码是REDIS_ENCODING_INT,那么说明对象中保存的是长度不超过32位的整数。其中ENCODING的值可以是REDIS_RDB_ENC_INT8、REDIS_RDB_ENC_INT16、REDIS_RDB_ENC_INT32三个常量中的一种,它们分别代表RDB文件使用8位、16位、32位来保存整数值integer。
如果字符串对象的编码是REDIS_ENCODING_RAW,那么说明对象所保存的是一个字符串值,根据字符串长度的不同,有压缩和不压缩两种方法来保存这个字符串:
- 如果字符串的长度小于等于20字节,那么这个字符串会直接被原样保存。
- 如果字符串的长度大于20字节,那么这个字符串会被压缩之后再保存。
注意:以上两个条件是在假设服务器打开了RDB文件压缩功能的情况下进行的,如果服务器关闭了RDB文件压缩功能,那么RDB程序总以无压缩的方式保存字符串值。(具体配置参考rdbcompression选项)
无压缩字符串结构和示例
len:字符串值得长度。
string:字符串本身。
压缩字符串结构和示例
REDIS_RDB_ENC_LZF:表示字符串已经被LZF算法压缩过,读入程序在碰到这个常量时,会根据之后的compressed_len、origin_len和compressed_string三部分,对字符串进行解压缩。
compressed_len:记录字符串被压缩之后的长度。
origin_len:记录字符串原始的长度。
compressed_string:记录被压缩之后的字符串。
value的编码--列表对象
TYPE的值为REDIS_RDB_TYPE_LIST,那么value保存的就是一个REDIS_ENCODING_LINKEDLIST编码的列表对象。
结构和示例
list_length:记录了列表的长度,它记录了列表保存了多少个项(item),读入程序可以通过这个长度知道自己应该读入多少个列表项。
itemX:表示列表的项。因为每个列表项都是一个字符串对象,所以程序会以处理字符串对象的方式来保存和读入列表项。
value的编码--集合对象
TYPE的值为REDIS_RDB_TYPE_SET,那么value保存的就是一个REDIS_ENCODING_HT编码的集合对象。
结构和示例
set_size:记录集合的大小,它记录了集合保存了多少个元素(elem),读入程序可以通过这个大小知道自己应该读入多少个集合元素。
elemX:表示集合的元素。因为每个集合元素是一个字符串对象,所以程序会以处理字符串对象的方式来保存和读入集合元素。
value的编码--哈希对象
TYPE的值为REDIS_RDB_TYPE_HASH,那么value保存的就是一个REDIS_ENCODING_HT编码的集合对象。
结构和示例
hash_size:记录了哈希表的大小,也即是这个哈希表保存了多少键值对,读入程序可以通过这个大小知道自己应该读入多少个键值对。
keyX和valueX:代表哈希表中的键值对,每个键值对都以键(keyX)紧挨着值(valueX)的方式排列在一起的,键值对的键(keyX)和值(valueX)都是字符串对象,所以程序会以处理字符串对象的方式来保存和读入键值对。
value的编码--有序集合对象
TYPE的值为REDIS_RDB_TYPE_ZSET,那么value保存的就是一个REDIS_ENCODING_SKIPLIST编码的有序集合对象。
结构和示例
sorted_set_size:记录了有序集合的大小,也即是这个有序集合保存了多少元素,读入程序可以通过这个大小知道自己应该读入多少个有序集合元素。
memberX和scoreX:代表有序集合中的元素,每个元素分为成员(memberX)和分值(scoreX)两部分,成员是一个字符串对象,分值是一个浮点数,程序会先将分值转化成字符串对象,然后再用保存字符串对象的方法将分值保存起来。
value的编码--INTSET编码的集合
TYPE的值为REDIS_RDB_TYPE_SET_INTSET,那么value保存的就是一个整数集合对象。
RDB保存整数集合对象的方法是,向将整数集合转换成字符串对象,然后将这个字符串对象保存到RDB文件里面。
如果程序在读入RDB文件的过程中,碰到由整数集合对象转换成的字符串对象,那么程序会根据TYPE值的指示,先读入字符串对象,再将这个字符串对象转换为原来的整数集合。
value的编码--ZIPLIST编码的列表、哈希表或者有序集合
TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST、REDIS_RDB_TYPE_ZSET_ZIPLIST或者REDIS_RDB_TYPE_HASH_ZIPLIST,那么value保存的就是一个压缩列表对象。
RDB文件保存这种对象的方法是:
- 将压缩列表转换为一个字符串对象。
- 将转换所得的字符串对象保存到RDB文件种。
当程序在读入RDB文件的过程中,碰到由压缩列表对象转换成的字符串对象,那么程序会根据TYPE值得指示,执行以下操作:
- 读入字符串对象,并将它转换成原来得压缩列表对象。
- 根据TYPE的值,设置压缩列表对象的类型:如果TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST,那么设置压缩列表对象的类型为列表;如果TYPE的值为REDIS_RDB_TYPE_ZSET_ZIPLIST,那么设置压缩列表对象的类型为有序集合;如果TYPE的值为REDIS_RDB_TYPE_HASH_ZIPLIST,那么设置压缩列表对象的类型为哈希表。