番外-Redis基本数据类型的数据结构（上）

一、简单动态字符串（SDS）

Redis默认并未直接使用C字符串(C字符串仅仅作为字符串字面量，用在一些无需对字符串进行修改的地方，如打印日志)。而是以Struct的形式构造了一个SDS的抽象类型。当Redis需要一个可以被修改的字符串时，就会使用SDS来表示。在Redis数据库里，包含字符串值的键值对都是由SDS实现的(Redis中所有的键都是由字符串对象实现的即底层是由SDS实现，Redis中所有的值对象中包含的字符串对象底层也是由SDS实现)。

1.1 SDS

struct sdshdr{
    int free; //int 记录buf数组中未使用字节的数量 如上图free为0代表未使用字节的数量为0
    int len; //int 记录buf数组中已使用字节的数量即sds的长度 如上图len为5代表未使用字节的数量为5
    char buf[]; //字节数组用于保存字符串 sds遵循了c字符串以空字符结尾的惯例目的是为了重用c字符串函数库里的函数
}

1.2 为什么要使用SDS

上图表示了SDS与C字符串的区别，关于为什么Redis要使用SDS而不是C字符串，我们可以从以下几个方面来分析

1.2.1 缓冲区溢出

C字符串，如果程序员在字符串修改的时候如果忘记给字符串重新分配足够的空间，那么就会发生内存溢出，如上图所示，忘记给s1分配足够的内存空间, s1的数据就会溢出到s2的空间, 导致s2的内容被修改.。而Redis提供的SDS其内置的空间分配策略则可以完全杜绝这种事情的发生。当API需要对SDS进行修改时, API会首先会检查SDS的空间是否满足条件, 如果不满足, API会自动对它动态扩展, 然后再进行修改。

1.2.2 内存重分配

c字符串内存重分配
在C字符串中，如果对字符串进行修改，那么我们就不得不面临内存重分配。因为C字符串是由一个N+1长度的数组组成，如果字符串的长度变长，我们就必须对数组进行扩容，否则会产生内存溢出。而如果字符串长度变短，我们就必须释放掉不再使用的空间，否则会发生内存泄漏
SDS空间分配策略
对于Redis这种具有高性能要求的内存数据库，如果每次修改字符串都要进行内存重分配，无疑是巨大的性能损失。而Redis的SDS提供了两种空间分配策略来解决这个问题。

1. 空间预分配

我们知道在数组进行扩容的时候，往往会申请一个更大的数组，然后把数组复制过去。为了提升性能，我们在分配空间的时候并不是分配一个刚刚好的空间，而是分配一个更大的空间。Redis同样基于这种策略提供了空间预分配。当执行字符串增长操作并且需要扩展内存时，程序不仅仅会给SDS分配必需的空间还会分配额外的未使用空间，其长度存到free属性中。其分配策略如下:

• 如果修改后len长度将小于1M,这时分配给free的大小和len一样,例如修改过后为10字节, 那么给free也是10字节，buf实际长度变成了10+10+1 = 21byte
• 如果修改后len长度将大于等于1M,这时分配给free的长度为1M,例如修改过后为30M,那么给free是1M.buf实际长度变成了30M+1M+1byte
  

2. 惰性空间释放

惰性空间释放用于字符串缩短的操作。当字符串缩短是，程序并不是立即使用内存重分配来回收缩短出来的字节，而是使用free属性记录起来，并等待将来使用。


Redis通过空间预分配和惰性空间释放策略在字符串操作中一定程度上减少了内存重分配的次数。但这种策略同样会造成一定的内存浪费，因此Redis SDS API提供相应的API让我们在有需要的时候真正的释放SDS的未使用空间。

1.2.3 为什么要使用SDS

通过以上分析，我们可以得到，SDS这种数据结构相对于C字符串有以下优点:

• 杜绝缓冲区溢出
• 减少字符串操作中的内存重分配次数
• 二进制安全
• 由于SDS遵循以空字符结尾的惯例，因此兼容部门C字符串函数

