Redis的RDB持久化

int open(const char *path, int oflag, .../*,mode_t mode */);
int close (int filedes);int remove( const char *fname );
ssize_t write(int fildes, constvoid *buf, size_t nbyte);
ssize_t read(int fildes, void *buf, size_t nbyte);

所以，我们有很好的可用的 API 来完成 第三步，但是对于成功返回之前，我们对系统调用花费的时间没有太多的控制权。

然后我们来说说 第四步。我们知道，除了早期对电脑特别了解那帮人 (操作系统就这帮人搞的)，实际的物理硬件都不是我们能够 直接操作 的，都是通过 操作系统调用 来达到目的的。为了防止过慢的 I/O 操作拖慢整个系统的运行，操作系统层面做了很多的努力，譬如说 上述第四步 提到的 写缓冲区，并不是所有的写操作都会被立即写入磁盘，而是要先经过一个缓冲区，默认情况下，Linux 将在 30 秒 后实际提交写入。

但是很明显，30 秒 并不是 Redis 能够承受的，这意味着，如果发生故障，那么最近 30 秒内写入的所有数据都可能会丢失。幸好 PROSIX API 提供了另一个解决方案：fsync，该命令会强制内核将 缓冲区 写入磁盘，但这是一个非常消耗性能的操作，每次调用都会 阻塞等待 直到设备报告 IO 完成，所以一般在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作。

到目前为止，我们了解到了如何控制 第三步 和 第四步，但是对于 第五步，我们 完全无法控制。也许一些内核实现将试图告诉驱动实际提交物理介质上的数据，或者控制器可能会为了提高速度而重新排序写操作，不会尽快将数据真正写到磁盘上，而是会等待几个多毫秒。这完全是我们无法控制的。

RDB简介

Redis是一个键值对数据库服务器，服务器中通常包含着任意个非空数据库，而每个非空数据库中又可以包含任意个键值对，为了方便起见，我们将服务器中的非空数据库以及它们的键值对统称为数据库状态。

举个例子，图展示了一个包含三个非空数据库的Redis服务器，这三个数据库以及数据库中的键值对就是该服务器的数据库状态。

因为Redis是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。

为了解决这个问题，Redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

快照作为包含整个数据集的单个 .rdb 文件生成。

RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中，如图所示。

RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态，如图所示。

因为RDB文件是保存在硬盘里面的，所以即使Redis服务器进程退出，甚至运行Redis服务器的计算机停机，但只要RDB文件仍然存在，Redis服务器就可以用它来还原数据库状态。

RDB文件的创建与载入

有两个Redis命令可以用于生成RDB文件，一个是SAVE, 另一个是BGSAVE。

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求：

和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求：

创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数，通过以下伪代码可以明显地看出这两个命令之间的区别：

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

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

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

只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。 服务器判断该用哪个文件来还原数据库状态的流程如图所示。

载入RDB文件的实际工作由rdb.c/rdbLoad函数完成，这个函数和rdbSave函数之间的关系可以用图10-5表示。

fork函数

操作系统多进程 COW(Copy On Write) 机制 拯救了我们。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程复制了一个进程，主进程和子进程会共享内存里面的代码块和数据段：

这里多说一点，为什么 fork 成功调用后会有两个返回值呢？ 因为子进程在复制时复制了父进程的堆栈段，所以两个进程都停留在了 fork 函数中 (都在同一个地方往下继续"同时"执行)，等待返回，所以 一次在父进程中返回子进程的 pid，另一次在子进程中返回零，系统资源不够时返回负数。(伪代码如下)

pid = os.fork()
if pid > 0:
  handle_client_request()  # 父进程继续处理客户端请求
if pid == 0:
  handle_snapshot_write()  # 子进程处理快照写磁盘
if pid < 0:
  # fork error

所以 快照持久化 可以完全交给 子进程 来处理，父进程 则继续 处理客户端请求。子进程 做数据持久化，它 不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是 父进程 不一样，它必须持续服务客户端请求，然后对 内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行 数据段页面 的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后 对这个复制的页面进行修改。这时 子进程 相应的页面是 没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化 叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

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

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

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

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文件期间，会一直处于阻塞状态，直到载入工作完成为止。

自动间隔性保存

SAVE命令由服务器进程执行保存工作，BGSAVE命令则由子进程执行保存工作，所以SAVE命令会阻塞服务器，而BGSAVE命令则不会。

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

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

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

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

服务器在900秒之内，对数据库进行了至少1次修改。

服务器在300秒之内，对数据库进行了至少10次修改。

服务器在60秒之内，对数据库进行了至少10000次修改。

举个例子，以下是Redis服务器在60秒之内，对数据库进行了至少10000次修改之后，服务器自动执行BGSAVE命令时打印出来的日志：

设置保存条件

