Redis基础知识(学习笔记12--集合的底层实现原理)

1. 两种实现的选择

对于Hash 与 Zset 集合,其底层的实现有两种:压缩表ziplist 和 跳跃表skiplist。着两种实现对于用户来说是透明的,但用户写入不同的数据,系统会自动使用不同的实现。只有同时满足以配置文件redis.conf中相关集合元素数量阈值与元素大小阈值两个条件,使用的就是压缩表,只要有一个条件不满足使用的就是跳跃表skiplist.例如,对于ZSet集合中这两个条件如下:

***集合元素个数小于redis.conf中zset-max-ziplist-entries属性的值,其默认值为128。

***每个集合元素大小都小于redis.conf中zset-max-ziplist-value属性的值,其默认值为64字节。

从配置文件中查看,当然也可以通过命令查看,例如:

查看zset的

> config get zset-*-ziplist-*

查看hash的

> config get hash-*_ziplist-*

2. ziplist

(1) 什么是ziplist

ziplist,通常称为压缩列表,是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构由三部分组成:head、entries 与 end,这三部分在内存上是连续存放的。

(2)head

head又由三部分构成:

***zlbytes:占4个字节,用于存放ziplist列表整体数据结构所占的字节数,包括zlbytes本身的长度。

***zltail:占4个字节,用于存放ziplist中最后一个entry在整个数据结构中的偏移量(字节)。该数据的存在可以快速定位列表的尾entry位置,以方便操作。

***zllen:占有两个字节,用于存放列表包含entry个数。由于其只有16位,所以ziplist最多可以含有的entry个数为2^16-1 =65535个。

(3) entries

entries是真正的列表,由很多的列表元素entry构成。由于不同的元素类型、数值的不同,从而导致每个entry的长度不同。

每个entry由三部分构成:

*** prvelength:该部分用于记录上一个entry的长度,以实现逆序遍历,默认长度为1字节,只要上一个entry的长度<254字节,prvelength就占1字节,否则其会自动扩展为3字节长度。

【为什么是254呢?因为255 是全是1,是end的标识符,需要预留出来;254 是自动扩展的标识符,也是预留的。】

*** encoding:该部分用于标志后面data的具体类型。如果data为整数类型,encoding固定长度为1字节。如果data为字符串类型,则encoding长度可能会是1字节、2字节或5字节。data字符串不同的长度,对应不同的encoding长度。

*** data:真正存储的数据。数据类型只能是整数类型或字符串类型。不同的数据占用的字节长度不同。

(4)end

end 只包含一部分,称为zlend,占1个字节,值固定为255,即二进制全为1,表示一个ziplist列表的结束。

总结

3.listPack

对应ziplist,实现复杂,未来逆序遍历,每个entry中包含一个entry的长度,这样会导致在ziplist中修改或者插入时需要进行级联更新。在高并发的写常见下会极度降低redis的性能。为了实现更紧凑、更快的解析,更简单的实现,重写实现了ziplist,并命名为listPack。

在redis 7.0 中,已经将ziplist全部替换为listPack,但为了兼容性,在配置中也保留了ziplist的相关属性。

>config get zset-max-listpack-*

注意:hash一样。

(1) 什么是listPack

 listPack也是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构也由三部分组成:head、entries 与 end,并且这三部分在内存上也是连续存放的。

listPack 与 ziplist的重大区别在head 与每个entry的结构上,表示列表结束的end与ziplist的zlend是相同的,占一个字节,且8位全为1。

(2)head

head由两部分组成:

***totalBytes:占4个字节,用于存放listPack列表整体数据结构所占的字节数,包括totalBytes本身的长度。

***elemNum:占2个字节,用于存放列表包含的entry个数。其意义与zipList中zllen的相同。

与ziplist的head相比,没有了记录最后一个entry偏移量的zltail。

(3)entries

entries 也是listPack中真正的列表,由很多的列表元素entry构成。由于不同的元素类型、数值的不同,从而导致每个entry的长度不同,但与ziplist的entry结构相比,listPack的entry结构发生了较大变化。

其中最大的变化就是没有了记录前一个entry长度的prvelength,而增加了记录当前entry长度的element-total-len。而这个改变仍然可以实现逆序遍历,但却避免了由于在列表中间修改或插入entry时引发的级联更新。

每个entry仍由三部分构成:

***encoding:该部分用于标志后面的data的具体类型。如果data为整数类型,encoding长度可能会是1、2、3、4、5或9字节。不同的字节长度,其标识位不同。如果data为字符串类型,则encoding长度可能会是1、2或5字节。data字符串不同的长度,对应着不同的encodingc长度。

*** data:正常存储的数据。数据类型只能是整数类型或字符串类型。不同的数据占用的字节长度不通。

***element-total-len:该部分用于记录当前entry的长度,用于实现逆序遍历。由于其特殊的记录方式,使其本身占有的字符数据可能会是1、2、3、4 或5字节。

(4)总结

 4.skiplist

(1) 什么是skiplist