Redis定位于一个高性能的内存数据库，其面向的就是大数据量，大并发，频繁读写，高响应速度的业务。因此在保证安全稳定的情况下，性能的提升非常重要。而SDS这种数据结构屏蔽了C字符串的一些缺点，可以提供安全高性能的字符串操作。

1.3 小结

Redis在互联网项目中的应用越来越广泛，会用只是学习Redis中最简单的一步，要想真正的成为Redis高手，了解其底层的实现必不可少。本篇文章简单介绍了Redis中SDS数据结构及其特性，分析了Redis SDS的空间分配策略和其与C字符串相比的优势，后续的文章将继续分享Redis底层实现的其它数据结构。未完待续…

二、链表

• Redis链表为双向无环链表！
• Redis之数据结构——简单动态字符串SDS提到Redis使用了简单动态字符串，链表，字典(散列表),跳跃表,整数集合,压缩列表这些数据结构来操作内存，并且简单介绍了Redis简单动态字符串。本篇文章我们继续来分析链表。
• 链表是一种非常常见的数据结构，在Redis中使用非常广泛，列表对象的底层实现之一就是链表。其它如慢查询，发布订阅，监视器等功能也用到了链表。

2.1 复习链表

2.1.1 数组与链表

• 数组需要一块连续的内存来存储，这个特性有利也有弊。好处是其支持根据索引下标"随机访问"(时间复杂度为O(1))，但是其插入与删除操作为了保证在内存中的连续性将会变得非常低效(时间复杂度为O(N))，并且其一经声明就要占用整块连续内存空间，如果声明过大，系统可能内存不足，声明过小又可能导致不够用，而当数组的空间不足的时候需要对其进行扩容(申请一个更大的空间，将原数组拷贝过去)。
• 而链表恰恰相反，其不需要一块连续的内存空间，其通过"指针"将一组零散的内存连接起来使用。其优点在于本身没有大小限制，天然支持扩容，插入删除操作高效(时间复杂度为O(1))，但缺点是随机访问低效(时间复杂度为O(N))。并且由于需要额外的空间存储指针。

2.1.2 单链表

单链表中每个节点除了包含数据之外还包含一个指针，叫后继指针，因此需要额外的空间来存储后继节点的地址。有两个特殊的节点,头结点和尾节点，其中头节点用来记录链表的基地址，有了它就可以遍历整个链表，尾节点的后继指针不是指向下一个节点，而是指向一个空地址NULL表示这是链表上最后一个节点。与数组一样，单链表也支持数据的查找、插入和删除操作，其中插入和删除操作只需要考虑相邻节点指针的变化，因此为常数级时间复杂度O(1)。要想随机访问第 k 个元素，就没有数组那么高效了。因为链表中的数据并非连续存储的，所以无法像数组那样，根据首地址和下标，通过寻址公式就能直接计算出对应的内存地址，而是需要根据指针一个结点一个结点地依次遍历，直到找到相应的结点，因此时间复杂度为O(N)。

2.1.3 双向链表

双向链表和单链表不同的是多了一个前驱指针，双向链表需要额外的两个空间来存储后继结点和前驱结点的地址。因此存储同样多的数据，双向链表占用比单链表更多的空间。但其优点在于支持双向遍历，体现在以下两个方面。

• 在有序链表中查找某个元素，单链表由于只有后继指针，因此只能从前往后遍历查找时间复杂度为O(N)，而双向链表可以双向遍历。
• 删除给定指针指向的结点。假设已经找到要删除的节点，要删除就必须知道其前驱节点和后继节点，单链表想要知道其前驱节点只能从头开始遍历，时间复杂度为0(n)，而双向链表由于保存了其前驱节点的地址，因此时间复杂度为0(1)

2.1.4 循环链表

顾名思义。循环链表与单、双链表不同的是其呈环状，单循环链表中其尾节点并非指向NULL而是指向头结点。双循环链表中其头节点的前驱指针指向尾节点，尾节点的后继指针指向头结点。循环链表的优势在于链尾到链头，链头到链尾比较方便适合处理的数据具有环型结构特点。

