2024年大数据最全Redis的五种数据结构分析_redis hash len，超详细讲解

最新推荐文章于 2024-09-19 14:55:13 发布

2401_84185182

最新推荐文章于 2024-09-19 14:55:13 发布

阅读量345

点赞数 5

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84185182/article/details/138620849

版权

程序员专栏收录该内容

116 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

然后会将其再进行封装成为一个list对象(源码adlist.h内)：

Redis中对linkedlist的访问是以NULL值为终点的，因为head节点的prev节点为NULL，tail节点的next节点为NULL。

所以，在Redis3.2之前我们可以得到如下简图：

ziplist

ziplist是为了节省内存而开发的一种压缩列表数据结构，哈希数据类型底层也用到了ziplist。

ziplist是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个ziplist可以包含任意多个entry，而每一个entry又可以保存一个字节数组或者一个整数值。

ziplist和linkedlist最大的区别是ziplist不存储指向上一个节点和下一个节点的指针，存储的是上一个节点的长度和当前节点的长度，牺牲了部分读写性能来换取高效的内存利用率，是一种时间换空间的思想。

ziplist适用于字段个数少和字段值少的场景。

ziplist的组成结构：

关于列表选择使用ziplist编码进行存储，必须满足下面两个条件：

1）列表对象保存的所有字符串元素的长度都小于64字节。

2）列表对象保存的元素数量小于512个。

一旦不满足这两个条件中的任意一个，则会使用linkedlist编码来进行存储

这两个条件可以通过参数list-max-ziplist-value和list-max-ziplist-entries进行修改重新设定

quicklist

在Redis3.2之后，统一用quicklist来存储列表对象，quicklist存储了一个双向列表，每个列表的节点是一个ziplist，所以实际上quicklist就是linkedlist和ziplist的结合。

quicklist内部存储结构，quicklist中每一个节点都是一个quicklistNode对象，其数据结构定义为：

然后各个quicklistNode就构成了一个列表，quicklist：

根据上面两个结构图，可以得到Redis3.2之后列表的简图：

quicklist和原始两种列表的对比

quicklist同样采用了linkedlist的双端列表特性，然后quicklist中的每个节点又是一个ziplist，所以quicklist就是综合平衡考虑了空间碎片和读写性能两个维度。

使用quicklist需要注意以下2点：

1、如果ziplist中的entry个数过少，极端情况就是只有1个entry，此时就相当于退化成了一个普通的linkedlist。

2、如果ziplist中的entry过多，那么也会导致一次性需要申请的内存空间过大，而且因为ziplist本身的就是以时间换空间，所以会过多entry也会影响到列表对象的读写性能。

ziplist中的entry个数可以通过参数list-max-ziplist-size来控制：

list-max-ziplist-size 1

这个参数可以配置正数也可以配置负数。正数表示限制每个节点中的entry数量，如果是负数则只能为-1~-5

-1:每个ziplist最多只能为4KB

-2:每个ziplist最多只能为8KB

-3:每个ziplist最多只能为16KB

-4:每个ziplist最多只能为32KB

-5:每个ziplist最多只能为64KB

Redis Lrange 返回列表中指定区间内的元素，区间以偏移量 START 和 END 指定。其中 0 表示列表的第一个元素，1 表示列表的第二个元素，以此类推。也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，以此类推。

List数据类型应用：

timeline：例如微博的时间轴，有人发布微博，用lpush加入时间轴，展示新的列表信息。

`三、Hash`：哈希表类型

Redis hash 是一个 string 类型的 field（字段）和 value（值）的映射表，hash 特别适合用于存储对象。

Redis 中每个 hash 可以存储 2^32 - 1 键值对（40多亿）

Redis的哈希对象的底层存储可以使用ziplist（压缩列表）和hashtable。

当hash对象可以同时满足以下两个条件时，哈希对象使用ziplist编码

1.哈希对象保存的所有键值对的键和值的字符串长度都小于64字节

2.哈希对象保存的键值对数量小于512个

常见操作命令：

所有hash的命令都是h开头的 hget、hset、hdel等

Hash数据类型应用：

1、缓存：能直观，相比string更节省空间的维护缓存信息，如：用户信息，视频信息等。

`四、Set`：无序集合类型

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据，将一个重复的元素添加到set中将会被忽略。

集合对象的编码可以是 intset 或者 hashtable。

Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)

