Redis数据结构的实现

一、链表

复习

数组与链表区别：

数组需要一块连续的内存来存储，这个特性有利也有弊。好处是其支持根据索引下标"随机访问"(时间复杂度为O(1)，数组中按照下标随机访问的时间复杂度是O(1))，但是其插入与删除操作为了保证在内存中的连续性将会变得非常低效(时间复杂度为O(N))，并且其一经声明就要占用整块连续内存空间，如果声明过大，系统可能内存不足，声明过小又可能导致不够用，而当数组的空间不足的时候需要对其进行扩容(申请一个更大的空间，将原数组拷贝过去)。

而链表恰恰相反，其不需要一块连续的内存空间，其通过"指针"将一组零散的内存连接起来使用。其优点在于本身没有大小限制，天然支持扩容，插入删除操作高效(时间复杂度为O(1))，但缺点是随机访问低效(时间复杂度为O(N))。并且由于需要额外的空间存储指针。

链表的常见实现方式：

1.单链表

单链表中每个节点除了包含数据之外还包含一个指针，叫后继指针，因此需要额外的空间来存储后继节点的地址。有两个特殊的节点,头结点和尾节点，其中头节点用来记录链表的基地址，有了它就可以遍历整个链表，尾节点的后继指针不是指向下一个节点，而是指向一个空地址NULL表示这是链表上最后一个节点。与数组一样，单链表也支持数据的查找、插入和删除操作。

在不知节点的情况下，要删除第index个元素，需要从头遍历直到找到第index-1个节点需要O（N）时间，找到后，改变指针指向时间为O（1），所以复杂度为O（N）。而插入与删除同理，需要遍历找到index-1的节点复杂度为O（N），找到后创建新节点，改变指针方向为O（1），所以复杂度同为O（N）。

得出理论在不知前驱节点时，进行插入和删除操作时，因不知前驱节点需要遍历得出前驱节点所以复杂度都为O（N），已知前驱节点复杂度为O（1），不同情况的复杂度都为不同，需要看情况区分。

查询复杂度为O（N）。

2.双向链表

双向链表和单链表不同的是多了一个前驱指针，双向链表需要额外的两个空间来存储后继结点和前驱结点的地址。因此存储同样多的数据，双向链表占用比单链表更多的空间。

双向链表在进行插入操作时指定节点，复杂度为O（1），因指定节点已知前后驱节点。

双向链表数据
...<->A<->B<->C<->...
向B节点后插入D
既
...<->A<->B<->D<->C<->...
算法如下：
1.找到B节点的后驱节点C，复杂度为O（1）
2.将插入D节点的prev指针指向B，next指针指向C，复杂度为O（1）
3.修改B的next指针指向D，复杂度为O（1）
4.修改C的prev指针指向D，复杂度为O（1）

而若是按序或者按值插入，需要遍历值所在的节点复杂度为O（N）在得到前驱节点插入时间O（1），所以复杂度为O（N）。因需要根据值去遍历得出节点复杂度为O（N）。

删除同插入，不在赘述。

查询复杂度为O（N）。

二、Redis双向链表

1.双端链表

多个listNode可以通过prev和next指针组成双端链表

结构如下：

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;

list结构为链表提供了表头指针head、表尾指针tail，以及链表长度计数器len，而dup、free和match成员则是用于实现多态链表所需的类型特定函数：

·dup函数用于复制链表节点所保存的值；
·free函数用于释放链表节点所保存的值；
·match函数则用于对比链表节点所保存的值和另一个输入值是否相等。

由list结构和listNode结构组成的链表

Redis的链表实现的特性可以总结如下：

·双端：链表节点带有prev和next指针，获取某个节点的前置节点和后置节点的复杂度都是O（1）。
·无环：表头节点的prev指针和表尾节点的next指针都指向NULL，对链表的访问以NULL为终点。
·带表头指针和表尾指针：通过list结构的head指针和tail指针，程序获取链表的表头节点和表尾节点的复杂度为O（1）。
·带链表长度计数器：程序使用list结构的len属性来对list持有的链表节点进行计数，程序获取链表中节点数量的复杂度为O（1）。
·多态：链表节点使用void*指针来保存节点值，并且可以通过list结构的dup、free、match三个属性为节点值设置类型特定函数，所以链表可以用于保存各种不同类型的值。

重点回顾：

·链表被广泛用于实现Redis的各种功能，比如列表键、发布与订阅、慢查询、监视器等。
·每个链表节点由一个listNode结构来表示，每个节点都有一个指向前置节点和后置节点的指针，所以Redis的链表实现是双端链表。
·每个链表使用一个list结构来表示，这个结构带有表头节点指针、表尾节点指针，以及链表长度等信息。
·因为链表表头节点的前置节点和表尾节点的后置节点都指向NULL，所以Redis的链表实现是无环链表。
·通过为链表设置不同的类型特定函数，Redis的链表可以用于保存各种不同类型的值。

二、字典