skiplist,跳跃列表,简称跳表,是一种随机化的数据结构,基于并联的链表,实现简单,查找效率较高。简单来说跳表也是链表的一种,只不过它在链表的基础上增加了跳跃功能。也正是这个跳跃功能,使得在查找元素时,能够提供较高的效率。

(2)skipList原理

假设有一个带头尾节点的有序列表。

 在该链表中,如果要查找某个数据,需要从头到尾逐个进行比较,直到找到包含数据的那个节点,或者找到第一个比给定数据大的节点,或者找到最后尾节点,后两种都属于没有找到的情况。同样,当我们需要新插入数据 时候,也要经历同样的查找过程,从而确定插入位置。

为了提升查找效率,在偶数节点上增加一个指针,让其指向下一个偶数节点。

 这样所有偶数节点就连成了一个新的链表(简称高层链表),当然,高层链表包含的节点个数只是原来链表的一半。此时再想查找某个数据时,先沿着高层链表进行查找。当遇到第一个比待查数据大的节点时,立即从该大节点的前一个节点回到原链表中继续进行查找。例如,若想插入一个数据20,则先在(8,19,31,42)的高层链表中查找,找到第一个比20大的节点31,然后再在高层链表中找到31节点的前一个节点19,然后再在原链表中获取到下一个节点值为23。比20大,则20插入到19节点与23节点之间。若插入的是25,比节点23大,则插入到23节点与31节点之间。

该方式明显可以减少比较次数,提高查找效率。如果链表元素较多,为了进一步提升查找效率,可以将原链表构建为三次链表(3的倍数为3级),或更高层级链表。

 (3)存在问题

这种对链表分层级的方式从原理看确实提升了查找效率,但再实际操作时,就出现了问题:由于固定序号的元素拥有固定层级,所以列表元素出现增加或者删除的情况下,会导致列表整体元素层级大调整,但这样势必会大大降低系统性能。并且元素节点越靠前,变动的代价越大。

(4)算法优化

解决方案,每一个节点,它的层级是随机的分配的,这样增加或删除节点,对其它不相邻的节点没有影响。

(5)知识点补充

跳表的结构体源码

*** ele,用于存储该节点的元素

*** score,用于存储节点的分数(节点按照 score 值排序,score 值一样则按照 ele 排序)

*** *backward,指向上一个节点

*** level[] 是实现跳表多层次指针的关键所在,level 数组中的每一个元素代表跳表的一层,比如 leve[0] 就表示第一层,leve[1] 就表示第二层。

zskiplist Level 结构体里定义了指向下一个跳表节点的指针** *forward 和用来记录两个节点之间的距离 span 

 5. quickList

(1) 什么是quickList

quickList,快速列表,quickList本身是一个双向无循环链表,它的每一个节点都是一个zipList,从redis 3.2 版本开始,对于List的底层实现,使用quickList代替了zipList 和 linkedList。

zipList 和 linkedList 都存在有明显不足,而quickList则对它们都进行了改进:吸收了zipList 和 linkedList的优点,避开了它们的不足。

quickList 本质上是 zipList 和 linkedList的混合体。其将linkedList按段切分,每一段使用zipList来紧凑存储若干真正的数据元素,多个zipList之间使用双向指针串接起来。当然,对于每个zipList中最多可存放多大容量的数据元素,在配置文件中通过list-max-ziplist-size属性指定。

【补充:为什么不用linkedlist? 链表的附加空间相对太高,prev 和 next指针就要占去16个字节,另外,每个节点的内存都是单独分配,会加剧内存的碎片化,影响内存的管理效率,所以,后来的新版本的redis对列表数据结构进行了改造,使用uickList 代替了 zipList 和 linkedList。】【ziplist,是连续的,所以插入、删除的是昂贵的,对内存空间需要频繁的申请和释放。】

(2)检索操作

对于list元素的检索,都是以其索引index为依据的。quickList由一个个的zipList构成,每个zipList的zllen中记录的就是当前zipList中包含的entry的个数,即包含的真正数据元素的个数。根据要检索元素的index,从quickList的头节点开始,逐个对zipList的zllen做sum求和,直到找到第一个求和后sum大于index的zipList,那么要检索的这个元素就在这个zipList中,只要遍历这个zipList中的entries 即可。

(3)插入操作

由于ziplist是有大小限制的,所以在quick中插入一个元素在逻辑上相对比较复杂一些。

 (4)删除操作

删除相对简单,检索,删除即可。但是需要考虑的是,如果ziplist只有一个元素,这个要想到删除后,ziplist就不再包含元素了,要进行ziplist的释放。

 6.key 与 value中元素的数量

Redis的各种特殊数据结构的设计,不仅极大提升了Redis的性能,并且还使得Redis可以支持的Key的数量、集合Value中可以支持的元素数量都可以非常庞大。

*** Redis 最多可以处理2^32个key(约42亿),并且在实践中经过测试,每个Redis实例至少可以处理2.5亿个key。

*** 每个Hash、List、Set、ZSet集合都可以包含2^32个元素。

 

学习参阅声明

【Redis视频从入门到高级】

https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】

 

作者:东山絮柳仔原文地址:https://www.cnblogs.com/xuliuzai/p/18276402

%s 个评论

要回复文章请先登录注册