2.2 Redis链表

Redis链表使用双向无环链表

如图所示，Redis使用一个listNode结构来表示

typedef struct listNode { 
// 前置节点 
struct listNode *prev; 
// 后置节点 
struct listNode *next; 
// 节点的值 
void *value; 
 } listNode;

2.2.1 list结构

同时Redis为了方便的操作链表，提供了一个list结构来持有链表。如下图所示

typedef struct list{ 
//表头节点
listNode *head; 
//表尾节点
listNode *tail; 
//链表所包含的节点数量 
unsigned long len; 
//节点值复制函数 
void *(*dup)(void *ptr); 
//节点值释放函数 
void *(*free)(void *ptr); 
//节点值对比函数 
int (*match)(void *ptr,void *key); }list;

Redis链表结构其主要特性如下:

• 双向：链表节点带有前驱、后继指针获取某个节点的前驱、后继节点的时间复杂度为0(1)。
• 无环: 链表为非循环链表表头节点的前驱指针和表尾节点的后继指针都指向NULL，对链表的访问以NULL为终点。
• 带表头指针和表尾指针：通过list结构中的head和tail指针，获取表头和表尾节点的时间复杂度都为O(1)。
• 带链表长度计数器:通过list结构的len属性获取节点数量的时间复杂度为O(1)。
• 多态：链表节点使用void*指针保存节点的值，并且可以通过list结构的dup、free、match三个属性为节点值设置类型特定函数，所以链表可以用来保存各种不同类型的值。

2.3 小结

链表作为一种非常常用的数据结构，内置在许多编程语言里面，更是找工作过程中经常问的面试题之一。本篇文章简单复习了链表这种数据结构常见的几种形式，并且简单分析了Redis中链表的使用。下篇文章将继续分享Redis中用到的数据结构Hash。敬请关注！

三、字典

3.1 复习散列表

3.1.1 散列表

散列表(哈希表)，其思想主要是基于数组支持按照下标随机访问数据时间复杂度为O(1)的特性。可是说是数组的一种扩展。假设，我们为了方便记录某高校数学专业的所有学生的信息。要求可以按照学号(学号格式为:入学时间+年级+专业+专业内自增序号，如2011 1101 0001)能够快速找到某个学生的信息。这个时候我们可以取学号的自增序号部分，即后四位作为数组的索引下标，把学生相应的信息存储到对应的空间内即可。


如上图所示,我们把学号作为key,通过截取学号后四位的函数后计算后得到索引下标，将数据存储到数组中。当我们按照键值(学号)查找时，只需要再次计算出索引下标，然后取出相应数据即可。以上便是散列思想

3.1.2 散列函数

上面的例子中，截取学号后四位的函数即是一个简单的散列函数

//散列函数 伪代码 
int Hash(string key) { 
// 获取后四位字符 
string hashValue =int.parse(key.Substring(key.Length-4, 4)); 
// 将后两位字符转换为整数 
return hashValue; }

在这里散列函数的作用就是讲key值映射成数组的索引下标。关于散列函数的设计方法有很多，如:直接寻址法、数字分析法、随机数法等等。但即使是再优秀的设计方法也不能避免散列冲突。在散列表中散列函数不应设计太复杂。

3.1.3 散列冲突

散列函数具有确定性和不确定性。

• 确定性:哈希的散列值不同，那么哈希的原始输入也就不同。即:key1=key2,那么hash(key1)=hash(key2)。
• 不确定性:同一个散列值很有可能对应多个不同的原始输入。即:key1≠key2，hash(key1)=hash(key2)。

散列冲突,即key1≠key2，hash(key1)=hash(key2)的情况。散列冲突是不可避免的，如果我们key的长度为100，而数组的索引数量只有50，那么再优秀的算法也无法避免散列冲突。关于散列冲突也有很多解决办法，这里简单复习两种：开放寻址法和链表法。

3.2 Redis字典

3.2.1 Redis字典的实现

Redis字典使用散列表最为底层实现，一个散列表里面有多个散列表节点，每个散列表节点就保存了字典中的一个键值对

