RDB文件结构
在Redis实现之RDB持久化（一）这一章中，我们介绍了Redis服务器保存和载入RDB文件的方法，在这一节，我们将对RDB文件本身进行介绍，并详细说明文件各个部分的结构和意义。图1-10展示了一个完整的RDB文件所包含的各个部分
图1-10 RDB文件结构
为了方便区分变量、数据、常量，图1-10中用全大写单词标识常量，用全小写标识变量和数据
RDB文件的最开头是Redis部分，这个部分的长度为5字节，保存着"REDIS"五个字符。通过这五个字符，程序可以在载入文件时，快速检查所载入的文件是否是RDB文件。因为RDB文件保存的是二进制数据，而不是C字符串，为了简单起见，我们用"REDIS"符号代表'R'、'E'、'D'、'I'、'S'五个字符，而不是待' '结尾符号的C字符串'R'、'E'、'D'、'I'、'S'、' '
db_version长度为4字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件的版本号，比如"0006"就代表RDB文件的版本为第六版
databases部分包含着零个至任意多个数据库以及各个数据库中的键值对数据：
- 如果服务器的数据库状态为空（所有数据库都是空的），那么这个部分也为空，长度为0字节
- 如果服务器的数据库状态为非空（有至少一个数据库非空），那么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容的不同，这个部分的长度也会有所不同
EOF常量的长度为1字节，这个常量标志着RDB文件正文内容结束，当读入程序遇到这个值的时候，它知道所有数据库的所有键值对都已加载完毕
check_num是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序通过对REDIS、db_version、databases、EOF四部分的内容进行计算得出的。服务器在载入RDB文件时，会将载入数据所计算出的校验和与check_num所记录的校验和进行对比，以此来检查RDB文件是否有出错或者损坏的情况出现
作为例子，图1-11展示了一个databases部分为空的RDB文件：文件开头的"REDIS"表示这是一个RDB文件，之后的"0006"表示这是第六版的RDB文件，因为databases为空，所以版本号之后直接跟着EOF常量，最后的6265312314761917404是文件的校验和
图1-11 databases部分为空的RDB文件
databases部分
一个RDB文件的databases部分可以保存任意多个非空数据库。例如，如果服务器的0号数据库和3号数据库非空，那么服务器将创建一个如图1-12所示的RDB文件，图中的databases 0代表0号数据库的所有键值对数据，而databases 3则代表3号数据库中所有键值对数据
图1-12 带有两个非空数据库的RDB文件示例
每个非空数据库在RDB文件中都可以保存为SELECTDB、db_number、key_value_pairs三个部分，如图1-13所示
图1-13 RDB文件这种的数据库结构
SELECTDB常量的长度为1字节，当读入程序遇到这个值的时候，它知道接下来要读入的将是一个数据库号码
db_number保存着一个数据库号码，根据号码的大小不同，这个部分的长度可以是1字节、2字节或者5字节。当程序读入db_number部分之后，服务器会调用SELECT命令，根据读入的数据库号码进行数据库切换，使得之后读入的键值对可以载入到正确的数据库中
key_value_pairs部分保存了数据库中的所有键值对数据，如果键值对带有过期时间，那么过期时间也会和键值对保存在一起。根据键值对的数量、类型、内容以及是否有过期时间等条件不同，key_value_pairs部分的长度也会有所不同。作为例子，图1-14展示了RDB文件中，0号数据库的结构
图1-14 数据库结构示例
另外，图1-15则展示了一个完成的RDB文件，文件包含了0号数据库和3号数据库
图1-15 RDB文件中的数据库结构示例
key_value_pairs部分
RDB文件中的每个key_value_pairs部分都保存了一个以上的键值对，如果键值对带过期时间的话，那么键值对的过期时间也会被保存在内。不带过期时间的键值对在RDB文件中由TYPE、key、value三部分组成，如图1-16所示
图1-16 不带过期时间的键值对
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一样。根据内容长度的不同，key的长度也会有所不同
- 根据TYPE类型的不同，以及保存内容长度的不同，保存value的结构和长度也会有所不同，稍后还会详细说明每种TYPE类型的value结构保存方式
带有过期时间的键值对在RDB文件中的结构如图1-17所示
图1-17 带有过期时间的键值对
带有过期时间的键值对中的TYPE、key、value三个部分的意义，前面介绍的不带过期时间的键值对的TYPE、key、value三个部分的意义完全相同，至于新怎的EXPIRETIME_MS和ms，它们的意义如下：
- EXPIRETIME_MS常量的长度为1字节，它告知读入程序，接下来要读入的将是一个以毫秒为单位的过期时间
- ms是一个8字节长的带符号整数，记录着一个以毫秒为单位的Unix时间戳，这个时间戳就是键值对的过期时间
作为例子，图1-18展示了一个没有过期时间的字符串键值对
图1-18 无过期时间的字符串键值对示例
图1-19展示了一个带有过期时间的集合键值对，其中键的过期时间为138855600000（2014年1月1日零时）
图1-19 带有过期时间的集合键值对示例
value编码
RDB文件中的每个中的每个value部分都保存了一个值对象，每个值对象的类型都由与之对应的TYPE记录，根据类型的不同，value部分的结构，长度也会有所不同。在接下来的各个小节中我们将分别介绍不同类型的值对象在RDB文件中的保存结构
字符串对象
如果TYPE的值REDIS_RDB_TYPE_STRING，那么value保存的就是一个字符串对象，字符串对象的编码可以是REDIS_ENCODING_INT或REDIS_ENCODING_RAW。如果字符串对象对象，字符串对象的为REDIS_ENCODING_INT，那么说明对象中保存的是长度不超过32位的整数，这种编码的对象将以图1-20所示的结构保存
图1-20 INT编码字符串对象的保存结构
其中，ENCODING的值可以是REDIS_ENCODING_INT8、REDIS_ENCODING_INT16或者REDIS_ENCODING_INT32三个常量的其中一个，它们分别代表RDB文件使用8位（bit）、16位、32位来保存整数值integer
举个栗子，如果字符串对象中保存的是可以用8位来保存的整数123，那么这个对象在RDB文件中保存的结构将如图1-21所示
图1-21 用8位来保存整数的例子
如果字符串对象的编码为REDIS_ENCODING_RAW，那么说明对象所保存的是一个字符串值，根据字符串长度的不同，有压缩和不压缩两种方法来保存这个字符串：
- 如果字符串的长度小于等于20字节，那么这个字符串会直接被原样保存
- 如果字符串的长度大于20字节，那么这个字符串会被压缩之后再保存
以上两个条件是假设服务器打开了RDB文件压缩功能的情况下进行的，如果服务器关闭了RDB文件压缩功能，那么RDB总以无压缩的方式保存字符串值。具体信息可以参考redis.conf文件中关于rdbcompression选项说明
对于没有被压缩的字符串，RDB程序会以图1-22所示的结构来保存该字符串
图1-22 无压缩字符串的保存结构
其中，string部分保存了字符串值本身，而len保存了字符串值的长度。对于压缩后的字符串，RDB程序会以图1-23所示的结构来保存该字符串
图1-23 压缩后字符串的保存结构
其中，RDDIS_RDB_ENC_LZF常量标识着字符串已经被LZF算法压缩过，读入程序在碰到这个常量时，会根据之后的compressed_len、origin_len和compressed_string三部分，对字符串进行解压缩：其中compressed_len记录的是字符串被压缩后的长度，而origin_len记录的是字符串原来的长度，compressed_string记录的是被压缩后的字符串
图1-24展示了一个保存无压缩字符串的例子，其中字符串长度为5，字符串的值为"hello"
图1-24 无压缩字符串
图1-25展示了一个压缩后的字符串示例，从图中可以看出，字符串原本的长度为21，压缩后的长度为6，压缩之后的字符串内容为"？aa???"，其中?代表的是无法用字符串形式打印出来的字节
图1-25 压缩后的字符串
列表对象
如果TYPE的值为REDIS_RDB_TYPE_LIST，那么value保存的就是一个REDIS_ENCODING_LINKEDLIST编码的列表对象，RDB文件保存这种对象的结构如图1-26所示
图1-26 LINKEDLIST编码列表对象的保存结构
list_length记录了列表的长度，它记录列表保存了多少个项（item），读入程序可以通过这个长度知道自己应该读入多少个列表项。图中以item开头的部分代表列表的项，因为每个列表项都是一个字符串对象，所以程序会以处理字符串对象的方式来保存和读入列表项
作为示例，图1-27展示了一个包含三个元素的列表
图1-27 保存LINKEDLIST编码列表的例子
结构中的第一个数字3是列表的长度，之后跟着的分别是第一个列表项、第二个列表项和第三个列表项，其中：
- 第一个列表项的长度是5，内容为字符串"hello"
- 第二个列表项的长度也是5，内容为字符串"world"
- 第三个列表项的长度为1，内容为字符串"!"
集合对象
如果TYPE的值为REDIS_RDB_TYPE_SET，那么value保存的就是一个REDIS_ENCODING_HT编码的集合对象，RDB文件保存这种对象的结构如图1-28所示
图1-28 HT编码集合对象的保存结构
其中，set_size是集合的大小，它记录了集合保存了多少个元素，读入程序可以通过这个大小知道自己应该读入多少个集合元素。图中以elem开头的部分代表集合的元素，因为每个集合元素都是一个字符串对象，所以程序会以处理字符串对象的方式来保存和读入集合元素
作为示例，图1-29展示了一个包含四个元素的集合
图1-29 保存HT编码集合的例子
结构中的第一个数字4记录了集合的大小，之后跟着的是集合的四个元素：
- 第一个元素的长度是5，值为"apple"
- 第二个元素的长度是6，值为"banana"
- 第三个元素的长度是3，值为"cat"
- 第四个元素的长度是3，值为"dog"
哈希表对象
如果TYPE的值为REDIS_RDB_TYPE_HASH，那么value保存的就是一个REDIS_ENCODING_HT编码的集合对象，RDB文件保存这种对象的结构如图1-30所示：
- hash_size记录了哈希表的大小，也即是这个哈希表保存了多少键值对，读入程序可以通过这个大小知道自己应该读入多少个键值对
- 有key_value_pair开头的部分代表哈希表的键值对，键值对的键和值都是字符串对象，所以程序会以处理字符串对象的方式来保存和读入键值对
图1-30 HT编码哈希表对象的保存结构
结构中的每个键值对都以键紧挨着值的方式排列在一起，如图1-31所示
图1-31 键值对的保存结构
因此，从更详细的角度看，图1-30所展示的结构可以进一步修改为图1-32
图1-32 更详细的HT编码哈希表对象的保存结构
作为图例，图1-33展示了一个包含两个键值对的哈希表
图1-33 保存HT编码的哈希表例子
有序集合对象
如果TYPE的值为REDIS_RDB_TYPE_ZSET，那么value保存的就是一个REDIS_ENCODING_SKIPLIST编码的有序集合对象，RDB文件保存这种对象的结构如图1-34所示
图1-34 SKIPLIST编码有序集合对象的保存结构
sorted_set_size记录了有序集合的大小，也即是这个有序集合保存了多少个元素，读入程序需要根据这个值来决定应该读入多少个有序集合元素。以element开头的部分代表有序集合中的元素，每个元素又分为成员（member）和分值（score）两部分，成员是一个字符串对象，分值则是一个double类型的浮点数，程序在保存RDB文件时会先将分值转换成字符串对象，然后再用保存字符串对象的方法将分值保存起来
有序集合中的每个元素都以成员紧挨着分值的方式排列，如图1-35所示
图1-35 成员和分值的保存结构
因此，从详细的角度来看，图1-34所展示的结构可以进一步修改为图1-36
图1-36 更详细的SKIPLIST编码有序集合对象的保存结构
作为示例，图1-37展示了一个带有两个元素的有序集合
图1-37 保存SKIPLIST编码有序集合的例子
在这个示例结构中，第一个数字2记录了有序集合的元素数量，之后跟着的是两个有序集合元素：
- 第一个元素的成员是长度为2的字符串"pi"，分值被转换成字符串之后变成了长度为4的字符串"3.14"
- 第一个元素的成员是长度为1的字符串"e"，分值被转换成字符串之后变成了长度为3的字符串"2.7"
INTSET编码的集合
如果TYPE的值为REDIS_RDB_TYPE_SET_INTSET，那么value保存的就是一个整数集合对象，RDB文件保存这种对象的方法是，先将整数集合转换成字符串对象，然后将这个字符串对象保存到RDB文件里面。如果程序在读入RDB文件的过程中，碰到由整数集合对象转换成的字符串对象，那么程序会根据TYPE值的指示，先读入字符串对象，再将这个字符串对象转换成原来的整数集合对象
ZIPLIST编码的列表、哈希表或有序集合
如果TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST、REDIS_RDB_TYPE_HASH_ZIPLIST或REDIS_RDB_TYPE_ZSET_ZIPLIST，那么value保存的就是一个压缩列表对象，RDB文件保存这种对象的方法是：
- 将压缩列表转换成一个字符串对象
- 将转换所得得字符串对象保存到RDB文件中
如果程序在读入RDB文件的过程中，碰到由压缩列表对象转换成的字符串对象，那么程序会根据TYPE值的指示，执行以下操作：
- 读入字符串对象，并将它转换成原来的压缩列表对象
- 根据TYPE的值，设置压缩列表对象的类型：如果TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST，那么压缩列表对象的类型为列表；如果TYPE的值为REDIS_RDB_TYPE_HASH_ZIPLIST，那么压缩列表对象的类型为哈希表；如果TYPE的值为REDIS_RDB_TYPE_ZSET_ZIPLIST，那么压缩列表对象的类型为有序集合
从步骤2可以看出，由于TYPE的存在，即使列表、哈希表和有序集合三种类型都使用压缩列表来保存，RDB读入程序也总可以将读入并转换之后得出的压缩列表设置为原来的类型
分析RDB文件
通过上一节对RDB文件的介绍，我们现在应该对RDB文件中的各个内容和结构有一定的了解了，是时候抛开单纯的图片示例，开始分析和观察一下实际的RDB文件了
我们使用od命令来分析Redis服务器产生的RDB文件，该命令可以用给定的格式转存（dump）并输入文件。比如说，给定-c参数可以以ASCII编码的方式打印输入文件，给定-x参数可以以十六进制的方式打印输出文件
不包含任何键值对的RDB文件
让我们从最简单的情况开始，执行以下命令，创建一个数据库状态为空的RDB文件
127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> 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"字符串
- 四字节的版本号（db_version）
- 一字节的EOF常量
- 八字节的校验和（check_num）
从od命令的输出中可以看到，最开头的是"REDIS"字符串，之后的0006是版本号，再之后的一个字节377代表EOF常量，最后的334 263 C 360 Z 334 362 V八字节则代表RDB文件的校验和
包含字符串键的RDB文件
这次我们来分析下一个带有单个字符串键的数据库：
127.0.0.1:6379＞ FLUSHALL OK 127.0.0.1:6379＞ SET MSG "HELLO" OK 127.0.0.1:6379＞ SAVE OK
再次执行od命令：
# od -c dump.rdb 0000000 R E D I S 0 0 0 6 376 003 M S G 0000020 005 H E L L O 377 207 z = 304 f T L 343 0000037
根据之前学习的数据库结构知识，当一个数据库被保存到RDB文件时，这个数据库将由以下三部分组成：
- 一个一字节长的特殊值SELECTDB
- 一个长度可能为一字节、两字节或者五字节的数据库号码（db_number）
- 一个或以上数量的键值对（key_value_pairs）
观察od命令打印的输出，RDB文件的最开始仍然是REDIS和版本号0006，之后出现的376代表SELECTDB常量，再之后的 代表整数0，表示被保存的数据库为0号数据库。在数据库号码之后，直到代表EOF常量的377为止，RDB文件包含有以下内容：
003 M S G 005 H E L L O
根据之前学习的键值对结构知识，在RDB文件中，没有过期时间的键值对由类型（TYPE）、键（key）、值（value）三部分组成：其中类型的长度为一字节，键和值都是字符串对象，并且字符串在未被压缩前，都是以字符串长度为前缀，后跟字符串内容本身的方式来储存的。根据这些特征，我们可以确定 就是字符串类型的TYPE值REDIS_RDB_TYPE_STRING（这个常量的实际值为整数0），之后的003是键MSG的长度值，再之后的005则是值HELLO的长度
包含带有过期时间的字符串键的RDB文件
现在，让我们来创建一个带有过期时间的字符串键：
127.0.0.1:6379＞ FLUSHALL OK 127.0.0.1:6379＞ SETEX MSG 10086 "HELLO" OK 127.0.0.1:6379＞ SAVE OK
打印RDB文件：
# od -c dump.rdb 0000000 R E D I S 0 0 0 6 376 374 2 365 336 0000020 @ 001 003 M S G 005 H E L L O 377 0000040 212 231 x 247 252 } 021 306 0000050
根据之前学习的键值对结构知识，一个带有过期时间的键值对将由以下部分组成：
- 一个一字节长的EXPIRETIME_MS特殊值
- 一个八字节长的过期时间（ms）
- 一个一字节长的类型（TYPE）
- 一个键（key）和一个值（value）
根据这些特征，可以得出RDB文件各个部分的意义：
- REDIS0006：RDB文件标志和版本号
- 376 ：切换到0号数据库
- 374：代表特殊值EXPIRETIME_MS
- 2 365 336 @ 001 ：代表八字节长的过期时间
- 0 003 M S G： 表示这是一个字符串键，003是键的长度，MSG是键
- 005 H E L L O：005是值的长度，HELLO是值
- 377：代表EOF常量
- 212 231 x 247 252 } 021 306：代表八字节长的校验和
包含一个集合键的RDB文件
最后，让我们试试在RDB文件中包含集合键：
127.0.0.1:6379＞ FLUSHALL OK 127.0.0.1:6379＞ SADD LANG "C" "JAVA" "RUBY" (integer) 3 127.0.0.1:6379＞ SAVE OK
打印输出如下：
# od -c dump.rdb 0000000 R E D I S 0 0 0 6 376 002 004 L A N 0000020 G 003 004 R U B Y 004 J A V A 001 C 377 202 0000040 312 r 352 346 305 * 023 0000047
以下是RDB文件各个部分的意义：
- REDIS0006：RDB文件标志和版本号
- 376 ：切换到0号数据库
- 002 004 L A N G：002是常量REDIS_RDB_TYPE_SET（这个常量的实际值为整数2），表示这是一个哈希表编码的集合键，004表示键的长度，LANG是键的名字
- 003：集合的大小，说明这个集合包含三个元素
- 004 R U B Y：集合的第一个元素
- 004 J A V A：集合的第二个元素
- 001 C：集合的第三个元素
- 377：代表常量EOF
- 202 312 r 352 346 305*023：代表校验和
关于分析RDB文件的说明
因为Redis本身带有RDB文件检查工具redis-check-dump，网上也能找到很多处理RDB文件的工具，所以人工分析RDB文件的内容并不是学习Redis所必须掌握的技能。不过从学习RDB文件的角度来看，人工分析RDB文件是一个不错的练习，这种练习可以帮助我们熟悉RDB文件的结构和格式
最后要提醒的是，前面我们一直用od命令配合-c参数来打印RDB文件，因为使用ASCII编码打印RDB文件可以很容易地发现文件中的字符串内容。但是，对于RDB文件中的数字值，比如校验和来说，通过ASCII编码来打印它并不容易看出它的真实值，更好的办法是使用-cx参数调用od命令，同时以ASCII编码和十六进制格式打印RDB文件：
# od -cx dump.rdb 0000000 R E D I S 0 0 0 6 377 334 263 C 360 Z 334 4552 4944 3053 3030 ff36 b3dc f043 dc5a 0000020 362 V 56f2 0000022
现在可以从输出中看出，RDB文件的校验和为0x 56f2 dc5a f043 b3dc（校验和以小端方式保存），这比用ASCII编码打印出来的334 263 C360 Z 334 362 V要清晰得多，后者看起来就像乱码一样