字典在Redis中的应用相当广泛，比如Redis的数据库就是使用字典来作为底层实现的，对数据库的增、删、查、改操作也是构建在对字典的操作之上的。

复习散列表

散列表(哈希表)，其思想主要是基于数组支持按照下标随机访问数据时间复杂度为O(1)的特性。是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。假设，我们为了方便记录某高校数学专业的所有学生的信息。要求可以按照学号(学号格式为:入学时间+年级+专业+专业内自增序号，如2011 1101 0001)能够快速找到某个学生的信息。这个时候我们可以取学号的自增序号部分，即后四位作为数组的索引下标，把学生相应的信息存储到对应的空间内即可。

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

散列函数（哈希函数）：

哈希函数指将哈希表中元素的关键键值映射为元素存储位置的函数。哈希表中元素是由哈希函数确定的。将数据元素的关键字K作为自变量，通过一定的函数关系（称为哈希函数），计算出的值，即为该元素的存储地址。简单的说，hash函数就是把任意长的输入字符串变化成固定长的输出字符串的一种函数。输出字符串的长度称为hash函数的位数。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来，比如我们自定义密码的存储。可以理解：散列（Hashing）通过散列函数将要检索的项与索引（散列，散列值）关联起来，生成一种便于搜索的数据结构（散列表）。

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

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

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

散列冲突：

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

确定性:哈希的散列值不同，那么哈希的原始输入也就不同。即:key1=key2,那么hash(key1)=hash(key2) （记住如果key相同，后面的key会顶替掉前面key的value值）。
不确定性:同一个散列值很有可能对应多个不同的原始输入。即:key1≠key2，hash(key1)=hash(key2)。

散列冲突,即key1≠key2，hash(key1)=hash(key2)的情况（也就是2个关键字处理函数的结果映射在了同一位置上）。散列冲突是不可避免的，如果我们key的长度为100，而数组的索引数量只有50，那么再优秀的算法也无法避免散列冲突。关于散列冲突也有很多解决办法，这里简单复习两种：开放寻址法和链表法。

开放寻址法：

开放寻址法的核心思想是，如果出现了散列冲突，我们就重新探测一一个空闲位置，将其插入。比如，我们可以使用线性探测法。当我们往散列表中插入数据时，如果某个数据经过散列函数散列之后，存储位置已经被占用了，我们就从当前位置开始，依次往后查找，看是否有空闲位置，如果遍历到尾部都没有找到空闲的位置，那么我们就再从表头开始找，直到找到为止。

散列表中查找元素的时候，我们通过散列函数求出要查找元素的键值对应的散列值，然后比较数组中下标为散列值的元素和要查找的元素。如果相等，则说明就是我们要找的元素；否则就顺序往后依次查找。如果遍历到数组中的空闲位置还没有找到，就说明要查找的元素并没有在散列表中。

对于删除操作稍微有些特别，不能单纯地把要删除的元素设置为空。因为在查找的时候，一旦我们通过线性探测方法，找到一个空闲位置，我们就可以认定散列表中不存在这个数据。但是，如果这个空闲位置是我们后来删除的，就会导致原来的查找算法失效。这里我们可以将删除的元素，特殊标记为 deleted。当线性探测查找的时候，遇到标记为 deleted 的空间，并不是停下来，而是继续往下探测。

线性探测法存在很大问题。当散列表中插入的数据越来越多时，其散列冲突的可能性就越大，极端情况下甚至要探测整个散列表,因此最坏时间复杂度为O(N)。在开放寻址法中，除了线性探测法，我们还可以二次探测和双重散列等方式。

二次探测：若当前key与原来key产生相同的哈希地址，则当前key存在该地址后偏移量为（1,2,3...）的二次方地址处。（hash(key)+1^2，hash(key)+2^2，.....）

链表法：

链表法是一种比较常用的散列冲突解决办法,Redis使用的就是链表法来解决散列冲突。链表法的原理是:如果遇到冲突，他就会在原地址新建一个空间，然后以链表结点的形式插入到该空间。当插入的时候，我们只需要通过散列函数计算出对应的散列槽位，将其插入到对应链表中即可。

负载因子与rehash：

我们可以使用装载因子来衡量散列表的“健康状况”。列表的负载因子 = 填入表中的元素个数/散列表的长度。散列表负载因子越大，代表空闲位置越少，冲突也就越多，散列表的性能会下降。对于散列表来说，负载因子过大或过小都不好，负载因子过大，散列表的性能会下降。而负载因子过小，则会造成内存不能合理利用，从而形成内存浪费。因此我们为了保证负载因子维持在一个合理的范围内，要对散列表的大小进行收缩或扩展，即rehash。散列表的rehash过程类似于数组的收缩与扩容。

开放寻址法与链表法比较：

对于开放寻址法解决冲突的散列表，由于数据都存储在数组中，因此可以有效地利用 CPU 缓存加快查询速度(数组占用一块连续的空间)。但是删除数据的时候比较麻烦，需要特殊标记已经删除掉的数据。而且，在开放寻址法中，所有的数据都存储在一个数组中，比起链表法来说，冲突的代价更高。所以，使用开放寻址法解决冲突的散列表，负载因子的上限不能太大。这也导致这种方法比链表法更浪费内存空间。

