在阅读《Redis设计与实现》的时候,发现它在阐述跳跃表的原理的时候是简略而过,出于对技术的深究性,我决定还是深入理解一下跳表的原理,并整理讲述给大家听
Redis中的跳表
在Redis的有序集合中,它的底层数据结构是跳表+字典,字典用于存储键与值的映射关系,可以在查找键对应的值的时候使时间复杂度降到o(1)。而跳表的数据结构是为了可以实现ZRANGE等范围查询功能,因为跳表在范围查询里面效率非常高,这是为什么呢,下面我们就将一一剖析跳表这一数据结构
从单链表到跳表
对于一个单链表来讲,即便链表中存储的数据是有序的,如果我们要想在其中查找某个数据,也只能从头到尾遍历链表。这样查找效率就会很低,时间复杂度会很高,是O(n)。
建立索引优化
现在假如我们每两个节点提取一个节点建立一个索引,作为该链表的上一层,那么我们的查询效率会大大增加
比如以下的场景,比如在原来的链表中,我们查询9这个节点,需要逐个比较从1->3->6->7->8->9总共比较6个节点。但是假如有新的链表辅助,我们在新链表中从1->6->8->10的时候发现9在8->10这个区间内,所以我们就可以再利用8从原来的链表中进行查询,所以流程为1->6->8->9,总共需要比较4个节点,从而利用消耗空间换时间
假如我们再多建立n层索引,那么我们需要查找的节点将会降低,所以消耗的时间也会降低
在这样的索引情况下,我们只需要按照1->8->9的过程进行查找,总共只需要比较3个节点
随着节点数的增多,跳表实现的效率会大大提升,那么下面我们就研究一下跳表的插入、查询、删除的时间复杂度
插入、查询、删除的时间复杂度
在进行时间复杂度的解析之前,我们需要了解在一个有n个节点的跳表中,总共建立了多个条索引,它们的情况是怎么样的?
如果两个结点会抽出一个结点作为上一级索引的结点,那第一级索引的结点个数大约就是n/2,第二级索引的结点个数大约就是n/4,第三级索引的结点个数大约就是n/8,依次类推,也就是说,第k级索引的结点个数是第k-1级索引的结点个数的1/2,那第k级索引结点的个数就是n/(2^k)。
假设索引有h级,最高级的索引有2个结点。通过上面的公式,我们可以得到n/(2^h)=2,从而求得h=log2(n-1)
如果每一层都要遍历m个结点,那在跳表中查询一个数据的时间复杂度就是O(m*logn),但实际情况是我们每一层的遍历的元素个数不会超过3个。这是因为我们是每两个节点建立一个索引,所以遍历超过3个节点的情况是不存在,如果遍历超过了3个,那就是因为上一层遍历的过程出错了,我们可以看下面的例子:
我们考虑一种情况,就是我们在查找10这个节点时,在L2以1->6->8->10的过程查询,在L2层遍历了4个节点。实际上这种情况是不可能存在的,因为我们在L3的时候已经排除了6这个节点,也就是L3这一层的存在保证了L2这一层只会从8->13这个范围进行遍历,保证了L2遍历的节点个数不会超过3个,所以在每一层中遍历节点超过4个的情况就不可能存在了。
所以可以得出我们的结论,跳跃表查询一个节点的时间复杂度是O(logn)
在解决了查询的问题之后我们来察看一下插入的时间复杂度
在单链表中,一旦定位好要插入的位置,插入结点的时间复杂度为O(1)。但是,这里为了保证原始链表中数据的有序性,我们需要先找到要插入的位置,这个查找操作为o(n),所以在单链表中插入的耗时为o(n)
但是对于跳表来说,我们查找某个结点的的时间复杂度是O(logn),所以这里查找某个数据应该插入的位置,方法也是类似的,时间复杂度也是O(logn)。
但是在插入之后我们还需要维护跳表的索引,假如不更新索引,那么我们的跳表就失去它存在的意义了,还可能会退化成单链表。所以我们需要更新我们的索引。
索引的添加策略:当我们往跳表中插入数据的时候,我们可以选择同时将这个数据插入到部分索引层中。我们通过一个随机函数,来决定将这个结点插入到哪几级索引中,比如随机函数生成了值K,那我们就将这个结点添加到第一级到第K级这K级索引中。
所以我们插入一个节点的时间复杂度也是o(logn)
同样的,删除一个节点情况与插入一个节点的情况是相类似的,我们在寻找对应节点的过程中顺便删除对应的节点,复杂度与查找一个节点的复杂度是一样的,所以删除一个节点的时间复杂度也是o(logn)
那为什么Redis没有用红黑树替代跳跃表实现呢?我认为的原因有以下几个:
- 在Redis中会有大量的范围查询的功能需求,红黑树在范围查找这方面的效率不如跳跃表,所以在范围查询方面使用跳跃表更优
- 红黑树的数据结构更为复杂,红黑树的插入和删除操作可能会引发子树的调整,逻辑复杂,而skiplist的插入和删除只需要修改相邻节点的指针,操作简单又快速
- 一般来说,红黑树每个节点包含2个指针,而skiplist每个节点包含的指针数目平均为1/(1-p),具体取决于参数p的大小。如果像Redis里的实现一样,取p=1/4,那么平均每个节点包含1.33个指针,比平衡树更有优势。