一些收藏数据结构

深入理解Redis跳跃表的基本实现和特性

2020-11-09  本文已影响0人  一角钱技术

点赞再看，养成习惯，公众号搜一搜【一角钱技术】关注更多原创技术文章。本文 GitHub org_hejianhui/JavaStudy 已收录，有我的系列文章。

前言

在这里我们先回忆一下普通链表的时间复杂度，可以看到除了 look up 操作是 O(n) 的，其他操作都是 O(1) 的时间复杂度。也就是说你需要随机访问里面的任何一个元素的话，它的时间复杂度平均值是 O(n) 的，这也就是链表它的问题所在。从这里可以看到并没有所谓完美的一种数据结构，如果完美那就不需要 Array 或者 LInked List 这两个数据结构并存了，就直接使用最牛逼的数据结构即可。所以相当于各有优劣，看你的使用场景在什么地方，作为完整性比较，我这里把两种时间复杂度都列出来。

Linked List 的时间复杂度

Array 的时间复杂度

注意：正常情况下数组的 prepend 操作的时间复杂度是 O(n) ，但是可以进行特殊优化到 O(1)。采用的方式是申请稍微大一些的内存空间，然后在数组开始预留一部分空间，然后 prepend 的操作则是把头下标前移一个位置即可。

跳表 Skip List

前面回顾了 Array 和 Linked List 的两种结构的时间复杂度，有一种情况下链表它的速度在 O(n) 这一块，就会觉得不太够用，我们来看一下这种情况指的是什么？

链表元素有序的时候


注意是指整个元素，如果是有序的话，在有些时候，比如在数据库里面也好，或者是在其他对一些有序的树进行查询的时候，即使用链表这种方式存储的话，我们发现它的元素是有序的，比如说下面这个升序链表，134578910 它是升序排列的，这个时候我们要快速地查询，比如 9 在什么地方或者查询 5，是不是在这个链表里面出现，这时候你会发现，如果是用普通的数组可以进行二分查找可以很快查到5所在的位置，以及查询到一个元素是否存在。

一个有序的数组里面存在，那么问题来了，如果是有序的，但是是链表的情况下应该怎样有效地加速呢？于是在近代1990年前后，一种新的数据结构出现了，它的名字叫做 跳表。

跳表的特点

注意：只能用于元素有序的情况。

所以，跳表（skip list）对表的是平衡树（AVL Tree）和 二分查找，是一种 插入/删除/搜索 都是 O(log n) 的数据结构。1989 年出现。

不管是平衡树、二叉搜索树其他哪些树的话都是在1960年和196几年就已经出现了，它的出现比平衡树和二分查找以及所谓的一些高级数据结构出现的要晚。比其他的晚了接近30年，最后才出现，这就是为什么很多老的数据结构的话，用平衡二叉树会多一点，而一些比较新的，特别是在元素个数不多的情况的情况下，用的全部都是跳表，也就是说在更新换代了。

它的最大优势是原理简单、容易实现、方便扩展、效率更高。因此在一些热门的项目里用来替代平衡树，如 Redis、LevelDB等。

跳跃表（skiplist）是一种随机化的数据， 由 William Pugh 在论文《Skip lists: a probabilistic alternative to balanced trees》中提出， 跳跃表以有序的方式在层次化的链表中保存元素， 效率和平衡树媲美 —— 查找、删除、添加等操作都可以在对数期望时间下完成， 并且比起平衡树来说， 跳跃表的实现要简单直观得多。

如何给有序的链表加速

假设有一个有序的链表，1 3 4 5 7 8 9 10 这么一个原始的链表。它的时间复杂度查询肯定是 O(n) 的，那么问一下如何优化？如何进行简单优化？可以让它的查询时间复杂度变低，也就是加速它的查询。

我们可以思考一些，如果你来比如说我要很快地查到 7 ，有没有在链表中存在和它的位置在哪儿的话，你能够非常快的查询出来吗？

上面这么一个结构，它是一维的数据结构，现在它是有序了，也就是说我们有附加的信息了，那么如何加速对吧？一般来说这种加速的方式的话，就类似于星际穿越里面这有点玄学，但是你一定要记住一个概念就行了，一维的数据结构要加速的话，经常采用的方式就是升维也就是说变成二维。为什么要多一层维度，因为你多了一个维度之后，就会有多一级的信息在里面，这样多一级的信息就可以帮助你可以很快地得到一维里面你必须挨个走才能走到的那些元素

添加第一级索引

如何提高链表线性查找的效率？



具体我们来看上图，在原始链表的情况下，我们再增加一个维度，也就是在上面再增加一层索引，我们叫做第一级索引，那么第一级索引的话就不是指向它元素的 next 元素了，而是指向它的 next next ，也就是说你可以理解为 next + 1 就行了，所以第一级索引的话就是第一个元素，马上第三个元素、第五个元素、第七个元素。

添加第二级索引

那么有的朋友可能就会想了，你加一级索引的话，每次相当于步伐加 2 了，但是它的速度的话也就是比原来稍微快了一点，能不能更快呢？对你这个想法是非常有道理的，也是很好的。