对于链表法解决冲突的散列表,对内存的利用率比开放寻址法要高。因为链表结点可以在需要的时候再创建，并不需要像开放寻址法那样事先申请好。链表法比起开放寻址法，对大装载因子的容忍度更高。开放寻址法只能适用装载因子小于1的情况。接近1时，就可能会有大量的散列冲突，性能会下降很多。但是对于链表法来说，只要散列函数的值随机均匀，即便装载因子变成10，也就是链表的长度变长了而已，虽然查找效率有所下降，但是比起顺序查找还是快很多。但是，链表因为要存储指针，所以对于比较小的对象的存储，是比较消耗内存的，而且链表中的结点是零散分布在内存中的，不是连续的，所以对CPU缓存是不友好的，这对于执行效率有一定的影响。

Redis字典的实现：

Redis的字典使用哈希表作为底层实现，一个哈希表里面可以有多个哈希表节点，而每个哈希表节点就保存了字典中的一个键值对。

Redis字典所使用的哈希表由dict.h/dictht结构定义：

typedef struct dictht {
  // 哈希表数组 
  dictEntry **table; 
  // 哈希表大小 
  unsigned long size;
  //哈希表大小掩码，用于计算索引值 
   //总是等于size-1 
   unsigned long sizemask; 
   // 该哈希表已有节点的数量 
   unsigned long used;
} dictht;
1.table属性是一个数组，数组中的每个元素都是一个指向dict.h/dictEntry结构的指针，每个dictEntry结构保存着一个键值对。
2.size属性记录了哈希表的大小，也即是table数组的大小。
3.used属性则记录了哈希表目前已有节点（键值对）的数量
4.sizemask属性的值总是等于size-1，这个属性和哈希值一起决定一个键应该被放到table数组的哪个索引上面（索引下标值）

一个空的哈希表

哈希表节点使用dictEntry结构表示，每个dictEntry结构都保存着一个键值对：

typedef struct dictEntry {
    // 键 
    void *key; 
    // 值 
     union{ 
     void *val; 
      uint64_tu64; 
       int64_ts64; 
      } v; 
     // 指向下个哈希表节点，形成链表 
     struct dictEntry *next;
} dictEntry;
key属性保存着键值对中的键，而v属性则保存着键值对中的值，其中键值对的值可以是一个指针，或者是一个uint64_t整数，又或者是一个int64_t整数。
next属性是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一次，以此来解决键冲突（collision）的问题。
举个例子：如何通过next指针，将两个索引值相同的k1和k0连接在一起。

Redis中的字典由dict.h/dict结构表示：

typedef struct dict { 
    // 类型特定函数 
    dictType *type; 
    // 私有数据 
    void *privdata; 
    // 哈希表 
    dictht ht[2]; 
    // rehash索引 
    //当rehash不在进行时，值为-1 
    in trehashidx; 
} dict;
type属性和privdata属性是针对不同类型的键值对，为创建多态字典而设置的：
·type属性是一个指向dictType结构的指针，每个dictType结构保存了一簇用于操作特定类型键值对的函数，Redis会为用途不同的字典设置不同的类型特定函数。
·而privdata属性则保存了需要传给那些类型特定函数的可选参数。
typedef struct dictType { 
     // 计算哈希值的函数 
     unsigned int (*hashFunction)(const void *key); 
      // 复制键的函数 
      void *(*keyDup)(void *privdata, const void *key);               
      // 复制值的函数 
      void *(*valDup)(void *privdata, const void *obj); 
      // 对比键的函数 
      int (*keyCompare)(void *privdata, const void *key1, const void *key2); 
       // 销毁键的函数 
      void (*keyDestructor)(void *privdata, void *key); 
      // 销毁值的函数 
      void (*valDestructor)(void *privdata, void *obj);
} dictType;
ht属性是一个包含两个项的数组，数组中的每个项都是一个dictht哈希表，一般情况下，字典只使用ht[0]哈希表，ht[1]哈希表只会在对ht[0]哈希表进行rehash时使用。
除了ht[1]之外，另一个和rehash有关的属性就是rehashidx，它记录了rehash目前的进度，如果目前没有在进行rehash，那么它的值为-1。

哈希算法

当要将一个新的键值对添加到字典里面时，程序需要先根据键值对的键计算出哈希值和索引值，然后再根据索引值，将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。
Redis计算哈希值和索引值的方法如下：
#使用字典设置的哈希函数，计算键key的哈希值
hash = dict->type->hashFunction(key);
#使用哈希表的sizemask属性和哈希值，计算出索引值
#根据情况不同，
ht[x]可以是ht[0]或者ht[1]
index = hash & dict->ht[x].sizemask;
当字典被用作数据库的底层实现，或者哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。

