Redis知识梳理(30)[ 跳跃列表 ]

电玩女神 2022-02-03 14:05 186阅读 0赞

Redis 的 zset 是一个复合结构，一方面它需要一个 hash 结构来存储 value 和 score 的对应关系，另一方面需要提供按照 score 来排序的功能，还需要能够指 定 score 的范围来获取 value 列表的功能，这就需要另外一个结构「跳跃列 表」。

![img][]

zset 的内部实现是一个 hash 字典加一个跳跃列表 (skiplist)。hash 结构在讲字 典结构时已经详细分析过了，它很类似于 Java 语言中的 HashMap 结构。本节 我们来讲跳跃列表，它比较复杂，读者要有心理准备。

# 基本结构 #

![img][img 1]

上图就是跳跃列表的示意图，图中只画了四层，Redis 的跳跃表共有 64 层，意 味着最多可以容纳 2^64 次方个元素。每一个 kv 块对应的结构如下面的代码中 的 zslnode 结构，kv header 也是这个结构，只不过 value 字段是 null 值——无效的，score 是 Double.MIN\_VALUE，用来垫底的。kv 之间使用指针串起来形成了双向链表结构，它们是 有序 排列的，从小到大。不同的 kv 层高可 能不一样，层数越高的 kv 越少。同一层的 kv 会使用指针串起来。每一个层元 素的遍历都是从 kv header 出发。

>  struct zslnode \{  
> string value;  
> double score;  
> zslnode\*\[\] forwards; // 多层连接指针  
> zslnode\* backward; // 回溯指针  
> \}  
> struct zsl \{  
> zslnode\* header; // 跳跃列表头指针  
> int maxLevel; // 跳跃列表当前的最高层  
> map<string, zslnode\*> ht; // hash 结构的所有键值对  
> \}

# 查找过程 #

设想如果跳跃列表只有一层会怎样?插入删除操作需要定位到相应的位置节点 (定位到最后一个比「我」小的元素，也就是第一个比「我」大的元素的前一 个)，定位的效率肯定比较差，复杂度将会是 O(n)，因为需要挨个遍历。也许你 会想到二分查找，但是二分查找的结构只能是有序数组。跳跃列表有了多层结构 之后，这个定位的算法复杂度将会降到 O(lg(n))

![img][img 2]

如图所示，我们要定位到那个紫色的 kv，需要从 header 的最高层开始遍历找 到第一个节点 (最后一个比「我」小的元素)，然后从这个节点开始降一层再遍历 找到第二个节点 (最后一个比「我」小的元素)，然后一直降到最底层进行遍历就 找到了期望的节点 (最底层的最后一个比我「小」的元素)。

我们将中间经过的一系列节点称之为「搜索路径」，它是从最高层一直到最底层的每一层最后一个比「我」小的元素节点列表。

有了这个搜索路径，我们就可以插入这个新节点了。不过这个插入过程也不是特别简单。因为新插入的节点到底有多少层，得有个算法来分配一下，跳跃列表使用的是随机算法。

# 随机层数 #

对于每一个新插入的节点，都需要调用一个随机算法给它分配一个合理的层数。 直观上期望的目标是 50% 的 Level1，25% 的 Level2，12.5% 的 Level3，一直 到最顶层 2^-63 ，因为这里每一层的晋升概率是 50%。

> /\* Returns a random level for the new skiplist node we are going to create.
> 
>  *  The return value of this function is between 1 and ZSKIPLIST\_MAXLEVEL
>  *  (both inclusive), with a powerlaw-alike distribution where higher
>  *  levels are less likely to be returned. \*/  
>     int zslRandomLevel(void) \{  
>     int level = 1;  
>     while ((random()&0xFFFF) < (ZSKIPLIST\_P \* 0xFFFF))  
>     level += 1;  
>     return (level<ZSKIPLIST\_MAXLEVEL) ? level : ZSKIPLIST\_MAXLEVEL;  
>     \}