字典

typedef struct dict{ 
//类型特定函数 
void *type; 
//私有数据 
void *privdata; 
//哈希表-见2.1.2
dictht ht[2]; 
//rehash 索引 当rehash不在进行时 值为-1 
int trehashidx; 
 }dict;

type属性和privdata属性是针对不同类型的键值对，为创建多态字典而设置的。

• type属性是一个指向dictType结构的指针，每个dictType用于操作特定类型键值对的函数，Redis会为用途不同的字典设置不同的类型特定函数。
• privdata属性则保存了需要传给给那些类型特定函数的可选参数。

散列表

typedef struct dictht { 
//哈希表数组，C语言中，*号是为了表明该变量为指针，有几个* 号就相当于是几级指针，这里是二级指针，理解为指向指针的指针
dictEntry **table; 
//哈希表大小 
unsigned long size; 
//哈希表大小掩码，用于计算索引值 
unsigned long sizemask; 
//该哈希已有节点的数量 
unsigned long used; 
}dictht;

• table属性是一个数组，数组中的每个元素都是一个指向dict.h/dictEntry结构的指针，每个dictEntry结构保存着一个键值对
• size属性记录了哈希表的大小，也是table数组的大小
• used属性则记录哈希表目前已有节点(键值对)的数量
• sizemask属性的值总是等于 size-1(从0开始)，这个属性和哈希值一起决定一个键应该被放到table数组的哪个索引上面（索引下标值）。

散列表结点

//哈希表节点定义dictEntry结构表示，每个dictEntry结构都保存着一个键值对。 
typedefstructdictEntry{ 
//键 
void*key; 
//值 
union{ 
    void*val; 
     uint64_tu64; 
     int64_ts64; 
     }v; 
    // 指向下个哈希表节点，形成链表 
structdictEntry *next; 
}dictEntry;

key属性保存着键值中的键，而v属性则保存着键值对中的值，其中键值(v属性)可以是一个指针，或uint64_t整数，或int64_t整数。 next属性是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一起，解决键冲突问题。

3.2.2 Redis如何解决散列冲突

链表法
当有两个或以上的键被分配到散列表数组同一个索引上时，就发生了键冲突。Redis使用链表法解决散列冲突。每个散列表节点都有一个next指针，多个散列表节点next可以用next指针构成一个单向链表，被分配到同一个索引上的多个节点可以使用这个单向链表连接起来。

如图所示,当键k0和k1的经过散列函数得到索引值都为1时，就会使用next指针将两个节点连接起来。而由于节点没有指向链尾的指针，因此新的节点总是插入到链表的头部，排在已有节点的前面。
Redis rehash
随着操作的进行，散列表中保存的键值对会也会不断地增加或减少，为了保证负载因子维持在一个合理的范围，当散列表内的键值对过多或过少时，内需要定期进行rehash，以提升性能或节省内存。Redis的rehash的步骤如下:

1. 为字典的ht[1]散列表分配空间，这个空间的大小取决于要执行的操作以及ht[0]当前包含的键值对数量(即:ht[0].used的属性值)
   1. 扩展操作：ht[1]的大小为 第一个大于等于ht[0].used*2的2的n次方幂。如:ht[0].used=3则ht[1]的大小为8，ht[0].used=4则ht[1]的大小为8。
   2. 收缩操作: ht[1]的大小为 第一个大于等于ht[0].used的2的n次方幂。

2. 将保存在ht[0]中的键值对重新计算键的散列值和索引值，然后放到ht[1]指定的位置上。

3. 将ht[0]包含的所有键值对都迁移到了ht[1]之后，释放ht[0],将ht[1]设置为ht[0],并创建一个新的ht[1]哈希表为下一次rehash做准备。

rehash操作需要满足以下条件

1. 服务器目前没有执行BGSAVE(rdb持久化)命令或者BGREWRITEAOF(AOF文件重写)命令，并且散列表的负载因子大于等于1。
2. 服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令，并且负载因子大于等于5。
3. 当负载因子小于0.1时，程序自动开始执行收缩操作。