解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时，我们称这些键发生了冲突（collision）。Redis的哈希表使用链地址法（separate chaining）来解决键冲突，每个哈希表节点都有一个next指针，多个哈希表节点可以用next指针构成一个单向链表，被分配到同一个索引上的多个节点可以用这个单向链表连接起来，这就解决了键冲突的问题。

如图所示,当键k0和k1的经过散列函数得到索引值都为1时，就会使用next指针将两个节点连接起来。因为dictEntry节点组成的链表没有指向链表表尾的指针，所以为了速度考虑，程序总是将新节点添加到链表的表头位置（复杂度为O（1）），排在其他已有节点的前面。

Redis rehash

随着操作的不断执行，哈希表保存的键值对会逐渐地增多或者减少，为了让哈希表的负载因子（load factor）维持在一个合理的范围之内，当哈希表保存的键值对数量太多或者太少时，程序需要对哈希表的大小进行相应的扩展或者收缩以提升性能或节省内存。扩展和收缩哈希表的工作可以通过执行rehash（重新散列）操作来完成，Redis对字典的哈希表执行rehash的步骤如下：

1）为字典的ht[1]哈希表分配空间，这个哈希表的空间大小取决于要执行的操作，以及ht[0]当前包含的键值对数量（也即是ht[0].used属性的值）：

·如果执行的是扩展操作，那么ht[1]的大小为第一个大于等于ht[0].used*2的2 n （2的n次方幂）；
·如果执行的是收缩操作，那么ht[1]的大小为第一个大于等于ht[0].used的2的n次方 。

2）将保存在ht[0]中的所有键值对rehash到ht[1]上面：rehash指的是重新计算键的哈希值和索引值，然后将键值对放置到ht[1]哈希表的指定位置上。

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

举个例子如对上图进行扩展操作：

1）ht[0].used当前的值为4，4*2=8，而8（2的3次方）恰好是第一个大于等于4的2的n次方，所以程序会将ht[1]哈希表的大小设置为8。

2）将ht[0]包含的四个键值对都rehash到ht[1]

3）ht[0]的所有键值对都已经被迁移到ht[1]后，释放ht[0]，并将ht[1]设置为ht[0]，然后为ht[1]分配一个空白哈希表为下一次rehash做准备，如图所示。至此，对哈希表的扩展操作执行完毕，程序成功将哈希表的大小从原来的4改为了现在的8。

完成rehash之后的字典

哈希表的扩展与收缩（什么时候进行自动扩容和收缩）

1）服务器目前没有在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于1。（扩展）

2）服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于5。（扩展）

其中哈希表的负载因子可以通过公式：# 负载因子= 哈希表已保存节点数量 / 哈希表大小 load_factor = ht[0].used / ht[0].size

另一方面，当哈希表的负载因子小于0.1时，程序自动开始对哈希表执行收缩操作。

Redis这么做的目的是基于操作系统创建子进程后写时复制技术，避免不必要的写入操作。

渐进式 rehash

对于rehash我们思考一个问题如果散列表当前大小为 1GB，要想扩容为原来的两倍大小，那就需要对 1GB 的数据重新计算哈希值，并且从原来的散列表搬移到新的散列表。这种情况听着就很耗时，而生产环境中甚至会更大。为了解决一次性扩容耗时过多的情况，可以将扩容操作穿插在插入操作的过程中，分批完成。当负载因子触达阈值之后，只申请新空间，但并不将老的数据搬移到新散列表中。当有新数据要插入时，将新数据插入新散列表中，并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表，都重复上面的过程。经过多次插入操作之后，老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次一次性数据搬移，插入操作就都变得很快了。

哈希表渐进式rehash的详细步骤：

1）为ht[1]分配空间，让字典同时持有ht[0]和ht[1]两个哈希表。

2）在字典中维持一个索引计数器变量rehashidx，并将它的值设置为0，表示rehash工作正式开始。

3）在rehash进行期间，每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1]，当rehash工作完成之后，程序将rehashidx属性的值增一。

4）随着字典操作的不断执行，最终在某个时间点上，ht[0]的所有键值对都会被rehash至ht[1]，这时程序将rehashidx属性的值设为-1，表示rehash操作已完成。

过程如下图：

1.准备开始rehash 2.rehash索引0上的键值对

3.rehash索引1上的键值对 4.rehash索引2上的键值对

5.rehash索引3上的键值对 6.rehash执行完毕

渐进式rehash执行期间的哈希表操作

因为在进行渐进式rehash的过程中，字典会同时使用ht[0]和ht[1]两个哈希表，所以在渐进式rehash进行期间，字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行。例如，要在字典里面查找一个键的话，程序会先在ht[0]里面进行查找，如果没找到的话，就会继续到ht[1]里面进行查找，诸如此类。

另外，在渐进式rehash执行期间，新添加到字典的键值对一律会被保存到ht[1]里面，而ht[0]则不再进行任何添加操作，这一措施保证了ht[0]包含的键值对数量会只减不增，并随着rehash操作的执行而最终变成空表。