不过 Redis 标准源码中的晋升概率只有 25%，也就是代码中的 ZSKIPLIST\_P 的 值。所以官方的跳跃列表更加的扁平化，层高相对较低，在单个层上需要遍历的 节点数量会稍多一点。

也正是因为层数一般不高，所以遍历的时候从顶层开始往下遍历会非常浪费。跳 跃列表会记录一下当前的最高层数 maxLevel ，遍历时从这个 maxLevel 开始遍 历性能就会提高很多。

# 插入过程 #

下面是插入过程的源码，它稍微有点长，不过整体的过程还是比较清晰的。

>  /\* Insert a new node in the skiplist. Assumes the element does not already  
> \* exist (up to the caller to enforce that). The skiplist takes ownership  
> \* of the passed SDS string ‘ele’. \*/  
> zskiplistNode \*zslInsert(zskiplist \*zsl, double score, sds ele) \{  
> // 存储搜索路径  
> zskiplistNode \*update\[ZSKIPLIST\_MAXLEVEL\], \*x;  
> // 存储经过的节点跨度  
> unsigned int rank\[ZSKIPLIST\_MAXLEVEL\];  
> int i, level;
> 
>  serverAssert(!isnan(score));  
> x = zsl->header;  
> // 逐步降级寻找目标节点，得到「搜索路径」  
> for (i = zsl->level-1; i >= 0; i–) \{  
> /\* store rank that is crossed to reach the insert position */  
> rank\[i\] = i == (zsl->level-1) ? 0 : rank\[i+1\];  
> // 如果score相等，还需要比较value  
> while (x->level\[i\].forward &&  
> (x->level\[i\].forward->score < score ||  
> (x->level\[i\].forward->score == score &&  
> sdscmp(x->level\[i\].forward->ele,ele) < 0)))  
> \{  
> rank\[i\] += x->level\[i\].span;  
> x = x->level\[i\].forward;  
> \}  
> update\[i\] = x;  
> \}  
> // 正式进入插入过程  
> /* we assume the element is not already inside, since we allow duplicated  
> \* scores, reinserting the same element should never happen since the  
> \* caller of zslInsert() should test in the hash table if the element is  
> \* already inside or not. */  
> // 随机一个层数  
> level = zslRandomLevel();  
> // 填充跨度  
> if (level > zsl->level) \{  
> for (i = zsl->level; i < level; i++) \{  
> rank\[i\] = 0;  
> update\[i\] = zsl->header;  
> update\[i\]->level\[i\].span = zsl->length;  
> \}  
> // 更新跳跃列表的层高  
> zsl->level = level;  
> \}  
> // 创建新节点  
> x = zslCreateNode(level,score,ele);  
> // 重排一下前向指针  
> for (i = 0; i < level; i++) \{  
> x->level\[i\].forward = update\[i\]->level\[i\].forward;  
> update\[i\]->level\[i\].forward = x;  
> /* update span covered by update\[i\] as x is inserted here */  
> x->level\[i\].span = update\[i\]->level\[i\].span - (rank\[0\] - rank\[i\]);  
> update\[i\]->level\[i\].span = (rank\[0\] - rank\[i\]) + 1;  
> \}  
> /* increment span for untouched levels \*/  
> for (i = level; i < zsl->level; i++) \{  
> update\[i\]->level\[i\].span++;  
> \}  
> // 重排一下后向指针  
> x->backward = (update\[0\] == zsl->header) ? NULL : update\[0\];  
> if (x->level\[0\].forward)  
> x->level\[0\].forward->backward = x;  
> else  
> zsl->tail = x;  
> zsl->length++;  
> return x;  
> \}

首先我们在搜索合适插入点的过程中将「搜索路径」摸出来了，然后就可以开始创建新节点了，创建的时候需要给这个节点随机分配一个层数，再将搜索路径上的节点和这个新节点通过前向后向指针串起来。如果分配的新节点的高度高于当前跳跃列表的最大高度，就需要更新一下跳跃列表的最大高度。