Redis这么做的目的是基于操作系统创建子进程后写时复制技术，避免不必要的写入操作。(有关BGSAVE、BGREWRITEAOF以及写时复制会在后续持久化一文详细介绍)。

3.3 小结

本篇文章主要回顾了散列表的概念，散列函数以及如何解决散列冲突。并分析了Redis中字典的实现。下篇文章将介绍跳跃表以及跳跃表在Redis中的实现。

四、跳跃表

4.1 复习跳跃表

4.1.1 什么是跳跃表

对于一个单链表来讲，即便链表中存储的数据是有序的，如果我们要想在其中查找某个数据，也只能从头到尾遍历链表。这样查找效率就会很低，时间复杂度会很高，是 O(n)。

如果我们想要提高其查找效率，可以考虑在链表上建索引的方式。每两个结点提取一个结点到上一级，我们把抽出来的那一级叫作索引。

• 这个时候，我们假设要查找节点8，我们可以先在索引层遍历，当遍历到索引层中值为 7 的结点时，发现下一个节点是9，那么要查找的节点8肯定就在这两个节点之间。我们下降到链表层继续遍历就找到了8这个节点。原先我们在单链表中找到8这个节点要遍历8个节点，而现在有了一级索引后只需要遍历五个节点。
• 从这个例子里，我们看出，加来一层索引之后，查找一个结点需要遍的结点个数减少了，也就是说查找效率提高了，同理再加一级索引。

从图中我们可以看出，查找效率又有提升。在例子中我们的数据很少，当有大量的数据时，我们可以增加多级索引，其查找效率可以得到明显提升。

像这种链表加多级索引的结构，就是跳跃表！

4.2 Redis跳跃表

• Redis使用跳跃表作为有序集合键的底层实现之一,如果一个有序集合包含的元素数量比较多,又或者有序集合中元素的成员是比较长的字符串时, Redis就会使用跳跃表来作为有序集合健的底层实现。
• 这里我们需要思考一个问题——为什么元素数量比较多或者成员是比较长的字符串的时候Redis要使用跳跃表来实现？
• 从上面我们可以知道，跳跃表在链表的基础上增加了多级索引以提升查找的效率，但其是一个空间换时间的方案，必然会带来一个问题——索引是占内存的。原始链表中存储的有可能是很大的对象，而索引结点只需要存储关键值值和几个指针，并不需要存储对象，因此当节点本身比较大或者元素数量比较多的时候，其优势必然会被放大，而缺点则可以忽略。

4.2.1 Redis中跳跃表的实现

Redis的跳跃表由zskiplistNode和skiplist两个结构定义,其中 zskiplistNode结构用于表示跳跃表节点,而 zskiplist结构则用于保存跳跃表节点的相关信息,比如节点的数量,以及指向表头节点和表尾节点的指针等等

上图展示了一个跳跃表示例,其中最左边的是 skiplist结构,该结构包含以下属性。

4.3 小结

跳跃表可能对我们来说是一种的稍陌生的数据结构。本篇文章简单介绍了跳跃表这种数据结构，并且分析了Redis中跳跃表的使用。下篇文章将继续分享Redis中用到的数据结构整数集合。敬请关注!

五、整数集合

整数集合(intset)并不是一个基础的数据结构，而是Redis自己设计的一种存储结构，是集合键的底层实现之一,当一个集合只包含整数值元素,并且这个集合的元素数量不多时, Redis 就会使用 整数集合 作为集合键的底层实现。

5.1 整数集合实现

整数集合(intset)是Redis用于保存整数值的集合抽象数据结构,它可以保存类型为int16_t、int32_t或者int64_t的整数值,并且保证集合中不会出现重复元素。

//每个intset结构表示一个整数集合 
typedef struct intset{ 
//编码方式 
uint32_t encoding; 
//集合中包含的元素数量 
uint32_t length; 
//保存元素的数组 
int8_t contents[]; 
} intset;