操作复杂度

重点回顾

字典被广泛用于实现Redis的各种功能，其中包括数据库和哈希键。
Redis中的字典使用哈希表作为底层实现，每个字典带有两个哈希表，一个平时使用，另一个仅在进行rehash时使用。
当字典被用作数据库的底层实现，或者哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。
哈希表使用链地址法来解决键冲突，被分配到同一个索引上的多个键值对会连接成一个单向链表。
在对哈希表进行扩展或者收缩操作时，程序需要将现有哈希表包含的所有键值对rehash到新哈希表里面，并且这个rehash过程并不是一次性地完成的，而是渐进式地完成的。

三、跳跃表

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。跳跃表支持平均O（logN）、最坏O（N）复杂度的节点查找，还可以通过顺序性操作来批量处理节点。Redis使用跳跃表作为有序集合键的底层实现之一，如果一个有序集合包含的元素数量比较多，又或者有序集合中元素的成员（member）是比较长的字符串时，Redis就会使用跳跃表来作为有序集合键的底层实现。Redis只在两个地方用到了跳跃表，一个是实现有序集合键，另一个是在集群节点中用作内部数据结构。

跳跃表的实现

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

位于图片最左边的是zskiplist结构，该结构包含以下属性：

typedef struct zskiplist { 
   // 表头节点和表尾节点 
   structz skiplistNode  *header, *tail; 
   // 表中节点的数量 
   unsigned long length; 
   // 表中层数最大的节点的层数 int level;
} zskiplist;

header和tail指针分别指向跳跃表的表头和表尾结点，通过这两个指针，程序定位表头节点和表尾结点的复杂度为O(1)。

length记录跳跃表的长度，也即是跳跃表目前包含节点的数量，程序可以在O（1）复杂度内返回跳跃表的长度。（表头节点不计算在内）

level记录目前跳跃表内，层数最大的那个节点的层数，在O（1）复杂度内获取跳跃表中层高最大的那个节点层数量（表头节点不计算在内）

位于zskiplist结构右方的是四个zskiplistNode结构，该结构包含以下属性：

typedef struct zskiplistNode { 
   // 层 
   struct zskiplistLevel 
       { 
           // 前进指针 
           struct zskiplistNode *forward; 
           // 跨度 
           unsigned int span; 
         }  
      level[]; 
      // 后退指针
      struct zskiplistNode *backward; 
      // 分值 
      double score; 
      // 成员对象 
      robj *obj;
} zskiplistNode;

层：跳跃表节点的level数组包含多个元素，每个元素都包含一个指向其他节点的指针，通过这些层加快访问其他节点的速度，层数量越多，访问其他节点的速度越快。每次创建跳跃表节点时，程序根据幂次定律随机生成一个1-32的的值作为level数组的大小，就是层的“高度”。L1、L2、L3等字样标记节点的各个层，L1代表第一层,L2第二层以此类推。每个层都有二个属性：前进指针和跨度。前进指针用于访问位于表尾方向的其他节点，跨度记录前进指针所指向节点和当前节点的距离，跨度越大相距的越远，指向null的跨度都为0，因为他们没有连接任何几点。上图中连线带有数字的箭头代表前进指针，而哪个数字就是跨度。

后退：用于从表尾向表头方向访问节点，因为每个节点只有一个后退指针，所以每次只能后退至前一个节点。节点中用BW字样标记节点的后退指针，他指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。

分值：各个节点中的1.0、2.0和3.0是节点所保存的分值。在跳跃表中，是一个double类型的浮点数，节点按各自所保存的分值从小到大排列。

成员对象：各个节点中的o1、o2和o3是节点所保存的成员对象。点的成员对象（obj属性）是一个指针，它指向一个字符串对象，而字符串对象则保存着一个SDS值。

注意的是：在同一个跳跃表中，各个节点保存的成员对象必须是唯一的，但是多个节点保存的分值却可以是相同的：分值相同的节点将按照成员对象在字典序中的大小来进行排序，成员对象较小的节点会排在前面（靠近表头的方向），而成员对象较大的节点则会排在后面（靠近表尾的方向）。

复杂度

重点回顾

跳跃表是有序集合的底层实现之一。
跳跃表基于单链表加索引的方式实现
跳跃表以空间换时间的方式提升了查找速度
Redis有序集合在节点元素较大或者元素数量较多时使用跳跃表实现
Redis的跳跃表实现由zskiplist和zskiplistNode两个结构组成，其中zskiplist用于保存跳跃表信息（比如表头节点、表尾节点、长度），而zskiplistNode则用于表示跳跃表节点。
每个跳跃表节点的层高都是1至32之间的随机数。
在同一个跳跃表中，多个节点可以包含相同的分值，但每个节点的成员对象必须是唯一的。
跳跃表中的节点按照分值大小进行排序，当分值相同时，节点按照成员对象的大小进行排序。

四、整数集合

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

整数集合的实现

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