# 删除过程 #

删除过程和插入过程类似，都需先把这个「搜索路径」找出来。然后对于每个层的相关节点都重排一下前向后向指针就可以了。同时还要注意更新一下最高层数maxLevel 。

# 更新过程 #

当我们调用 zadd 方法时，如果对应的 value 不存在，那就是插入过程。如果这 个 value 已经存在了，只是调整一下 score 的值，那就需要走一个更新的流程。 假设这个新的 score 值不会带来排序位置上的改变，那么就不需要调整位置，直 接修改元素的 score 值就可以了。但是如果排序位置改变了，那就要调整位置。 那该如何调整位置呢?

>  /\* Remove and re-insert when score changes. \*/
> 
>  if (score != curscore) \{  
> zskiplistNode \*node;  
> serverAssert(zslDelete(zs->zsl,curscore,ele,&node));  
> znode = zslInsert(zs->zsl,score,node->ele);
> 
>  /\* We reused the node->ele SDS string, free the node now \* since zslInsert created a new one. \*/  
> node->ele = NULL;  
> zslFreeNode(node);
> 
>  /\* Note that we did not removed the original element from \* the hash table representing the sorted set, so we just \* update the score. */  
> dictGetVal(de) = &znode->score; /* Update score ptr. \*/  
> \*flags |= ZADD\_UPDATED;  
> \}  
> return 1;

一个简单的策略就是先删除这个元素，再插入这个元素，需要经过两次路径搜 索。Redis 就是这么干的。 不过 Redis 遇到 score 值改变了就直接删除再插 入，不会去判断位置是否需要调整，从这点看，Redis 的 zadd 的代码似乎还有 优化空间。关于这一点，读者们可以继续讨论。

# 如果 score 值都一样呢? #

在一个极端的情况下，zset 中所有的 score 值都是一样的，zset 的查找性能会 退化为 O(n) 么?Redis 作者自然考虑到了这一点，所以 zset 的排序元素不只看 score 值，如果 score 值相同还需要再比较 value 值 (字符串比较)。

# 元素排名是怎么算出来的? #

前面我们啰嗦了一堆，但是有一个重要的属性没有提到，那就是 zset 可以获取 元素的排名 rank。那这个 rank 是如何算出来的?如果仅仅使用上面的结构， rank 是不能算出来的。Redis 在 skiplist 的 forward 指针上进行了优化，给每 一个 forward 指针都增加了 span 属性，span 是「跨度」的意思，表示从前一 个节点沿着当前层的 forward 指针跳到当前这个节点中间会跳过多少个节点。 Redis 在插入删除操作时会小心翼翼地更新 span 值的大小。

>  struct zslforward \{  
> zslnode\* item;  
> long span; // 跨度  
> \}  
> struct zsl \{  
> String value;  
> double score;  
> zslforward\*\[\] forwards; // 多层连接指针  
> zslnode\* backward; // 回溯指针  
> \}

这样当我们要计算一个元素的排名时，只需要将「搜索路径」上的经过的所有节 点的跨度 span 值进行叠加就可以算出元素的最终 rank 值。

======================================================================

### Redis对象 ###

Redis对象由`redisObject`结构体表示。

