跳跃表-zskipList
1.跳跃表概述
跳跃表(skiplist)是一种随机化的数据, 由 William Pugh 在论文《Skip lists: a probabilistic alternative to balanced trees》中提出, 跳跃表以有序的方式在层次化的链表中保存元素, 效率和平衡树媲美 —— 查找、删除、添加等操作都可以在对数期望时间下完成, 并且比起平衡树来说, 跳跃表的实现要简单直观得多。
跳表(skip list)对表的是平衡树(AVL Tree)和 二分查找,是一种 插入/删除/搜索 都是 O(logn) 的数据结构。
以下是个典型的跳跃表例子(图片来自维基百科):
从图中可以看到, 跳跃表主要由以下部分构成:
- 表头(head):负责维护跳跃表的节点指针。
- 跳跃表节点:保存着元素值,以及多个层。
- 层:保存着指向其他元素的指针。高层的指针越过的元素数量大于等于低层的指针,为了提高查找的效率,程序总是从高层先开始访问,然后随着元素值范围的缩小,慢慢降低层次。
- 表尾:全部由
NULL
组成,表示跳跃表的末尾。
2.如何给有序链表加速
一开始就讲跳表肯定是晦涩难懂的,我们已经了解了跳表的基础定义,我们先了解一下有序链表。看看有序链表是如何“加速”的。
有序链表是所有元素以递增或递减方式有序排列的数据结构,其中每个节点都指向下个节点的next指针,最后一个节点的next指针指向NULL。
如上,我们有一个单向有序链表,如果要查询31的元素,需要从第一个元素开始依次向后查询、比较才可以找到,找到顺序为1->8->10->11->20->26->31,共6次比较,时间复杂度为O(N)。有序链表的插入和删除操作都需要先找到合适的位置在修改next指针,修改操作基本不耗费时间,所以插入、删除、修改有序链表的耗时主要在查找元素上。
如何进行简单优化?可以让它的查询时间复杂度变低,也就是加速它的查询。
一般来说这种加速的方式的话,就类似于星际穿越里面这有点玄学,但是你一定要记住一个概念就行了,一维的数据结构要加速的话,经常采用的方式就是升维也就是说变成二维。为什么要多一层维度,因为你多了一个维度之后,就会有多一级的信息在里面,这样多一级的信息就可以帮助你可以很快地得到一维里面你必须挨个走才能走到的那些元素
添加第一级索引
具体我们来看上图,在原始链表的情况下,我们再增加一个维度,也就是在上面再增加一层索引,我们叫做第一级索引,那么第一级索引的话就不是指向它元素的 next 元素了,而是指向它的 next next ,也就是说你可以理解为 next + 1 就行了,所以第一级索引的话就是第一个元素,马上第三个元素、第五个元素、第七个元素。
这里你就会发现如果你要找26的话,我们怎么办?我们这么查找,先查找第一级索引看有没有1 10 26 ,如果有那就说明 26 存在这个链表里面是存在的,说明我们查询到了。
我们再看要查另一个元素,比如说 31,我们怎么走?还是先找第一级,31是大于 1 的,所以后继往后到达 10 索引的值,31 是大于 10 的,继续往后到了 10 ,31 也大 26 的,再继续往后发现 60 大于 31 了。说明 31 是存在于 26 和 60 这两个索引之间的元素里面的,那么这个时候从第一级元素向下走到原始的链表了,从对应的位置挨个找就会发现 31 找到了,说明 31 也是存在的。
添加第二级索引
那么有的朋友可能就会想了,你加一级索引的话,每次相当于步伐加 2 了,但是它的速度的话也就是比原来稍微快了一点,能不能更快呢?
同理可得,在第一级索引的基础上,我们把它当作是一个原始链表一样,往上再加一级索引,也就是说每次针对第一级索引走两步。那么它相等于原始链表相当于每次就走了四步。对不对,就乘于 2,那这样的话,速度就更加高效了。
- 比如我举个例子要查31,先找 1,31 比 1要大,再找 26 ,这时候你会发现 31 也是比 26 大的,所以 26 这里的话就必须向下再走一级索引了,走到第一级索引的 26 来,再类似于之前 26 和 60 之间,然后再走到下一层, 这样一直走下来找到31。
添加多级索引
以此类推,增加多级索引
假设有五级索引的这么一个原始链表,那么我们要查一个元素,比如说要查 62 元素或者中间元素,就类似于下图,一级一级一级一级走下来,最后的话就可以查到我们需要的62这个元素。当然的话你最后查到原始链表,你会发现比如说是我们要查63或者61,原始链表里面没有,我们就说元素不存在,在我们这个有序的链表里面,也就是说在跳表里面查不到这么一个元素。
如果我们将有序链表的部分节点分层,每一层都是一个有序链表。在查找时优先从最高层开始向后查找,当到达某节点时,如果next节点值大于要查找的值或next指针指向NULL,则从当前节点下降一成继续向后查找,这样是否可以提升查询效率呢?
使用分层有序链表,比如我们查找值为31的节点时,查找步骤如下:
- 从最高层第2层开始查找,1节点比31值要小,继续向后比较。
- 10节点比31节点要小,继续向后比较,这时会发现第2层10节点的next指针是指向NULL,所以在10节点就开始需要下降一层到第1层并继续向后查找节点进行比较。
- 在下降到第1层中,10节点的值比31要小,继续向后比较,第1层10节点的next指针指向26,26比31要小,继续向后比较,第1层26节点的next指针指向60,60比31要大,需要下降一层继续向后比较。
- 最后下降到了第0层,第0层的26节点的next指针指向31,31为我们要找的节点,节点被找到。
3.redis跳跃表
为了满足自身的功能需要, Redis 基于 William Pugh 论文中描述的跳跃表进行了以下修改:
- 允许重复的
score
值:多个不同的member
的score
值可以相同。 - 进行对比操作时,不仅要检查
score
值,还要检查member
:当score
值可以重复时,单靠score
值无法判断一个元素的身份,所以需要连member
域都一并检查才行。 - 每个节点都带有一个高度为 1 层的后退指针,用于从表尾方向向表头方向迭代:当执行 ZREVRANGE 或 ZREVRANGEBYSCORE 这类以逆序处理有序集的命令时,就会用到这个属性。
3.1 zskiplist
这个修改版的跳跃表由 redis.h/zskiplist
结构定义:
1 |
|
该结构体属性如下:
- header:指向跳跃表头节点。头节点时跳跃表的特殊节点,他的level是固定数组元素个数为32个,头节点不存储任何score和obj,level也不计入跳跃表的高度,头节点在初始化时,score值为0,ele值为NULL,32个元素的forward值都指向NULL,span为0.
- tail:指向跳跃表尾节点。
- length:跳跃表长度,表示第0层除头节点以外的所有节点总数。
- level:跳跃表高度,除头节点外,其他节点层数最高的即为跳跃表高度。
注意表头节点和其他节点的构造是一样的:表头节点也有后退指针、分值和成员对象,不过表头节点的这些属性都不会被用到。
3.2 zskiplistNode
跳跃表的节点由 redis.h/zskiplistNode
定义:
1 |
|
- score:是一个double类型的浮点数,用户存储有序链表节点的分值,跳跃表中的所有节点都按分值从小到大来排序。
- obj:为节点的成员对象,指向一个字符串对象,而字符串对象则保存着一个SDS值。
- backward:后退指针,用于从从表尾向表头遍历跳跃表访问节点时使用。指向跳跃表当前节点的最底层节点的前一个节点,头节点和第一个节点的backward指向NULL。
- 层(level):为动态柔性数组,数组可以包含多个元素,每个元素都包含一个指向其他节点的指针。每个节点层高不同对应的数组大小也不同,每次创建一个新跳跃表节点的时候,根据幂次定律 (power law,值越大出现的概率越小) 随机生成一个1~32的值,一般来说,层的数量越多,访问其他节点的速度就越快。
这level数组中的每项元素包含以下两个元素:
- forward:指向本层下一个节点,每个层都有一个指向表尾方向的前进指针 (level[i]->forward属性),用于从表头向表尾方向访问节点,尾节点的forward指向NULL。
- span:层的跨度 (level[i]->span属性) 用于记录两个节点之间的距离,即forward指向的节点于本节点之间的元素个数,span值越大,说明跳过的节点个数越多。
以下是操作这两个数据结构的 API ,API 的用途与相应的算法复杂度:
函数 | 作用 | 复杂度 |
---|---|---|
zslCreateNode |
创建并返回一个新的跳跃表节点 | 最坏 O(1) |
zslFreeNode |
释放给定的跳跃表节点 | 最坏 O(1) |
zslCreate |
创建并初始化一个新的跳跃表 | 最坏 O(1) |
zslFree |
释放给定的跳跃表 | 最坏 O(N) |
zslInsert |
将一个包含给定 score 和
member 的新节点添加到跳跃表中 |
最坏 O(N)平均 O(logN) |
zslDeleteNode |
删除给定的跳跃表节点 | 最坏 O(N) |
zslDelete |
删除匹配给定 member 和
score 的元素 |
最坏 O(N) 平均 O(logN) |
zslFirstInRange |
找到跳跃表中第一个符合给定范围的元素 | 最坏 O(N) 平均 O(logN) |
zslLastInRange |
找到跳跃表中最后一个符合给定范围的元素 | 最坏 O(N) 平均 O(logN) |
zslDeleteRangeByScore |
删除 score
值在给定范围内的所有节点 |
最坏 O(N^2) |
zslDeleteRangeByRank |
删除给定排序范围内的所有节点 | 最坏 O(N^2) |
zslGetRank |
返回目标元素在有序集中的排位 | 最坏 O(N) 平均 O(logN) |
zslGetElementByRank |
根据给定排位,返回该排位上的元素节点 | 最坏 O(N) 平均 O(logN) |
Redis 跳跃表默认允许最大的层数是 32,被源码中 ZSKIPLIST_MAXLEVEL 定义。
3.3 redis跳跃表实现
Redis 的跳跃表由 redis.h/zskiplistNode
和
redis.h/zskiplist
两个结构定义, 其中
zskiplistNode
结构用于表示跳跃表节点, 而
zskiplist
结构则用于保存跳跃表节点的相关信息,
比如节点的数量, 以及指向表头节点和表尾节点的指针, 等等。
上图展示了一个跳跃表示zskiplist 结构,该结构包含以下属性:
header
:指向跳跃表的表头节点。tail
:指向跳跃表的表尾节点。level
:记录目前跳跃表内,层数最大的那个节点的层数(表头节点的层数不计算在内)。length
:记录跳跃表的长度,也即是,跳跃表目前包含节点的数量(表头节点不计算在内)。
位于 zskiplist
结构右方的是四个
zskiplistNode
结构, 该结构包含以下属性:
- 层(level):节点中用
L1
、L2
、L3
等字样标记节点的各个层,L1
代表第一层,L2
代表第二层,以此类推。每个层都带有两个属性:前进指针和跨度。前进指针用于访问位于表尾方向的其他节点,而跨度则记录了前进指针所指向节点和当前节点的距离。在上面的图片中,连线上带有数字的箭头就代表前进指针,而那个数字就是跨度。当程序从表头向表尾进行遍历时,访问会沿着层的前进指针进行。 - 后退(backward)指针:节点中用
BW
字样标记节点的后退指针,它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。 - 分值(score):各个节点中的
1.0
、2.0
和3.0
是节点所保存的分值。在跳跃表中,节点按各自所保存的分值从小到大排列。 - 成员对象(obj):各个节点中的
o1
、o2
和o3
是节点所保存的成员对象。
层
跳跃表节点的 level 数组可以包含多个元素,每个元素都包含一个指向其他节点的指针,程序可以通过这些层来加快访问其他节点的速度,一般来说,层的数量越多,访问其他节点的速度就越快。
每次创建一个新跳跃表节点的时候, 程序都根据幂次定律 (power
law,越大的数出现的概率越小) 随机生成一个介于 1
和
32
之间的值作为 level
数组的大小,
这个大小就是层的“高度”。
下图分别展示了三个高度为 1
层、 3
层和
5
层的节点, 因为 C 语言的数组索引总是从 0
开始的, 所以节点的第一层是 level[0]
, 而第二层是
level[1]
, 以此类推。
前进指针
每个层都有一个指向表尾方向的前进指针(level[i].forward
属性), 用于从表头向表尾方向访问节点。
上图用虚线表示出了程序从表头向表尾方向, 遍历跳跃表中所有节点的路径:
- 迭代程序首先访问跳跃表的第一个节点(表头), 然后从第四层的前进指针移动到表中的第二个节点。
- 在第二个节点时, 程序沿着第二层的前进指针移动到表中的第三个节点。
- 在第三个节点时, 程序同样沿着第二层的前进指针移动到表中的第四个节点。
- 当程序再次沿着第四个节点的前进指针移动时, 它碰到一个
NULL
, 程序知道这时已经到达了跳跃表的表尾, 于是结束这次遍历。
跨度
层的跨度(level[i].span
属性)用于记录两个节点之间的距离:
- 两个节点之间的跨度越大, 它们相距得就越远。
- 指向
NULL
的所有前进指针的跨度都为0
, 因为它们没有连向任何节点。
初看上去, 很容易以为跨度和遍历操作有关, 但实际上并不是这样 —— 遍历操作只使用前进指针就可以完成了, 跨度实际上是用来计算排位(rank)的: 在查找某个节点的过程中, 将沿途访问过的所有层的跨度累计起来, 得到的结果就是目标节点在跳跃表中的排位。
举个例子, 如下用虚线标记了在跳跃表中查找分值为 3.0
、
成员对象为 o3
的节点时, 沿途经历的层:
查找的过程只经过了一个层, 并且层的跨度为 3
,
所以目标节点在跳跃表中的排位为 3
。
再举个例子, 如下用虚线标记了在跳跃表中查找分值为 2.0
、
成员对象为 o2
的节点时, 沿途经历的层:
在查找节点的过程中, 程序经过了两个跨度为 1
的节点,
因此可以计算出, 目标节点在跳跃表中的排位为 2 。
后退指针
节点的后退指针(backward
属性)用于从表尾向表头方向访问节点:
跟可以一次跳过多个节点的前进指针不同, 因为每个节点只有一个后退指针,
所以每次只能后退至前一个节点。
上图用虚线展示了如果从表尾向表头遍历跳跃表中的所有节点:
程序首先通过跳跃表的 tail
指针访问表尾节点,
然后通过后退指针访问倒数第二个节点,
之后再沿着后退指针访问倒数第三个节点, 再之后遇到指向 NULL
的后退指针, 于是访问结束。
分值和成员
- 节点的分值(
score
属性)是一个double
类型的浮点数, 跳跃表中的所有节点都按分值从小到大来排序。 - 节点的成员对象(
obj
属性)是一个指针, 它指向一个字符串对象, 而字符串对象则保存着一个 SDS(简单动态字符串) 值。
在同一个跳跃表中, 各个节点保存的成员对象必须是唯一的, 但是多个节点保存的分值却可以是相同的: 分值相同的节点将按照成员对象在字典序中的大小来进行排序, 成员对象较小的节点会排在前面(靠近表头的方向), 而成员对象较大的节点则会排在后面(靠近表尾的方向)。
举个例子, 在下图所示的跳跃表中, 三个跳跃表节点都保存了相同的分值
10086.0
, 但保存成员对象 o1
的节点却排在保存成员对象 o2
和 o3
的节点之前,
而保存成员对象 o2
的节点又排在保存成员对象 o3
的节点之前, 由此可见, o1
、 o2
、
o3
三个成员对象在字典中的排序为
o1 <= o2 <= o3
。
跳跃表
虽然仅靠多个跳跃表节点就可以组成一个跳跃表, 如下图 所示:
但通过使用一个 zskiplist
结构来持有这些节点,
程序可以更方便地对整个跳跃表进行处理,
比如快速访问跳跃表的表头节点和表尾节点,
又或者快速地获取跳跃表节点的数量(也即是跳跃表的长度)等信息,
如下所示:
4. 问题
为啥 redis 使用跳表(skiplist)而不是使用 red-black?
- skiplist的复杂度和红黑树一样,而且实现起来更简单。
- 在并发环境下skiplist有另外一个优势,红黑树在插入和删除的时候可能需要做一些rebalance的操作,这样的操作可能会涉及到整个树的其他部分,而skiplist的操作显然更加局部性一些,锁需要盯住的节点更少,因此在这样的情况下性能好一些。
附:开发者说的为什么选用skiplist The Skip list
There are a few reasons:
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.
5. 总结
- 跳跃表是有序集合的底层实现之一, 除此之外它在 Redis 中没有其他应用。
- Redis 的跳跃表实现由
zskiplist
和zskiplistNode
两个结构组成, 其中zskiplist
用于保存跳跃表信息(比如表头节点、表尾节点、长度), 而zskiplistNode
则用于表示跳跃表节点。 - 每个跳跃表节点的层高都是
1
至32
之间的随机数。 - 在同一个跳跃表中, 多个节点可以包含相同的分值, 但每个节点的成员对象必须是唯一的。
- 跳跃表中的节点按照分值大小进行排序, 当分值相同时, 节点按照成员对象的大小进行排序。
6.Read more
:lollipop::http://redisbook.com/preview/skiplist/datastruct.html
:lollipop::https://juejin.cn/post/689302628126206591496
博客说明
文章所涉及的资料来自互联网整理和个人总结,意在于个人学习和经验汇总,不用于任何的商业用途。如有侵权,请联系本人删除。谢谢!