typedef struct intset { 
   // 编码方式 
   uint32_t encoding; 
   // 集合包含的元素数量 
   uint32_t length; 
   // 保存元素的数组 
    int8_t contents[];
} intset;

contents数组是整数集合的底层实现：整数集合的每个元素都是contents数组的一个数组项（item），各个项在数组中按值的大小从小到大有序地排列，并且数组中不包含任何重复项。

length属性记录了数组的长度。

虽然intset结构将contents属性声明为int8_t类型的数组，但实际上contents数组并不保存任何int8_t类型的值，contents数组的真正类型取决于encoding属性的值：如果encoding属性的值为INTSET_ENC_INT16，那么contents就是一个int16_t类型的数组，数组里的每个项都是一个int16_t类型的整数值（最小值为-32768，最大值为32767）。如果encoding属性的值为INTSET_ENC_INT32，那么contents就是一个int32_t类型的数组，数组里的每个项都是一个int32_t类型的整数值（最小值为-2147483648，最大值为2147483647）。如果encoding属性的值为INTSET_ENC_INT64，那么contents就是一个int64_t类型的数组，数组里的每个项都是一个int64_t类型的整数值（最小值为-9223372036854775808，最大值为9223372036854775807）。

升级

每当我们要将一个新元素添加到整数集合里面，并且新元素的类型比整数集合现有所有元素的类型都要长时，整数集合需要先进行升级（upgrade），然后才能将新元素添加到整数集合里面。

升级整数集合并添加新元素共分为三步进行：

1）根据新元素的类型，扩展整数集合底层数组的空间大小，并为新元素分配空间。

2）将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素放置到正确的位上，而且在放置元素的过程中，需要继续维持底层数组的有序性质不变。

3）将新元素添加到底层数组里面。

举个例子：

如下图有一个INTSET_ENC_INT16编码的整数集合，集合中包含三个int16_t类型的元素因为每个元素都占用16位空间，所以整数集合底层数组的大小为3*16=48位，下图右侧第一列展示了整数集合的三个元素在这48位里的位置。

现在，假设我们要将类型为int32_t的整数值65535添加到整数集合里面，因为65535的类型int32_t比整数集合当前所有元素的类型都要长，所以在将65535添加到整数集合之前，程序需要先对整数集合进行升级。

升级首先要做的是，根据新类型的长度，以及集合元素的数量（包括要添加的新元素在内），对底层数组进行空间重分配。整数集合目前有三个元素，再加上新元素65535，整数集合需要分配四个元素的空间，因为每个int32_t整数值需要占用32位空间，所以在空间重分配之后，底层数组的大小将是32*4=128位，如下图右侧第二列，虽然程序对底层数组进行了空间重分配，但数组原有的三个元素1、2、3仍然是int16_t类型，这些元素还保存在数组的前48位里面，所以程序接下来要做的就是将这三个元素转换成int32_t类型，并将转换后的元素放置到正确的位上面，而且在放置元素的过程中，需要维持底层数组的有序性质不变。

首先，因为元素3在1、2、3、65535四个元素中排名第三，所以它将被移动到contents数组的索引2位置上，也即是数组64位至95位的空间内，如下图第三列所示。接着，因为元素2在1、2、3、65535四个元素中排名第二，所以它将被移动到contents数组的索引1位置上，也即是数组的32位至63位的空间内，如下图第四列所示。之后，因为元素1在1、2、3、65535四个元素中排名第一，所以它将被移动到contents数组的索引0位置上，即数组的0位至31位的空间内，如下图右侧第五列。然后，因为元素65535在1、2、3、65535四个元素中排名第四，所以它将被添加到contents数组的索引3位置上，也即是数组的96位至127位的空间内，下图右侧最后一列。最后，程序将整数集合encoding属性的值从INTSET_ENC_INT16改为INTSET_ENC_INT32，并将length属性的值从3改为4，设置完成之后的整数集合。因为每次向整数集合添加新元素都可能会引起升级，而每次升级都需要对底层数组中已有的所有元素进行类型转换，所以向整数集合添加新元素的时间复杂度为O（N）。其他类型的升级操作，比如从INTSET_ENC_INT16编码升级为INTSET_ENC_INT64编码，或者从INTSET_ENC_INT32编码升级为INTSET_ENC_INT64编码，升级的过程都和上面展示的升级过程类似。

因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大，所以这个新元素的值要么就大于所有现有元素，要么就小于所有现有元素：在新元素小于所有现有元素的情况下，新元素会被放置在底层数组的最开头（索引0）；在新元素大于所有现有元素的情况下，新元素会被放置在底层数组的最末尾（索引length-1）。

升级的好处

整数集合的升级策略有两个好处，一个是提升整数集合的灵活性，另一个是尽可能地节约内存。

提升灵活性：因为C语言是静态类型语言，为了避免类型错误，我们通常不会将两种不同类型的值放在同一个数据结构里面。例如，我们一般只使用int16_t类型的数组来保存int16_t类型的值，只使用int32_t类型的数组来保存int32_t类型的值，诸如此类。但是，因为整数集合可以通过自动升级底层数组来适应新元素，所以我们可以随意地将int16_t、int32_t或者int64_t类型的整数添加到集合中，而不必担心出现类型错误，这种做法非常灵活。

