RDB持久化解析
redis提供了rdb持久化，这个功能可以将redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。
因为RDB文件是保存在硬盘里面的，所以即使redis服务器进程退出，甚至运行redis服务的计算机宕机，但只要rdb文件仍然存在，redis服务器就可以用它来还原数据库状态。
1.1 RDB文件的创建与载入
有两个redis命令可以用来生成rdb文件，一个是SAVE，另一个是BGSAVE；
save命令会阻塞redis服务器进程，直到rdb文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求；
和save命令直接阻塞服务器进程的做法不同，bgsave命令会派生一个子进程，然后由子进程负责创建rdb文件，服务器进程继续处理命令请求
创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数
值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：
- 如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态
- 只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态
载入RDB文件的实际工作由rdb.c/rdbLoad函数完成，这个函数和rdbSave函数之间的关系可以如下表示：
1.1.1 SAVE命令执行时的服务器状态
执行SAVE命令时，服务器会被阻塞
1.1.2 BGSAVE命令执行时的服务器状态
因为BGSAVE命令的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，redis服务器可以继续处理客户端的命令请求，但是，有BGSAVE命令执行期间，服务器处理SAVE，BGSAVE，BGREWRITEAOF三个命令的方式会和平时有所不同
首先，在BGSAVE命令执行期间，客户端发送的BGSAVE命令会被服务器拒绝，因为同时执行两个BGSAVE命令也会产生竞争条件
最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行：
- 如果
BGSAVE命令正在执行，那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行 - 如果
BGREWRITEAOF命令正在执行，那么客户端发送的BGSAVE命令会被服务器拒绝
1.1.3 RDB文件载入时的服务器状态
服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止
1.2 自动间隔性保存
用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令
1.2.1 设置保存条件
当redis服务器启动时，用户可以通过指定配置文件或者传入启动参数的方式设置save选项，如果用户没有主动设置save选项，那么服务器会为save选项设置默认条件：
save 900 1
# 900秒之内，对数据库进行了至少1次修改
save 300 10
# 300秒之内，对数据库进行了至少10次修改
save 60 10000
# 60秒之内，对数据库进行了至少10000次修改
接着，服务器程序会根据save选项所设置的保存条件，设置服务器状态redisServer结构的saveparams属性：
struct redisServer{
// ...
// 记录了保存条件的数组
struct saveparam *saveparams;
// ...
};
saveparams属性是一个数组，数组中的每个元素都是一个saveparam结构，每个saveparam结构都保存了一个save选项设置的保存条件：
struct saveparam{
// 秒数
time_t seconds;
// 修改数
int changes;
}
1.2.2 dirty计数器和lastsave属性
dirty计数器记录距离上一次成功执行save命令或者bgsave命令之后，服务器对数据库状态进行了多少次修改
lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行save命令或者bgsave命令的时间
struct redisServer{
// 修改计数器
long long dirty;
// 上一次执行保存的时间
time_t lastsave;
};
当服务器成功执行一个数据库修改命令之后，程序就会对dirty计数器进行更新：命令修改了多少次数据库，dirty计数器的值就增加多少
1.2.3 检查保存条件是否满足
redis服务器周期性操作函数serverCron默认间隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行bgsave
1.3 RDB文件结构
RDB文件开头是REDIS部分，这个部分的长度是5字节，保存着“REDIS”五个字符。通过这五个字符，程序可以在载入文件时，快速检查所载入的文件是否RDB文件。
db_version长度为4字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件的版本号，比如“0006”就代表RDB文件的版本为第六版。
databases部分包含着零个或任意多个数据库，以及各个数据库中的键值对数据：
- 如果服务器的数据库状态为空，那么这个部分也为空，长度为0字节
- 如果服务器的数据库状态为非空，那这个部分就非空
EOF常量的长度为1字节，这个常量标志着RDB文件正文内容的结束，当读入程序遇到这个值的时候，他知道所有数据库的所有键值对都已经载入完毕了。
check_num是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序对redis，db_version,databases,EOF四个部分的内容进行计算得出的。服务器在载入RDB文件时，会将载入数据所计算出的检验和与check_sum所记录的检验和进行对比，以此来检查RDB文件是否有出错或者损坏的情况出现。
1.3.1 databases部分
一个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部分的长度也会有所不同
1.3.2 key_value_pairs部分
RDB文件中的每个key_value_pairs部分都保存了一个或以上数量的键值对，如果键值对带有过期时间的话，那么键值对的过期时间也会被保存在内
不带过期时间的键值对在RDB文件中由TYPE,KEY,VALUE三部分组成
TYPE记录了value的类型，长度为1字节，值可以是以下常量的其中一个：
- 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_RDB_TYPE_STRING类型的value一样 - 根据type类型的不同，以及保存内容长度的不同，保存value的结构和长度也会有所不同
带有过期时间的键值对在RDB文件中的结构如图：
EXPIRETIME_MS常量的长度为1字节，它告知读入程序，接下来要读入的将是一个以毫秒为单位的过期时间ms是一个8字节长的带符号整数，记录着一个以毫秒为单位的UNIX时间戳，这个时间戳就是键值对的过期时间
1.3.3 value的编码
RDB文件中的每个value部分都保存了一个值对象，每个值对象的类型都由与之对应的TYPE记录，根据类型的不同，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字节，压缩保存
无压缩结构：
压缩结构：
采用
LZF算法进行压缩，读入程序在碰到这个常量后，会根据之后的compressed_len记录的是字符串被压缩之后的长度,而origin_len记录的是原长度。 -
列表对象
list_length记录了列表的长度，它记录列表保存了多少个项（item），读入程序可以通过这个长度知道自己应该读入多少个列表项
结构中的一个
数字3是列表的长度，之后跟着的分别是第一个列表项，第二个列表项和第三个列表项- 第一个列表项的长度为5，内容为字符串“hello”
- 如上
-
集合对象
set_size是集合的大小，它记录集合保存了多少个元素。图中以
elem开头的部分代表集合的元素，因为每个集合元素都是一个字符串对象，所以程序会以处理字符串对象的方式来保存和读入集合元素
4代表集合大小，5代表第一个元素的长度
-
哈希对象
hash_size记录了哈希表的大小，也即是这个哈希表保存了多少键值对，读入程序可以通过这个大小知道自己应该读入多少个键值对- 以
key_value_pair开头的部分代表哈希表中的键值对，键值对的键和值都是字符串对象，所以程序会以处理字符串对象的方式来保存和读入键值对
2代表哈希表的键值对数量，1代表键长度为1，值是长度为5的apple
-
有序集合对象
sorted_set_size记录了有序集合的大小，以element开头的部分代表有序集合中的元素，分为成员和分值两部分。
-
INTSET编码的集合
先读入字符串对象，再将这个字符串对象转换成原来的整数集合对象
-
ZIPLIST编码的列表，哈希表或者有序集合
RDB文件保存这种对象的方法：
- 将压缩列表转换成一个字符串对象
- 将转换所得的字符串对象保存到RDB文件
恢复操作：
- 读入字符串对象，并将它转换成原来的压缩列表对象
- 根据TYPE的值，进行不同类型的转换
1.4 分析RDB文件
1.4.1 不包含任何键值对的RDB文件
创建一个数据库状态为空的RDB文件：
redis> FLUSHALL
OK
redis> SAVE
OK
然后调用od命令，打印RDB文件：
$ od -c dump.rdb
0000000 R E D I S 0 0 0 6 377 334 263 C 360 Z 334
0000020 362 v
0000022
根据之前学习的RDB文件结构知识，当一个RDB文件没有包含任何数据库数据时，这个RDB文件由以下四个部分组成：
- 五个字节的REDIS字符串
- 四个字节的版本号：0006
- 一个字节的EOF常量：377
- 八个字节的校验和：334 263 C 360 Z 334 362 V
1.4.2 包含字符串键的RDB文件
首先查看一个示意文件：
- 一个一字节长的特殊值SELECTDB
- 一个长度可能为一字节，两字节或五字节的数据库号码
- 一个或以上数量的键值对
图中：
- 376代表SELECTDB常量，\0代表整数0，表示被保存的数据库为0号数据库
- \0 003 M S G 005 H E L L O： \0代表字符串类型，3代表键的长度，MSG为内容，以此类推
1.4.3 包含带有过期时间的字符串键的RDB文件
查看示意文件：
一个带有过期时间的键值对将由以下部分组成：
- 一个一字节长的EXPIRETIME_MS特殊值
- 一个八字节长的过期时间（ms）
- 一个一字节长的类型（TYPE）
- 一个键和一个值
上述文件中：
- REDIS0006:RDB文件标志和版本号
- 379 \0：切换到0号数据库
- 374：代表特殊值EXPIRETIME_MS
- \ 2 365 336 @ 001 \0 \0：代表八字节长的过期时间
- \0 003 MSG ：字符串键，3是长度，MSG是键
- 同理
- 377：代表EOF常量
- 八字结校验和
1.4.4 包含一个集合键的RDB文件
1.4.5 关于分析RDB文件的说明
redis本身带有RDB文件检查工具redis-check-dump。
扫一扫
330
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
