redis有序集合zset的底层实现——跳跃表skiplist

关注

原创最新推荐文章于 2026-10-19 13:15:21 发布 1.9k 阅读 AI 写同款· GEO 优化 ›

Redis 为什么这么快？ Redis 的有序集合 zset 的底层实现原理是什么？ —— 跳跃表 skiplist Redis有序集合 zset 的底层实现——跳跃表skiplist Redis简介 Redis是一个开源的内存中的数据结构存储系统，它可以用作：数据库、缓存和消息中间件。它支持多种类型的数据结构，如字符串（Strings），散列（Hash），列表（List），集合（Set），有序集合（Sorted Set或者是ZSet）与范围查询，Bitmaps，Hyperloglogs 和地理空间... 阅读详情

何为跳表？

跳表是一个随机化的数据结构，实质就是一种可以进行二分查找的有序链表。

跳表在原有的有序链表上面增加了多级索引，通过索引来实现快速查找。

跳表不仅能提高搜索性能，同时也可以提高插入和删除操作的性能。

跳表详解

有序链表

考虑一个有序链表，我们要查找3、7、17这几个元素，我们只能从头开始遍历链表，直到查找到元素为止。

上述这个链表是有序的，但是不能使用二分查找，是不是很捉急？（P.S.数组可以实现二分查找）

那么，有没有什么方法可以实现有序链表的二分查找呢？

答案是肯定的，那就是我们将要介绍的这种数据结构——跳表。

跳表的演进

我们把一些节点从有序表中提取出来，缓存一级索引，就组成了下面这样的结构：

现在，我们要查找17这个元素是不是要快很多呢？

我们只要从一级索引往后遍历即可，只需要经过1、6、15、17这几个元素就可以找到17了。

那么，我们要查找11这个元素呢？

我们从一级索引的1开始，向右到6，再向右发现是15，它比11大，此路不通，从6往下走，再从下面的6往右走，到7，再到11。

同样地，一级索引也可以往上再提取一层，组成二级索引，如下：

这时候我们再查找17这个元素呢？

只需要经过6、15、17这几个元素就可以找到17了。

这基本上就是跳表的核心思想了，其实这也是一个“空间换时间”的算法，通过向上提取索引增加了查找的效率。

跳表的插入

上面讲的都是跳表的查询，那么，该如何向跳表中插入元素呢？

比如，我们要向上面这个跳表添加一个元素8。

首先，我们先根据投硬币的方式，决定8这个元素要占据的层数，没错就是扔硬币，是不是很好玩儿^^

比如，层数level=2。

然后，找到8这个元素在下面两层的前置节点。

接着，就是链表的插入元素操作了，比较简单。

最后，就像下面这样：

跳表的删除

查询、插入元素都讲了，下面我们就来说说怎么删除元素。

首先，找到各层中包含元素x的节点。

然后，使用标准的链表删除元素的方法删除即可。

比如，要删除17这个元素。

标准化的跳表

上面举的例子是完全随机的跳表，那么，如果我们每两个元素提取一个元素作为上一级的索引会怎么样呢？

这是不是很像*衡二叉树，现在这颗树元素比较少，可能不太明显，我们来看个元素个数多的情况。

可以看到，上一级元素的个数是下一级的一半，这样每次减少一半，就很接**衡二叉树了。

时间复杂度

我们知道单链表查询的时间复杂度为O(n)，而插入、删除操作需要先找到对应的位置，所以插入、删除的时间复杂度也是O(n)。

那么，跳表的时间复杂度是多少呢？

如果按照标准的跳表来看的话，每一级索引减少k/2个元素（k为其下面一级索引的个数），那么整个跳表的高度就是(log n)。

学习过*衡二叉树的同学都知道，它的时间复杂度与树的高度成正比，即O(log n)。

所以，这里跳表的时间复杂度也是O(log n)。（这里不一步步推倒了，只要记住，查询时每次减少一半的元素的时间复杂度都是O(log n)，比如二叉树的查找、二分法查找、归并排序、快速排序）

空间复杂度

我们还是以标准的跳表来分析，每两个元素向上提取一个元素，那么，最后额外需要的空间就是：

n/2 + n/(2^2) + n/(2^3) + ... + 8 + 4 + 2 = n - 2

所以，跳表的空间复杂度是O(n)。

总结

（1）跳表是可以实现二分查找的有序链表；

（2）每个元素插入时随机生成它的level；

（3）最低层包含所有的元素；

（4）如果一个元素出现在level(x)，那么它肯定出现在x以下的level中；

（5）每个索引节点包含两个指针，一个向下，一个向右；

（6）跳表查询、插入、删除的时间复杂度为O(log n)，与*衡二叉树接*；

redis作为一种内存KV数据库，提供了string, hash, list, set, zset等多种数据结构。其中有序集合zset在增删改查的性质上类似于C++ stl的map和Java的TreeMap，提供了一组“键-值”对，并且“键”按照“值”的顺序排序。但是与C++ stl或Java的红黑树实现不同的是，redis中有序集合的实现采用了另一种数据结构——跳跃表。跳跃表是有序单链表的一种改进，其查询、插入、删除也是O(logN)的时间复杂度。