节约内存：要让一个数组可以同时保存int16_t、int32_t、int64_t三种类型的值，最简单的做法就是直接使用int64_t类型的数组作为整数集合的底层实现。不过这样一来，即使添加到整数集合里面的都是int16_t类型或者int32_t类型的值，数组都需要使用int64_t类型的空间去保存它们，从而出现浪费内存的情况。而整数集合现在的做法既可以让集合能同时保存三种不同类型的值，又可以确保升级操作只会在有需要的时候进行，这可以尽量节省内存。例如，如果我们一直只向整数集合添加int16_t类型的值，那么整数集合的底层实现就会一直是int16_t类型的数组，只有在我们要将int32_t类型或者int64_t类型的值添加到集合时，程序才会对数组进行升级。

降级

整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态。也就是说一旦我们向一个int16_t的整数集合内添加了一个int32_t的元素后，整数集合将升级到int32_t类型。即使后续的操作中我们删除了这个元素，整数集合还是会保持int32_t类型的状态。

复杂度

操作	时间复杂度
创建一个新的整数集合	O(1)
添加指定元素到集合	O(N)
移除指定元素	O(N)
判断指定元素是否在集合中	O(logN) 底层有序，查找通过二分查找所以复杂度为O（logN）
随机返回一个元素	O(1)
取出在指定索引上的元素	O(1)
返回集合包含的元素个数	O(1)
返回集合占用的内存字节数	O(1)

重点回顾

整数集合是集合键的底层实现之一。
整数集合的底层实现为数组，这个数组以有序、无重复的方式保存集合元素，在有需要时，程序会根据新添加元素的类型，改变这个数组的类型。
升级操作为整数集合带来了操作上的灵活性，并且尽可能地节约了内存。
整数集合只支持升级操作，不支持降级操作。

五、压缩列表

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

压缩列表

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

压缩列表的构成

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

下图展示了列表zlbytes属性的值为0x50（十进制80），表示压缩列表的总长为80字节。列表zltail属性的值为0x3c（十进制60），这表示如果我们有一个指向压缩列表起始地址的指针p，那么只要用指针p加上偏移量60，就可以计算出表尾节点entry3的地址。列表zllen属性的值为0x3（十进制3），表示压缩列表包含三个节点。

压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值，其中，字节数组可以是以下三种长度的其中一种：

长度小于等于63（2 6 –1）字节的字节数组；
长度小于等于16383（2 14 –1）字节的字节数组；
长度小于等于4294967295（2 32 –1）字节的字节数组；

而整数值则可以是以下六种长度的其中一种：

4位长，介于0至12之间的无符号整数；
1字节长的有符号整数；
3字节长的有符号整数；
int16_t类型整数；
int32_t类型整数；
int64_t类型整数。

每个压缩列表节点都由previous_entry_length、encoding、content三个部分组成

previous_entry_length：

节点的previous_entry_length属性以字节为单位，记录了压缩列表中前一个节点的长度。previous_entry_length属性的长度可以是1字节或者5字节

如果前一节点的长度小于254字节，那么previous_entry_length属性的长度为1字节：前一节点的长度就保存在这一个字节里面。
如果前一节点的长度大于等于254字节，那么previous_entry_length属性的长度为5字节：其中属性的第一字节会被设置为0xFE（十进制值254），而之后的四个字节则用于保存前一节点的长度。

下图展示展示了一个包含一字节长previous_entry_length属性的压缩列表节点，属性的值为0x05，表示前一节点的长度为5字节。

下图展示了一个包含五字节长previous_entry_length属性的压缩节点，属性的值为0xFE00002766，其中值的最高位字节0xFE表示这是一个五字节长的previous_entry_length属性，而之后的四字节0x00002766（十进制值10086）才是前一节点的实际长度。

因为节点的previous_entry_length属性记录了前一个节点的长度，所以程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址。

举个例子，如果我们有一个指向当前节点起始地址的指针c，那么我们只要用指针c减去当前节点previous_entry_length属性的值，就可以得出一个指向前一个节点起始地址的指针p

压缩列表的从表尾向表头遍历操作就是使用这一原理实现的，只要我们拥有了一个指向某个节点起始地址的指针，那么通过这个指针以及这个节点的previous_entry_length属性，程序就可以一直向前一个节点回溯，最终到达压缩列表的表头节点。

下图展示了一个从表尾节点向表头节点进行遍历的完整过程：

首先，我们拥有指向压缩列表表尾节点entry4起始地址的指针p1（指向表尾节点的指针可以通过指向压缩列表起始地址的指针加上zltail属性的值得出）；
通过用p1减去entry4节点previous_entry_length属性的值，我们得到一个指向entry4前一节点entry3起始地址的指针p2；
通过用p2减去entry3节点previous_entry_length属性的值，我们得到一个指向entry3前一节点entry2起始地址的指针p3；
通过用p3减去entry2节点previous_entry_length属性的值，我们得到一个指向entry2前一节点entry1起始地址的指针p4，entry1为压缩列表的表头节点；
最终，我们从表尾节点向表头节点遍历了整个列表。