• contents数组是整数集合的底层实现，整数集合的每个元素都是 contents数组的个数组项(item),各个项在数组中按值的大小从小到大有序地排列,并且数组中不包含任何重复项。
• length属性记录了数组的长度。
• intset结构将contents属性声明为int8_t类型的数组,但实际上 contents数组并不保存任何int8t类型的值, contents数组的真正类型取决于encoding属性的值。encoding属性的值为INTSET_ENC_INT16则数组就是uint16_t类型，数组中的每一个元素都是int16_t类型的整数值(-32768——32767)，encoding属性的值为INTSET_ENC_INT32则数组就是uint32_t类型，数组中的每一个元素都是int16_t类型的整数值(-2147483648——2147483647)。

如上图，为一int16_t类型的整数集合，我们可以看到数组中存储了5个int16_t类型的整数，它们按照从小到大的顺序依次排列。这个时候我们思考一个问题。如果这个时候存入一个int32_t类型的整数会怎么样？内存溢出？这个时候就要提到整数集合的升级

5.2 整数集合的升级（略）

六、压缩列表

同整数集合一样压缩列表也不是基础数据结构，而是 Redis 自己设计的一种数据存储结构。它有点儿类似数组，通过一片连续的内存空间，来存储数据。不过，它跟数组不同的一点是，它允许存储的数据大小不同。

6.1 结构概述

听到“压缩”两个字，直观的反应就是节省内存。之所以说这种存储结构节省内存,是相较于数组的存储思路而言的。我们知道,数组要求每个元素的大小相同,如果我们要存储不同长度的字符串,那我们就需要用最大长度的字符串大小作为元素的大小(假设是20个字节)。存储小于 20 个字节长度的字符串的时候，便会浪费部分存储空间。

数组的优势占用一片连续的空间可以很好的利用CPU缓存访问数据。如果我们想要保留这种优势，又想节省存储空间我们可以对数组进行压缩

但是这样有一个问题，我们在遍历它的时候由于不知道每个元素的大小是多少，因此也就无法计算出下一个节点的具体位置。这个时候我们可以给每个节点增加一个lenght的属性

如此。我们在遍历节点的之后就知道每个节点的长度(占用内存的大小)，就可以很容易计算出下一个节点再内存中的位置。这种结构就像一个简单的压缩列表了。

6.2 Redis压缩列表

• 压缩列表(zip1ist)是列表和哈希的底层实现之一。
• 当一个列表只包含少量列表项,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做列表的底层实现。
• 当一个哈希只包含少量键值对,比且每个键值对的键和值要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做哈希的底层实现。

6.2.1 Redis压缩列表的构成

压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结枃。一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值，如下图

示例：

如上图，展示了一个总长为80字节，包含3个节点的压缩列表。如果我们有一个指向压缩列表起始地址的指针p，那么表为节点的地址就是P+60

6.2.2 Redis压缩列表结点的构成

七、Redis对象系统简介

• 之前几篇文章,简单介绍 Redis用到的所有主要数据结构,简单动态字符串(SDS)、双端链表、字典、压缩列表、整数集合、跳跃表。
• Redis并没有直接使用这些数据结构来实现键值对数据库,而是基于这些数据结构创建了一个对象系统,这个系统包含 字符串对象、列表对象、哈希对象、集合对象和有序集合 对象这五种类型的对象,而每种对象又通过不同的编码映射到不同的底层数据结构。

7.1 Redis对象类型和编码

• Redis中的每个对象都由一个redisObject结构表示,该结构中和保存数据有关的三个属性分别是type属性、 encoding属性和ptr属性:
• Redis使用对象来表示数据库中的键和值,每次当我们在Redis的数据库中新创建一个键值对时,我们至少会创建两个对象,一个对象用作键值对的健(键对象),另一个对象用作键值对的值(值对象)

typedef struct redisObiect{ 
//类型 
unsigned type:4; 
//编码 
unsigned encoding:4; 
//指向底层数据结构的指针void *ptr; 
}

其中Redis的键对象都是字符串对象，而Redis的值对象主要有字符串、哈希、列表、集合、有序集合几种。其分别对应的内部编码和底层数据结构如下图所示：