跳跃表的原理

跳跃表的思想来自于一篇论文：Skip Lists: A Probabilistic Alternative to Balanced Trees. 如果想要深入了解跳跃表，可以阅读论文原文。这里引用论文中的一幅图对跳跃表的原理作一个简单的说明。

在这里插入图片描述

上图用a,b,c,d,e五种有序链表及其变式（变式的名字是我随便起的）说明了跳跃表的motivation.

[a]单链表：查询时间复杂度O(n)
[b]level-2单链表：每隔一个节点为一个level-2节点，每个level-2节点有2个后继指针，分别指向单链表中的下一个节点和下一个level-2节点。查询时间复杂度为O(n/2)
[c]level-3单链表：每隔一个节点为一个level-2节点，每隔4个节点为一个level-3节点，查询时间复杂度O(n/4)
[d]指数式单链表：每2^i个节点的level为i+1，查询时间复杂度为O(log2N)
[e]跳跃表：各个level的节点个数同指数式单链表，但出现的位置随机，查询复杂度仍然是O(log2N)吗

之所以这里关心查询复杂度，因为有序链表的插入和删除复杂度等于查询复杂度。

作为一种概率性算法，文章证明了跳跃表查询复杂度的期望是O(logN).

redis有序集合采用跳跃表的原因

为什么redis的有序集合采用跳跃表而不是红黑树呢？对于这个问题，可以在https://news.ycombinator.com/item?id=1171423找到作者本人的一个回答

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.
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.
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.

About the Append Only durability & speed, I don’t think it is a good idea to optimize Redis at cost of more code and more complexity for a use case that IMHO should be rare for the Redis target (fsync() at every command). Almost no one is using this feature even with ACID SQL databases, as the performance hint is big anyway.

About threads: our experience shows that Redis is mostly I/O bound. I’m using threads to serve things from Virtual Memory. The long term solution to exploit all the cores, assuming your link is so fast that you can saturate a single core, is running multiple instances of Redis (no locks, almost fully scalable linearly with number of cores), and using the “Redis Cluster” solution that I plan to develop in the future.

可以看到redis选择跳跃表而非红黑树作为有序集合实现方式的原因并非是基于并发上的考虑，因为redis是单线程的，选用跳跃表的原因仅仅是因为跳跃表的实现相较于红黑树更加简洁。

redis跳跃表的源码

跳跃表节点，跳跃表和zset结构体的定义在server.h

/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;

typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

skiplist相关函数定义在t_zset.c中。跳跃表中，一个节点的level符合一定的概率，决定一个新增节点的level的函数是zslRandomLevel

/* 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选择使用跳表而不是红黑树来实现有序集合？

首先，我们来分析下Redis的有序集合支持的操作：

1）插入元素

2）删除元素

3）查找元素

4）有序输出所有元素

5）查找区间内所有元素

其中，前4项红黑树都可以完成，且时间复杂度与跳表一致。

但是，最后一项，红黑树的效率就没有跳表高了。

在跳表中，要查找区间的元素，我们只要定位到两个区间端点在最低层级的位置，然后按顺序遍历元素就可以了，非常高效。

而红黑树只能定位到端点后，再从首位置开始每次都要查找后继节点，相对来说是比较耗时的。

此外，跳表实现起来很容易且易读，红黑树实现起来相对困难，所以Redis选择使用跳表来实现有序集合。

【Redis】拼多多面试官问我zset底层是如何实现的，我反手就把跳表的数据结构画了出

普通链表是一个节点一个节点按顺序的排序，而跳表是为每个节点随机出一个层数，每一层指向的节点可能会不同。
并且，越高层的链表节点数越少。这样查找的话，会从高层开始查找，一层一层往下找，最终在第一层找出其精准位置。
这样的查找方式可以跳过很多下层节点数，大大加快查找速度。
而对于插入和删除等，也只需要修改对应节点前后指针而已，这就比平衡树更有优势。

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

REDIS - 跳跃表与压缩列表
 【最完整系列】Redis-结构篇-压缩列表（压缩列表看这个）Redis的配置文件中关于有序集合底层实现的两个配置。
1、zset-max-ziplist-entries 128:zset采用压缩列表时，元素个数最大值。默认值为128。
2、zset-max-ziplist-value 64:zset采用压缩列表时，每个元素的字符串长度最大值。默认值为64。

当满足以下任一条件时，Redis便会将zset的底层实现由压缩列表转为跳跃表。
1、zset中元素个数大于zset_max_ziplist_entries；
2、插入元素的字符串长度大于zset_max_ziplist_value。
zset在转为跳跃表之后，即使元素被逐渐删除，也不会重新转为压缩列表。

压缩列表ziplist本质上就是一个字节数组，是Redis为了节约内存而设计的一种线性数据结构，可以包含多个元素，每个元素可以是一个字节数组或一个整数。

因为ziplist是紧凑存储，没有冗余空间，意味着新插入元素，就需要扩展内存：
1、分配新的内存，将原数据拷贝到新内存；
2、扩展原有内存;
所以ziplist 不适合存储大型字符串，存储的元素也不宜过多。

收录于