那么在一级索引的基础上，我们可以再加索引就行了，也就是说同理可得，在第一级索引的基础上，我们把它当作是一个原始链表一样，往上再加一级索引，也就是说每次针对第一级索引走两步。那么它相等于原始链表相当于每次就走了四步。对不对，就乘于 2，那这样的话，速度就更加高效了。

添加多级索引

以此类推，增加多级索引

假设有五级索引的这么一个原始链表，那么我们要查一个元素，比如说要查 62 元素或者中间元素，就类似于下图，一级一级一级一级走下来，最后的话就可以查到我们需要的62这个元素。当然的话你最后查到原始链表，你会发现比如说是我们要查63或者61，原始链表里面没有，我们就说元素不存在，在我们这个有序的链表里面，也就是说在跳表里面查不到这么一个元素，最后也可以得出这样的结论。


跳表查询的时间复杂度分析

跳表的时间复杂度计算

举一个例子，跳表在查询的时候，假设索引的高度：logn，每层索引遍历的结点个数：3，假设要走到第 8 个节点。

每层要遍历的元素总共是3个，所以这里的话 log28 的话，就是它的时间复杂度。最后的话得出证明出来：时间复杂度为log2n。也就是从最朴素的原始链表的话，它的 O(n) 的时间复杂度降到 log2n 的时间复杂度。这已经是一个很大的改进了。假设是1024的话，你会发现原始链表要查1024次最后得到这个元素，那么这里的话就只需要查（2的10次方是1024次）十次这样一个数量级。

现实中跳表的形态

在现实中我们在用跳表的情况下，它会由于这个元素的增加和删除而导致的它的索引的话，有些数它并不是完全非常工整的，最后经过多次改动后，它最后索引有些地方会跨几步，有些地方会少只跨两步，这是因为里面的一些元素会被增加和删除了，而且它的维护成本相对较高，也是说当你增加一个元素，你会把它的索引要更新一遍，你要删除一个元素，也需要把它的索引更新一遍。在这种过程中它在增加和删除的话，它的时间复杂度就会变成 O(logn) 了。

在跳表中查询任意数据的时平均时间复杂度就是 O(logn)。

跳表查询的空间复杂度分析

在这里的话，我们假设它的长度为 n，然后按照之前的例子，每两个节点抽一个做成一个索引的话，那么它的一级索引为二分之 n 对吧。最后如下：

跳跃表的构成

以下是个典型的跳跃表例子：



从图中可以看到， 跳跃表主要由以下部分构成：

Redis 跳跃表的实现

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


上图展示了一个跳跃表示例，位于图片最左边的示 zskiplist 结构，该结构包含以下属性：

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

注意：表头节点和其他节点的构造是一样的： 表头节点也有后退指针、分值和成员对象， 不过表头节点的这些属性都不会被用到， 所以图中省略了这些部分， 只显示了表头节点的各个层。

跳跃表节点

跳跃表节点的实现由 redis.h/zskiplistNode 结构定义：

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

层

跳跃表节点的 level 数组可以包含多个元素，每个元素都包含一个指向其他节点的指针，程序可以通过这些层来加快访问其他节点的速度，一般来说，层的数量越多，访问其他节点的速度就越快。

每次创建一个新跳跃表节点的时候， 程序都根据幂次定律 （power law，越大的数出现的概率越小） 随机生成一个介于 1 和 32 之间的值作为 level 数组的大小， 这个大小就是层的“高度”。

下图分别展示了三个高度为 1 层、 3 层和 5 层的节点， 因为 C 语言的数组索引总是从 0 开始的， 所以节点的第一层是 level[0] ， 而第二层是 level[1] ， 以此类推。

前进指针

每个层都有一个指向表尾方向的前进指针（level[i].forward 属性）， 用于从表头向表尾方向访问节点。


上图用虚线表示出了程序从表头向表尾方向， 遍历跳跃表中所有节点的路径：
  1. 迭代程序首先访问跳跃表的第一个节点（表头）， 然后从第四层的前进指针移动到表中的第二个节点。
  2. 在第二个节点时， 程序沿着第二层的前进指针移动到表中的第三个节点。
  3. 在第三个节点时， 程序同样沿着第二层的前进指针移动到表中的第四个节点。
  4. 当程序再次沿着第四个节点的前进指针移动时， 它碰到一个 NULL ， 程序知道这时已经到达了跳跃表的表尾， 于是结束这次遍历。

跨度

层的跨度（level[i].span 属性）用于记录两个节点之间的距离：

初看上去， 很容易以为跨度和遍历操作有关， 但实际上并不是这样 —— 遍历操作只使用前进指针就可以完成了， 跨度实际上是用来计算排位（rank）的： 在查找某个节点的过程中， 将沿途访问过的所有层的跨度累计起来， 得到的结果就是目标节点在跳跃表中的排位。

举个例子， 如下用虚线标记了在跳跃表中查找分值为 3.0 、 成员对象为 o3 的节点时， 沿途经历的层： 查找的过程只经过了一个层， 并且层的跨度为 3 ， 所以目标节点在跳跃表中的排位为 3 。