当Redis服务器启动时，用户可以通过指定配置文件或者传人启动参数的方式设置save选项，如果用户没有主动设置save选项，那么服务器会为save选项设置默认条件：

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

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

比如说，如果save选项的值为以下条件：

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

dirty计数器和lastsave属性

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

dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修改（包括写入、删除、更新等操作）。

lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间。

当服务器成功执行一个数据库修改命令之后，程序就会对dirty计数器进行更新：命令修改了多少次数据库，dirty计数器的值就增加多少。

例如，如果我们为一个字符串键设置值：

redis> SET message "hello" OK

那么程序会将dirty计数器的值增加1。

又例如，如果我们向一个集合键增加三个新元素：

redis> SADD database Redis MongoDB MariaDB (integer) 3

那么程序会将dirty计数器的值增加3。

图展示了服务器状态中包含的dirty计数器和 lastsave属性，说明如下：

dirty计数器的值为123, 表示服务器在上次保存之后，对数据库状态共进行了123次修改。

lastsave属性则记录了服务器上次执行保存操作的时间1318210800 (2013年9 月4日零时）。

检查保存条件是否满足

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

以下伪代码展示了serverCron函数检查保存条件的过程：

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

举个例子，如果Redis服务器的当前状态如图所示。

那么当时间来到1378271101, 也即是1378270800的301秒之后，服务器将自动执行一次BGSAVE命令，因为saveparams数组的第二个保存条件，300秒之内有至少 10次修改，已经被满足。

假设BGSAVE在执行5秒之后完成，那么图所示的服务器状态将更新为图, 其中dirty计数器已经被重置为0, 而lastsave属性也被更新为1378271106。

RDB文件结构

我们介绍了Redis服务器保存和载人RDB文件的方法，在这一节，我们将对RDB文件本身进行介绍，并详细说明文件各个部分的结构和意义。

图展示了一个完整RDB文件所包含的各个部分。

注意,为了方便区分变量、数据、常量，图中用全大写单词标示常量，用全小写单词标示变量和数据。本章展示的所有RDB文件结构图都遵循这一规则。

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

注意,因为RDB文件保存的是二进制数据，而不是C字符串，为了简便起见，我们用 "REDIS"符号代表，R'、'E'、'D'、＇I＇、＇S五个字符，而不是带，\0'结尾符号的C 字符串R'、'E'、'D'、＇I＇、＇S'、'\0'。本章介绍的所有内容，以及展示的所有RDB 文件结构图都遵循这一规则。

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

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

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

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

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

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

作为例子，图展示了一个databases部分为空的RDB文件：文件开头的 "REDIS"表示这是一个RDB文件，之后的"0006"表示这是第六版的RDB文件，因为 databases为空，所以版本号之后直接跟着EOF常量，最后的6265312314761917404 是文件的校验和。

databases部分

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

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

每个非空数据库在RDB文件中都可以保存为SELECTDB、db_number、key_value_ pairs三个部分，如图

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

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

key_value_pairs部分保存了数据库中的所有键值对数据，如果键值对带有过期时间，那么过期时间也会和键值对保存在一起。根据键值对的数量、类型、内容以及是否有过期时间等条件的不同，key_value_pairs部分的长度也会有所不同。

作为例子，图展示了RDB文件中，0号数据库的结构。

另外，图则展示了一个完整的RDB文件，文件中包含了0号数据库和3号数据库。

key_value_pairs部分

RDB文件中的每个key_value_pairs部分都保存了一个或以上数量的键值对，如果键值对带有过期时间的话，那么键值对的过期时间也会被保存在内。

不带过期时间的键值对在RDB文件中由TYPE、key、value三部分组成，如图所示。

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

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

其中key总是一个字符串对象，它的编码方式和REDIS_RDB_TYPE_STRING类型的value一样。根据内容长度的不同，key的长度也会有所不同。

根据TYPE类型的不同，以及保存内容长度的不同，保存value的结构和长度也会有所不同，稍后会详细说明每种TYPE类型的value结构保存方式。

带有过期时间的键值对在RDB文件中的结构如图

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

EXPIRETIME MS常量的长度为1字节，它告知读入程序，接下来要读人的将是一个以毫秒为单位的过期时间。

ms是一个8字节长的带符号整数，记录着一个以毫秒为单位的UN1X时间戳，这个时间戳就是键值对的过期时间。

作为例子，图展示了一个没有过期时间的字符串键值对。

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

value的编码

RDB文件中的每个value部分都保存了一个值对象，每个值对象的类型都由与之对应的TYPE记录，根据类型的不同，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位 (bit)、16位或者32位来保存整数值integer。

举个例子，如果字符串对象中保存的是可以用8位来保存的整数123, 那么这个对象在RDB文件中保存的结构将如图

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

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

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

注意，以上两个条件是在假设服务器打开了RDB文件压缩功能的情况下进行的，如果服务器关闭了RDB文件压缩功能，那么RDB程序总以无压缩的方式保存字符串值。

具体信息可以参考redis.conf文件中关于rdbcompression选项的说明。

对于没有被压缩的字符串，RDB程序会以图所示的结构来保存该字符串。

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

其中，REDIS_RDB_ENC_LZF常量标志着字符串已经被LZF算法(http://liblzf.plan9.de)压缩过了，读人程序在碰到这个常量时，会根据之后的compressed_len、origin_ len和compressed_string三部分，对字符串进行解压缩：其中compressed_ len记录的是字符串被压缩之后的长度，而origin_len记录的是字符串原来的长度， compressed_string记录的则是被压缩之后的字符串。

图展示了一个保存无压缩字符串的例子，其中字符串的长度为5, 字符串的值为"hello"

图展示了一个压缩后的字符串示例，从图中可以看出，字符串原本的长度为21, 压缩之后的长度为6, 压缩之后的字符串内容为"?aa???", 其中？代表的是无法用字符串形式打印出来的字节。

列表对象

如果TYPE的值为REDIS_RDB_TYPE_LIST, 那么value保存的就是一个REDIS_ ENCODING_LINKEDLIST编码的列表对象，RDB文件保存这种对象的结构如图所示。

list_length记录了列表的长度，它记录列表保存了多少个项(item), 读人程序可以通过这个长度知道自己应该读人多少个列表项。

图中以让em开头的部分代表列表的项，因为每个列表项都是一个字符串对象，所以程序会以处理字符串对象的方式来保存和读入列表项。

作为示例，图展示了一个包含三个元素的列表。

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

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

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

第三个列表项的长度为1, 内容为字符串，＇！”。

集合对象

如果TYPE的值为REDIS RDB TYPE SET, 那么value保存的就是一个REDIS ENCODING HT编码的集合对象，RDB文件保存这种对象的结构如图

其中，set_size是集合的大小，它记录集合保存了多少个元素，读人程序可以通过这个大小知道自己应该读入多少个集合元素。

图中以elem开头的部分代表集合的元素，因为每个集合元素都是一个字符串对象，所以程序会以处理字符串对象的方式来保存和读人集合元素。

作为示例，图展示了一个包含四个元素的集合。

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

第一个元素的长度为5, 值为"apple"

第二个元素的长度为6, 值为"banana"

第三个元素的长度为3, 值为"cat"

第四个元素的长度为3, 值为"dog"

哈希表对象

如果TYPE的值为REDIS_RDB_TYPE_HASH, 那么value保存的就是一个REDIS_ ENCODING_HT编码的集合对象，RDB文件保存这种对象的结构如图所示：

hash_size记录了哈希表的大小，也即是这个哈希表保存了多少键值对，读人程序可以通过这个大小知道自己应该读人多少个键值对。

以key_value_pair开头的部分代表哈希表中的键值对，键值对的键和值都是字符串对象，所以程序会以处理字符串对象的方式来保存和读人键值对。

结构中的每个键值对都以键紧挨着值的方式排列在一起，如图

因此，从更详细的角度看，图所展示的结构可以进一步修改为图。

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

在这个示例结构中，第一个数字2记录了哈希表的键值对数量，之后跟着的是两个键值对：

第一个键值对的键是长度为1的字符串"a"'值是长度为5的字符串"apple"

第二个键值对的键是长度为1的字符串心”，值是长度为6的字符串"banana"

有序集合对象

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

sorted_set_size记录了有序集合的大小，也即是这个有序集合保存了多少元素，读人程序需要根据这个值来决定应该读人多少有序集合元素。

以element开头的部分代表有序集合中的元素．每个元素又分为成员(member)和分值(score)两部分，成员是一个字符串对象，分值则是一个double类型的浮点数，程序在保存RDB文件时会先将分值转换成字符串对象，然后再用保存字符串对象的方法将分值保存起来。

有序集合中的每个元素都以成员紧挨着分值的方式排列，如图

作为示例，图展示了一个带有两个元素的有序集合。

在这个示例结构中，第一个数字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文件保存这种对象的方法是：

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

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

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

1)读人字符串对象，并将它转换成原来的压缩列表对象。

2)根据TYPE的值，设置压缩列表对象的类型：如果TYPE的值为REDIS_RDB_ TYPE_LIST_ZIPLIST, 那么压缩列表对象的类型为列表；如果TYPE的值为REDIS_ RDB_TYPE_HASH_ZIPLIST, 那么压缩列表对象的类型为哈希表；如果TYPE的值为 REDIS_RDB_TYPE_ZSET_ZIPL工ST, 那么压缩列表对象的类型为有序集合。

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