前言

前面我们已经介绍了Redis的键值对存储管理的底层数据结构。如果不清楚的同志可以看我前面的博客

Redis数据库存储键值对的底层原理-CSDN博客

下面,我们来看一下Redis键值对中值的数据结构有那些叭

Redis常见的5种数据类型

string                                                                                                          动态字符串,可扩容

list列表                                                                                                       压缩列表、双向链表

hash散列                                                                                                    压缩列表、哈希表

set无序唯一集合,可求交集、并集、差集                                                    哈希表

zset有序集合分值排序(分值可以重复) zset不支持差集运算                        压缩列表、跳表

所以,我们常见的Redis键值对中值的数据结构有字符串、双向链表、哈希表、压缩列表和跳表

字符串和双向链表就不需要过多解释,非常常见,哈希表在前面已经解释过了,如果不清楚的同志可以看我的上篇文章

Redis数据库存储键值对的底层原理-CSDN博客

所以我们现在需要重点讲解一下,压缩列表和跳表

压缩列表

压缩列表就是可以理解为是一个数组
与数组不同的是
1、压缩列表存储的是序列化之后的值
2、压缩列表在表头有三个字段,分别是列表字节长度、列表尾节点的字节偏移量、列表中数据的个数,为数组提供高效的尾部数据插入

        我们可以使用表头的三个字段快速访问到数组的第一项数据和最后一项数据,⽽查找其他元素时，就没有这么⾼效了，只能逐个查找

列表尾节点的字节偏移量可以理解为不带最后一项数据的数组字节长度

其中,list列表、hash、set集合、有序集合zset在数据量少的时候使用的就是压缩列表

跳表

有序链表只能逐⼀查找元素，导致操作起来⾮常缓慢，于是就出现了跳表。具体来说，跳表在链表 的基础上，增加了多级索引，通过索引位置的⼏个跳转，实现数据的快速定位

跳表上面的索引也是使用链表做的,比如第0层为有序链表,第1层隔一个节点取一个节点组成链表索引,依次操作,直至最顶层最少为一个节点

优先使用压缩列表原因

数据量少的情况下使用压缩列表的原因

压缩列表本质就是一个带有三个字段表头的数组

1、内存利⽤率,数组和压缩列表都是⾮常紧凑的数据结构,它⽐链表占⽤的内存 要更少

2、Redis是内存数据库,⼤量数据存到内存中,此时需要做尽可能的优化,提⾼内存的利⽤率。

3、数组对CPU⾼速缓存⽀持更友好，所以Redis在设计时，集合数据元素较少情况下， 默认采⽤内存紧凑排列的⽅式存储，同时利⽤CPU⾼速缓存不会降低访问速度。当数据元素超 过设定阈值后，避免查询时间复杂度太⾼，转为哈希和跳表数据结构存储，保证查询效率