再举个例子， 如下用虚线标记了在跳跃表中查找分值为 2.0 、 成员对象为 o2 的节点时， 沿途经历的层： 在查找节点的过程中， 程序经过了两个跨度为 1 的节点， 因此可以计算出， 目标节点在跳跃表中的排位为 2 。

后退指针

节点的后退指针（backward 属性）用于从表尾向表头方向访问节点： 跟可以一次跳过多个节点的前进指针不同， 因为每个节点只有一个后退指针， 所以每次只能后退至前一个节点。


上图用虚线展示了如果从表尾向表头遍历跳跃表中的所有节点： 程序首先通过跳跃表的 tail 指针访问表尾节点， 然后通过后退指针访问倒数第二个节点， 之后再沿着后退指针访问倒数第三个节点， 再之后遇到指向 NULL 的后退指针， 于是访问结束。

分值和成员

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

举个例子， 在下图所示的跳跃表中， 三个跳跃表节点都保存了相同的分值 10086.0 ， 但保存成员对象 o1 的节点却排在保存成员对象 o2 和 o3 的节点之前， 而保存成员对象 o2 的节点又排在保存成员对象 o3 的节点之前， 由此可见， o1 、 o2 、 o3 三个成员对象在字典中的排序为 o1 <= o2 <= o3 。

跳跃表

虽然仅靠多个跳跃表节点就可以组成一个跳跃表， 如下图 所示：


但通过使用一个 zskiplist 结构来持有这些节点， 程序可以更方便地对整个跳跃表进行处理， 比如快速访问跳跃表的表头节点和表尾节点， 又或者快速地获取跳跃表节点的数量（也即是跳跃表的长度）等信息， 如下所示：

zskiplist 结构的定义如下： 
typedef struct zskiplist {

    // 表头节点和表尾节点
    struct zskiplistNode *header, *tail;

    // 表中节点的数量
    unsigned long length;

    // 表中层数最大的节点的层数
    int level;

} zskiplist;

跳跃表API

列出了跳跃表的所有操作 API 。

函数 作用 时间复杂度
zslCreate 创建一个新的跳跃表。 O(1)
zslFree 释放给定跳跃表，以及表中包含的所有节点。 O(N) ， N 为跳跃表的长度。
zslInsert 将包含给定成员和分值的新节点添加到跳跃表中。 平均 O(\log N) ，最坏 O(N) ， N 为跳跃表长度。
zslDelete 删除跳跃表中包含给定成员和分值的节点。 平均 O(\log N) ，最坏 O(N) ， N 为跳跃表长度。
zslGetRank 返回包含给定成员和分值的节点在跳跃表中的排位。 平均 O(\log N) ，最坏 O(N) ， N 为跳跃表长度。
zslGetElementByRank 返回跳跃表在给定排位上的节点。 平均 O(\log N) ，最坏 O(N) ， N 为跳跃表长度。
zslIsInRange 给定一个分值范围（range）， 比如 0 到 15 ， 20 到 28 ，诸如此类， 如果给定的分值范围包含在跳跃表的分值范围之内， 那么返回 1 ，否则返回 0 。 通过跳跃表的表头节点和表尾节点， 这个检测可以用 O(1) 复杂度完成。
zslFirstInRange 给定一个分值范围， 返回跳跃表中第一个符合这个范围的节点。 平均 O(\log N) ，最坏 O(N) 。 N 为跳跃表长度。
zslLastInRange 给定一个分值范围， 返回跳跃表中最后一个符合这个范围的节点。 平均 O(\log N) ，最坏 O(N) 。 N 为跳跃表长度。
zslDeleteRangeByScore 给定一个分值范围， 删除跳跃表中所有在这个范围之内的节点。 O(N) ， N 为被删除节点数量。
zslDeleteRangeByRank 给定一个排位范围， 删除跳跃表中所有在这个范围之内的节点。 O(N) ， N 为被删除节点数量。

面试：为啥 redis 使用跳表(skiplist)而不是使用 red-black？

  1. skiplist的复杂度和红黑树一样，而且实现起来更简单。
  2. 在并发环境下skiplist有另外一个优势，红黑树在插入和删除的时候可能需要做一些rebalance的操作，这样的操作可能会涉及到整个树的其他部分，而skiplist的操作显然更加局部性一些，锁需要盯住的节点更少，因此在这样的情况下性能好一些。

具体可以参考Herb Sutter写的Choose Concurrency-Friendly Data Structures.

另外这篇论文里有更详细的说明和对比，page50~53：
http://www.cl.cam.ac.uk/research/srg/netos/papers/2007-cpwl.pdf

附：开发者说的为什么选用skiplist The Skip list

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

总结

参考资料

文章持续更新，可以公众号搜一搜「 一角钱技术 」第一时间阅读， 本文 GitHub org_hejianhui/JavaStudy 已经收录，欢迎 Star。

上一篇下一篇

猜你喜欢

热点阅读