encoding：

节点的encoding属性记录了节点的content属性所保存数据的类型以及长度：

一字节、两字节或者五字节长，值的最高位为00、01或者10的是字节数组编码：这种编码表示节点的content属性保存着字节数组，数组的长度由编码除去最高两位之后的其他位记录；
一字节长，值的最高位以11开头的是整数编码：这种编码表示节点的content属性保存着整数值，整数值的类型和长度由编码除去最高两位之后的其他位记录；

content：

节点的content属性负责保存节点的值，节点值可以是一个字节数组或者整数，值的类型和长度由节点的encoding属性决定。

下图展示了一个保存字节数组的节点示例：

编码的最高两位00表示节点保存的是一个字节数组；
编码的后六位001011记录了字节数组的长度11；
content属性保存着节点的值"hello world"。

下图展示了一个保存整数值的节点示例：

编码11000000表示节点保存的是一个int16_t类型的整数值；
content属性保存着节点的值10086。

连锁更新

前面说过，每个节点的previous_entry_length属性都记录了前一个节点的长度，现在，考虑这样一种情况：在一个压缩列表中，有多个连续的、长度介于250字节到253字节之间的节点e1至eN，因为e1至eN的所有节点的长度都小于254字节，所以记录这些节点的长度只需要1字节长的previous_entry_length属性，换句话说，e1至eN的所有节点的previous_entry_length属性都是1字节长的。这时，如果我们将一个长度大于等于254字节的新节点new设置为压缩列表的表头节点，那么new将成为e1的前置节点，如下图。

因为e1的previous_entry_length属性仅长1字节，它没办法保存新节点new的长度，所以程序将对压缩列表执行空间重分配操作，并将e1节点的previous_entry_length属性从原来的1字节长扩展为5字节长。现在，麻烦的事情来了，e1原本的长度介于250字节至253字节之间，在为previous_entry_length属性新增四个字节的空间之后，e1的长度就变成了介于254字节至257字节之间，而这种长度使用1字节长的previous_entry_length属性是没办法保存的。因此，为了让e2的previous_entry_length属性可以记录下e1的长度，程序需要再次对压缩列表执行空间重分配操作，并将e2节点的previous_entry_length属性从原来的1字节长扩展为5字节长。正如扩展e1引发了对e2的扩展一样，扩展e2也会引发对e3的扩展，而扩展e3又会引发对e4的扩展……为了让每个节点的previous_entry_length属性都符合压缩列表对节点的要求，程序需要不断地对压缩列表执行空间重分配操作，直到eN为止。Redis将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新”，下图展示了这一过程。除了添加新节点可能会引发连锁更新之外，删除节点也可能会引发连锁更新。

除了添加新节点可能会引发连锁更新之外，删除节点也可能会引发连锁更新。考虑下图所示的压缩列表，如果e1至eN都是大小介于250字节至253字节的节点，big节点的长度大于等于254字节（需要5字节的previous_entry_length来保存），而small节点的长度小于254字节（只需要1字节的previous_entry_length来保存），那么当我们将small节点从压缩列表中删除之后，为了让e1的previous_entry_length属性可以记录big节点的长度，程序将扩展e1的空间，并由此引发之后的连锁更新。因为连锁更新在最坏情况下需要对压缩列表执行N次空间重分配操作，而每次空间重分配的最坏复杂度为O（N），所以连锁更新的最坏复杂度为O（N 2 ）。要注意的是，尽管连锁更新的复杂度较高，但它真正造成性能问题的几率是很低的：

首先，压缩列表里要恰好有多个连续的、长度介于250字节至253字节之间的节点，连锁更新才有可能被引发，在实际中，这种情况并不多见；
其次，即使出现连锁更新，但只要被更新的节点数量不多，就不会对性能造成任何影响：比如说，对三五个节点进行连锁更新是绝对不会影响性能的；

因为以上原因，ziplistPush等命令的平均复杂度仅为O（N），在实际中，我们可以放心地使用这些函数，而不必担心连锁更新会影响压缩列表的性能。

复杂度

因为ziplistPush、ziplistInsert、ziplistDelete和ziplistDeleteRange四个函数都有可能会引发连锁更新，所以它们的最坏复杂度都是O（N 2）。

重点回顾

压缩列表是一种为节约内存而开发的顺序型数据结构。
压缩列表被用作列表键和哈希键的底层实现之一。
压缩列表可以包含多个节点，每个节点可以保存一个字节数组或者整数值。
添加新节点到压缩列表，或者从压缩列表中删除节点，可能会引发连锁更新操作，但这种操作出现的几率并不高。

部分内容图片取自

作者： Mr于

出处：https://www.cnblogs.com/hunternet/p/9989771.html