7.2 思考一个问题

Redis中的对象，大都是通过多种数据结构来实现的，为什么会这样设计呢？用一种固定的数据结构来实现，不是更加简单吗？

• Redis这样设计有两个好处：
  1. 可以自由改进内部编码，而对外的数据结构和命令没有影响，这样一旦开发出更优秀的内部编码，无需改动外部数据结构和命令，例如Redis3.2提供了quicklist，其结合了ziplist和linkedlist两者 的优势，为列表类型提供了一种更为优秀的内部编码实现，而对外部用户来说基本感知不到。 这一点比较像程序设计中的分层架构。
  2. 多种内部编码实现可以在不同场景下发挥各自的优势，从而优化对象在不同场景下的使用效率。例如ziplist比较节省内存，但是在列表元素比较多的情况下，性能会有所下降，这时候Redis会根据配置选项将列表类型的内部实现转换linkedlist。 (后续文章将根据具体对象介绍)

八、快速列表（quicklist）

之前的文章我们曾总结到了Redis数据结构——链表和Redis数据结构——压缩列表这两种数据结构，他们是Redis List(列表)对象的底层实现方式。但是考虑到链表的附加空间相对太高，prev 和 next 指针就要占去 16 个字节 (64bit 系统的指针是 8 个字节)，另外每个节点的内存都是单独分配，会加剧内存的碎片化，影响内存管理效率。因此Redis3.2版本开始对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist.

8.1 基本结构

quicklist 实际上是 zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来。

typedef struct quicklistNode { 
    struct quicklistNode *prev; //上一个node节点 
    struct quicklistNode *next; //下一个node 
    unsigned char *zl; //保存的数据 压缩前ziplist 压缩后压缩的数据 
    unsigned int sz; /* ziplist size in bytes */ 
    unsigned int count : 16; /* count of items in ziplist */ 
    unsigned int encoding : 2; /* RAW==1 or LZF==2 */ 
    unsigned int container : 2; /* NONE==1 or ZIPLIST==2 */ 
    unsigned int recompress : 1; /* was this node previous compressed? */ 
    unsigned int attempted_compress : 1; /* node can't compress; too small */ 
    unsigned int extra : 10; /* more bits to steal for future usage */ 
} quicklistNode;

• prev: 指向链表前一个节点的指针。
• next: 指向链表后一个节点的指针。
• zl: 数据指针。如果当前节点的数据没有压缩，那么它指向一个ziplist结构；否则，它指向一个quicklistLZF结构。
• sz: 表示zl指向的ziplist的总大小（包括zlbytes, zltail, zllen, zlend和各个数据项）。需要注意的是：如果ziplist被压缩了，那么这个sz的值仍然是压缩前的ziplist大小。
• count: 表示ziplist里面包含的数据项个数。这个字段只有16bit。稍后我们会一起计算一下这16bit是否够用。
• encoding: 表示ziplist是否压缩了（以及用了哪个压缩算法）。目前只有两种取值：2表示被压缩了（而且用的是LZF压缩算法），1表示没有压缩。
• container: 是一个预留字段。本来设计是用来表明一个quicklist节点下面是直接存数据，还是使用ziplist存数据，或者用其它的结构来存数据（用作一个数据容器，所以叫container）。但是，在目前的实现中，这个值是一个固定的值2，表示使用ziplist作为数据容器。
• recompress: 当我们使用类似lindex这样的命令查看了某一项本来压缩的数据时，需要把数据暂时解压，这时就设置recompress=1做一个标记，等有机会再把数据重新压缩。
• attempted_compress: 这个值只对Redis的自动化测试程序有用。我们不用管它。
• extra: 其它扩展字段。目前Redis的实现里也没用上。

8.2 常用操作（略）

8.3 小结

Redis quicklist是Redis 3.2版本以后针对链表和压缩列表进行改造的一种数据结构，是 zipList 和 linkedList 的混合体，相对于链表它压缩了内存。进一步的提高了效率。