集合类型也是用来保存多个字符串的元素，但和列表不同的是，集合中：

不允许有重复的元素
集合中的元素是无序的，不能通过索引下标获取元素
支持集合间的操作，可以取多个集合取交集、并集、差集

Set数据类型应用：

1、标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人

2、点赞，或点踩，收藏等，可以放到set中实现

五、Sorted Set

Redis的sorted_set是有序集合，在set的基础上增加score属性用来排序

在redis中，数据类型对应的命令一般以数据类型的首字母开头，但是单词s已经被string类型使用了，所以sorted_set类型的相关命令只能使用26个英文字母中的最后一个字母z来开头，所以sorted_set也被称为zset。

有序集合和集合有着必然的联系，保留了集合不能有重复成员的特性，区别是，有序集合中的元素是可以排序的，它给每个元素设置一个分数，作为排序的依据。

（有序集合中的元素不可以重复，但是score 分数可以重复，就和一个班里的同学学号不能重复，但考试成绩可以相同）。

Sortedset底层存储结构：

Sortedset同时会由两种数据结构支持,ziplist和skiplist

只有同时满足如下条件时，使用的是ziplist，其他时候则是使用skiplist

1）有序集合保存的元素数量小于128个

2）有序集合保存的所有元素的长度小于64字节

当ziplist作为存储结构时候,每个集合元素使用两个紧挨在一起的压缩列表节点来保存,第一个节点保存元素的成员,第二个元素保存元素的分值.

当使用skiplist作为存储结构时,使用skiplist按序保存元素分值,使用dict来保存元素和分值的对应关系

关于skiplist

skiplist本质上是一个list, 它其实是由有序链表发展而来

我们先来看一个有序链表，如下图（最左侧的灰色节点表示一个空的头节点）：

在这样一个链表中，如果我们要查找某个数据，那么需要从头开始逐个进行比较，直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点为止（没找到）。也就是说，时间复杂度为O(n)。同样，当我们要插入新数据的时候，也要经历同样的查找过程，从而确定插入位置

假如我们每相邻两个节点增加一个指针，让指针指向下下个节点，如下图：

这样所有新增加的指针连成了一个新的链表，但它包含的节点个数只有原来的一半（上图中是7, 19, 26）。现在当我们想查找数据的时候，可以先沿着这个新链表进行查找。当碰到比待查数据大的节点时，再回到原来的链表中进行查找。比如，我们想查找23，查找的路径是沿着下图中标红的指针所指向的方向进行的：

1）23首先和7比较，再和19比较，比它们都大，继续向后比较，当23和26比较的时候，比26要小，因此回到下面的链表（原链表），与22比较

2）23比22要大，沿下面的指针继续向后和26比较

3）23比26小，说明待查数据23在原链表中不存在，而且它的插入位置应该在22和26之间

在这个查找过程中，由于新增加的指针，我们不再需要与链表中每个节点逐个进行比较了。需要比较的节点数大概只有原来的一半。

利用同样的方式，我们可以在上层新产生的链表上，继续为每相邻的两个节点增加一个指针，从而产生第三层链表。如下图：

在这个新的三层链表结构上，如果我们还是查找23，那么沿着最上层链表首先要比较的是19，发现23比19大，接下来我们就知道只需要到19的后面去继续查找，从而一下子跳过了19前面的所有节点。可以想象，当链表足够长的时候，这种多层链表的查找方式能让我们跳过很多下层节点，大大加快查找的速度

skiplist正是受这种多层链表的想法的启发而设计出来的。实际上，按照上面生成链表的方式，上面每一层链表的节点个数，是下面一层的节点个数的一半，这样查找过程就非常类似于一个二分查找，使得查找的时间复杂度可以降低到O(log n)。但是，这种方法在插入数据的时候有很大的问题。新插入一个节点之后，就会打乱上下相邻两层链表上节点个数严格的2:1的对应关系。如果要维持这种对应关系，就必须把新插入的节点后面的所有节点（也包括新插入的节点）重新进行调整，这会让时间复杂度重新退化成O(n)，删除数据也有同样的问题。

skiplist为了避免这一问题，它不要求上下相邻两层链表之间的节点个数有严格的对应关系，而是为每个节点随机出一个层数(level)。比如，一个节点随机出的层数是3，那么就把它链入到第1层到第3层这三层链表中。为了表达清楚，下图展示了如何通过一步步地插入操作从而形成一个skiplist的过程：