<table> 
 <thead> 
  <tr> 
   <th><code></code>1234567</th> 
   <th><code></code>typedef struct redisObject {unsigned type:4; // 对象的类型，包括 /* Object types <em>/unsigned encoding:4; // 底部为了节省空间，一种type的数据，可以采用不同的存储方式unsigned lru:REDIS_LRU_BITS; /</em> lru time (relative to server.lruclock) */int refcount; // 引用计数void *ptr;} robj;</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

*  Redis中的每个键值对的键和值都是一个redisObject。
 *  共有五种类型的对象：字符串（String）、列表（List）、哈希（Hash）、集合（Set）、有序集合（SortedSet），源码`server.h`如下定义：

<table> 
 <thead> 
  <tr> 
   <th><code></code>123456</th> 
   <th><code></code>/* The actual Redis Object */#define OBJ_STRING 0#define OBJ_LIST 1#define OBJ_SET 2#define OBJ_ZSET 3#define OBJ_HASH 4</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

*  每种类型的对象至少都有两种或以上的编码方式；可以在不同的使用场景上优化对象的使用场景。用`TYPE`命令可查看某个键值对的类型

### 对象编码 ###

Redis目前使用的编码方式：

<table> 
 <thead> 
  <tr> 
   <th><code></code>123456789101112</th> 
   <th><code></code>/* Objects encoding. Some kind of objects like Strings and Hashes can be* internally represented in multiple ways. The ‘encoding’ field of the object* is set to one of this fields for this object.<em>/#define OBJ_ENCODING_RAW /</em> Raw representation <em>/ 简单动态字符串#define OBJ_ENCODING_INT /</em> Encoded as integer <em>/ 整数#define OBJ_ENCODING_HT /</em> Encoded as hash table <em>/ 字典#define OBJ_ENCODING_ZIPLIST /</em> Encoded as ziplist <em>/ 压缩列表#define OBJ_ENCODING_INTSET /</em> Encoded as intset <em>/ 整数集合#define OBJ_ENCODING_SKIPLIST /</em> Encoded as skiplist <em>/ 跳跃表#define OBJ_ENCODING_EMBSTR /</em> Embedded sds string encoding <em>/ embstr编码的简单动态字符串#define OBJ_ENCODING_QUICKLIST /</em> Encoded as linked list of ziplists */</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

本质上，Redis就是基于这些数据结构而构造出一个对象存储系统。redisObject结构体有个ptr指针，指向对象的底层实现数据结构，encoding属性记录对象所使用的编码，即该对象使用什么数据结构作为底层实现。

### zset介绍 ###

有序集合对象的编码可以是`ziplist`或者`skiplist`。同时满足以下条件时使用ziplist编码：

*  元素数量小于128个
 *  所有member的长度都小于64字节

以上两个条件的上限值可通过zset-max-ziplist-entries和zset-max-ziplist-value来修改。

`ziplist`编码的有序集合使用紧挨在一起的压缩列表节点来保存，第一个节点保存member，第二个保存score。ziplist内的集合元素按score从小到大排序，score较小的排在表头位置。

`skiplist`编码的有序集合底层是一个命名为`zset`的结构体，而一个zset结构同时包含一个字典和一个跳跃表。跳跃表按score从小到大保存所有集合元素。而字典则保存着从member到score的映射，这样就可以用O(1)的复杂度来查找member对应的score值。虽然同时使用两种结构，但它们会通过指针来共享相同元素的member和score，因此不会浪费额外的内存。

### zset操作命令 ###

<table> 
 <thead> 
  <tr> 
   <th><code></code>1234567891011121314151617</th> 
   <th><code></code>zadd(key, score, member)：向名称为key的zset中添加元素member，score用于排序。如果该元素已经存在，则根据score更新该元素的顺序。zrem(key, member) ：删除名称为key的zset中的元素memberzincrby(key, increment, member) ：如果在名称为key的zset中已经存在元素member，则该元素的score增加increment；否则向集合中添加该元素，其score的值为incrementzrank(key, member) ：返回名称为key的zset（元素已按score从小到大排序）中member元素的rank（即index，从0开始），若没有member元素，返回“nil”zrevrank(key, member) ：返回名称为key的zset（元素已按score从大到小排序）中member元素的rank（即index，从0开始），若没有member元素，返回“nil”zrange(key, start, end)：返回名称为key的zset（元素已按score从小到大排序）中的index从start到end的所有元素zrevrange(key, start, end)：返回名称为key的zset（元素已按score从大到小排序）中的index从start到end的所有元素zrangebyscore(key, min, max)：返回名称为key的zset中score &gt;= min且score &lt;= max的所有元素 zcard(key)：返回名称为key的zset的基数zscore(key, element)：返回名称为key的zset中元素element的score zremrangebyrank(key, min, max)：删除名称为key的zset中rank &gt;= min且rank &lt;= max的所有元素 zremrangebyscore(key, min, max) ：删除名称为key的zset中score &gt;= min且score &lt;= max的所有元素</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

### **skiplist介绍** ###

跳表(skip List)是一种随机化的数据结构，基于并联的链表，实现简单，插入、删除、查找的复杂度均为O(logN)。简单说来跳表也是链表的一种，只不过它在链表的基础上增加了跳跃功能，正是这个跳跃的功能，使得在查找元素时，跳表能够提供O(logN)的时间复杂度。

先来看一个有序链表，如下图（最左侧的灰色节点表示一个空的头结点）：

![img][img 3]

在这样一个链表中，如果我们要查找某个数据，那么需要从头开始逐个进行比较，直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点为止（没找到）。也就是说，时间复杂度为O(n)。同样，当我们要插入新数据的时候，也要经历同样的查找过程，从而确定插入位置。

假如我们每相邻两个节点增加一个指针，让指针指向下下个节点，如下图：

![img][img 4]

这样所有新增加的指针连成了一个新的链表，但它包含的节点个数只有原来的一半（上图中是7, 19, 26）。现在当我们想查找数据的时候，可以先沿着这个新链表进行查找。当碰到比待查数据大的节点时，再回到原来的链表中进行查找。比如，我们想查找23，查找的路径是沿着下图中标红的指针所指向的方向进行的：

![img][img 5]

*  23首先和7比较，再和19比较，比它们都大，继续向后比较。
 *  但23和26比较的时候，比26要小，因此回到下面的链表（原链表），与22比较。
 *  23比22要大，沿下面的指针继续向后和26比较。23比26小，说明待查数据23在原链表中不存在，而且它的插入位置应该在22和26之间。

在这个查找过程中，由于新增加的指针，我们不再需要与链表中每个节点逐个进行比较了。需要比较的节点数大概只有原来的一半。

利用同样的方式，我们可以在上层新产生的链表上，继续为每相邻的两个节点增加一个指针，从而产生第三层链表。如下图：

![img][img 6]

在这个新的三层链表结构上，如果我们还是查找23，那么沿着最上层链表首先要比较的是19，发现23比19大，接下来我们就知道只需要到19的后面去继续查找，从而一下子跳过了19前面的所有节点。可以想象，当链表足够长的时候，这种多层链表的查找方式能让我们跳过很多下层节点，大大加快查找的速度。

`skiplist`正是受这种多层链表的想法的启发而设计出来的。实际上，按照上面生成链表的方式，上面每一层链表的节点个数，是下面一层的节点个数的一半，这样查找过程就非常类似于一个二分查找，使得查找的时间复杂度可以降低到O(log n)。但是，这种方法在插入数据的时候有很大的问题。新插入一个节点之后，就会打乱上下相邻两层链表上节点个数严格的2:1的对应关系。如果要维持这种对应关系，就必须把新插入的节点后面的所有节点（也包括新插入的节点）重新进行调整，这会让时间复杂度重新蜕化成O(n)。删除数据也有同样的问题。

skiplist为了避免这一问题，它不要求上下相邻两层链表之间的节点个数有严格的对应关系，而是为每个节点随机出一个层数(level)。比如，一个节点随机出的层数是3，那么就把它链入到第1层到第3层这三层链表中。为了表达清楚，下图展示了如何通过一步步的插入操作从而形成一个skiplist的过程：

![img][img 7]

从上面skiplist的创建和插入过程可以看出，每一个节点的层数（level）是随机出来的，而且新插入一个节点不会影响其它节点的层数。因此，插入操作只需要修改插入节点前后的指针，而不需要对很多节点都进行调整。这就降低了插入操作的复杂度。实际上，这是skiplist的一个很重要的特性，这让它在插入性能上明显优于平衡树的方案。这在后面我们还会提到。

skiplist，指的就是除了最下面第1层链表之外，它会产生若干层稀疏的链表，这些链表里面的指针故意跳过了一些节点（而且越高层的链表跳过的节点越多）。这就使得我们在查找数据的时候能够先在高层的链表中进行查找，然后逐层降低，最终降到第1层链表来精确地确定数据位置。在这个过程中，我们跳过了一些节点，从而也就加快了查找速度。

刚刚创建的这个skiplist总共包含4层链表，现在假设我们在它里面依然查找23，下图给出了查找路径：

![img][img 8]

需要注意的是，前面演示的各个节点的插入过程，实际上在插入之前也要先经历一个类似的查找过程，在确定插入位置后，再完成插入操作。

实际应用中的skiplist每个节点应该包含key和value两部分。前面的描述中我们没有具体区分key和value，但实际上列表中是按照key(score)进行排序的，查找过程也是根据key在比较。

执行插入操作时计算随机数的过程，是一个很关键的过程，它对skiplist的统计特性有着很重要的影响。这并不是一个普通的服从均匀分布的随机数，它的计算过程如下：

*  首先，每个节点肯定都有第1层指针（每个节点都在第1层链表里）。
 *  如果一个节点有第i层(i>=1)指针（即节点已经在第1层到第i层链表中），那么它有第(i+1)层指针的概率为p。
 *  节点最大的层数不允许超过一个最大值，记为MaxLevel。

这个计算随机层数的伪码如下所示：

<table> 
 <thead> 
  <tr> 
   <th><code></code>123456</th> 
   <th><code></code>randomLevel()level := 1// random()返回一个[0…1)的随机数while random() &lt; p and level &lt; MaxLevel dolevel := level + 1return level</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

randomLevel()的伪码中包含两个参数，一个是p，一个是MaxLevel。在Redis的skiplist实现中，这两个参数的取值为：

<table> 
 <thead> 
  <tr> 
   <th><code></code>12</th> 
   <th><code></code>p = 1/4MaxLevel = 32</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

### skiplist与平衡树、哈希表的比较 ###

*  skiplist和各种平衡树（如AVL、红黑树等）的元素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做单个key的查找，不适宜做范围查找。所谓范围查找，指的是查找那些大小在指定的两个值之间的所有节点。
 *  在做范围查找的时候，平衡树比skiplist操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就非常简单，只需要在找到小值之后，对第1层链表进行若干步的遍历就可以实现。
 *  平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而skiplist的插入和删除只需要修改相邻节点的指针，操作简单又快速。
 *  从内存占用上来说，skiplist比平衡树更灵活一些。一般来说，平衡树每个节点包含2个指针（分别指向左右子树），而skiplist每个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。如果像Redis里的实现一样，取p=1/4，那么平均每个节点包含1.33个指针，比平衡树更有优势。
 *  查找单个key，skiplist和平衡树的时间复杂度都为O(log n)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近O(1)，性能更高一些。所以我们平常使用的各种Map或dictionary结构，大都是基于哈希表实现的。
 *  从算法实现难度上来比较，skiplist比平衡树要简单得多。

### Redis中的skiplist实现 ###

skiplist的数据结构定义：

<table> 
 <thead> 
  <tr> 
   <th><code></code>123456789101112131415161718</th> 
   <th><code></code>#define ZSKIPLIST_MAXLEVEL 32#define ZSKIPLIST_P 0.25typedef struct zskiplistNode {robj *obj;double score;struct zskiplistNode *backward;struct zskiplistLevel {struct zskiplistNode *forward;unsigned int span;} level[];} zskiplistNode;typedef struct zskiplist {struct zskiplistNode *header, *tail;unsigned long length;int level;} zskiplist;</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

简单分析一下几个查询命令：

*  zrevrank由数据查询它对应的排名，这在前面介绍的skiplist中并不支持。
 *  zscore由数据查询它对应的分数，这也不是skiplist所支持的。
 *  zrevrange根据一个排名范围，查询排名在这个范围内的数据。这在前面介绍的skiplist中也不支持。
 *  zrevrangebyscore根据分数区间查询数据集合，是一个skiplist所支持的典型的范围查找（score相当于key，数据相当于value）。

实际上，Redis中sorted set的实现是这样的：

*  当数据较少时，sorted set是由一个ziplist来实现的。
 *  当数据多的时候，sorted set是由一个dict + 一个skiplist来实现的。简单来讲，dict用来查询数据到分数的对应关系，而skiplist用来根据分数查询数据（可能是范围查找）。

看一下sorted set与skiplist的关系，：

*  zscore的查询，不是由skiplist来提供的，而是由那个dict来提供的。
 *  为了支持排名(rank)，Redis里对skiplist做了扩展，使得根据排名能够快速查到数据，或者根据分数查到数据之后，也同时很容易获得排名。而且，根据排名的查找，时间复杂度也为O(log n)。
 *  zrevrange的查询，是根据排名查数据，由扩展后的skiplist来提供。
 *  zrevrank是先在dict中由数据查到分数，再拿分数到skiplist中去查找，查到后也同时获得了排名。

总结起来，Redis中的skiplist跟前面介绍的经典的skiplist相比，有如下不同：

*  分数(score)允许重复，即skiplist的key允许重复。这在最开始介绍的经典skiplist中是不允许的。
 *  在比较时，不仅比较分数（相当于skiplist的key），还比较数据本身。在Redis的skiplist实现中，数据本身的内容唯一标识这份数据，而不是由key来唯一标识。另外，当多个元素分数相同的时候，还需要根据数据内容来进字典排序。
 *  第1层链表不是一个单向链表，而是一个双向链表。这是为了方便以倒序方式获取一个范围内的元素。
 *  在skiplist中可以很方便地计算出每个元素的排名(rank)。

### Redis为什么用skiplist而不用平衡树？ ###

<table> 
 <thead> 
  <tr> 
   <th><code></code>1234567</th> 
   <th><code></code>There are a few reasons:1) They are not very memory intensive. It’s up to you basically. Changing parameters about the probability of a node to have a given number of levels will make then less memory intensive than btrees.2) A sorted set is often target of many ZRANGE or ZREVRANGE operations, that is, traversing the skip list as a linked list. With this operation the cache locality of skip lists is at least as good as with other kind of balanced trees.3) They are simpler to implement, debug, and so forth. For instance thanks to the skip list simplicity I received a patch (already in Redis master) with augmented skip lists implementing ZRANK in O(log(N)). It required little changes to the code.</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

这里从内存占用、对范围查找的支持和实现难易程度这三方面总结的原因。

[img]: /images/20220203/48231bb7e469432dadd3763ef00658a8.png
[img 1]: /images/20220203/2b2773a3ac6443398fa2dba0acbe8cb9.png
[img 2]: /images/20220203/1df4afab116a49d1a247f89901f6e67f.png
[img 3]: /images/20220203/3e7e67c9a4804afaa187ac52af8c0818.png
[img 4]: /images/20220203/57c400c9f7df4fd7abb24c3594af3517.png
[img 5]: /images/20220203/bc58f49960a3499a95fa4212057f7350.png
[img 6]: /images/20220203/f753fb2fbf4541108f2f7026c0a1e0e1.png
[img 7]: /images/20220203/6baa41353a754d3398563748cb174797.png
[img 8]: /images/20220203/1b3615dc3bd2461fbc8e559ee2a5c53a.png