Redis的ZSet底层数据结构,ZSet类型全面解析

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: Redis的ZSet底层数据结构,ZSet类型全面解析;应用场景、底层结构、常用命令;压缩列表ZipList、跳表SkipList;B+树与跳表对比,MySQL为什么使用B+树;ZSet为什么用跳表,而不是B+树、红黑树、二叉树

文章目录

一、ZSet有序集合类型

  • 1.1 简介
  • 1.2 应用场景
  • 1.3 底层结构
  • 1.4 ZSet常用命令

二、ZSet底层结构详解

  • 2.1 数据结构

  • 2.2 压缩列表ZipList

  • 2.3 跳表详解

    • 2.3.1 跳表是什么(what)
    • 2.3.2 跳表怎么做的(how)
    • 2.3.3 为什么需要跳表(WHY)/跳表高效的动态插入和删除
    • 2.3.4 ZSet中的跳表
  • 2.4 什么时候采用压缩列表、什么时候采用跳表

三、Redis跳表与MySQL B+树

  • 3.1 对比
  • 3.2 MySQL为什么用B+树,而不是跳表
  • 3.3 ZSet为什么用跳表,而不是B+树/红黑树/二叉树

四、Hash、B+树、跳表的比较

0-1.png

一、ZSet有序集合类型

1.1 简介

详细介绍:Redis五种数据类型、String、List、Set、Hash、ZSet

ZSet(有序集合)即SortedSet,是一个自动根据元素score排序的有序集合。它是一个可排序的set集合,在 Set 的基础上增加了一个权重参数 score,使得集合中的元素能够按 score 进行有序排列。在 Redis 中,有序集合的最大成员数是 2^32 - 1。ZSet具备下列特性:

  • 可排序。根据score值排序,如果多个元素score相同 则会按照字典进行排序
  • 元素不重复,member必须唯一。注意:集合成员是唯一的,但评分可以重复
  • 查询速度快,也可以根据member查询分数

在 Zset 中,集合元素的添加、删除和查找的时间复杂度都是 O(logn),这得益于 Redis 使用跳表SkipList来实现 Zset。

因为ZSet的可排序特性,经常被用来实现排行榜这样的功能。

1-1.png

1.2 应用场景

  • 排行榜应用:有序集合使得我们能够方便地实现排行榜,比如网站的文章排行、学生成绩排行等。
  • 带权重的消息队列:可以通过 score 来控制消息的优先级。
  • 时间线:使用 Zset 来实现时间线功能。例如将发布的消息作为元素、消息的发布时间作为分数,然后用 Zset 来存储和排序所有的消息。你可以很容易地获取到最新的消息,或者获取到任何时间段内的消息。
  • 延时队列:你可以将需要延时处理的任务作为元素,任务的执行时间作为分数,然后使用 Zset 来存储和排序所有的任务。你可以定期扫描 Zset,处理已经到达执行时间的任务。

以上只是 ZSet 的一些常见应用场景,实际上Zset 的应用非常广泛,只要是需要排序和排名功能的场景,都可以考虑使用 ZSet。

1.3 底层结构

ZSet与Java中的TreeSet有些类似,但底层数据结构却差别很大。ZSet中的每一个元素都带有一个score属性,可以基于score属性对元素排序。底层实现有两种方式:当元素较少或总体元素占用空间较少时,使用压缩列表ZipList来实现;当不符合使用压缩列表的条件时,使用跳表SkipList+ 字典hashtable来实现。注意,集合成员是唯一的,但是评分可以重复。

  • Redis ZSet 的底层实现为跳跃列表和哈希表两种,跳跃列表保证了元素的排序和快速的插入性能,哈希表则提供了快速查找的能力。

  • 当元素数量不多时,HT和SkipList的优势不明显,而且更耗内存。因此zset还会采用ZipList结构来节省内存,不过需要同时满足两个条件:

    • 元素数量小于zset_max_ziplist_entries,默认值128
    • 每个元素都小于zset_max_ziplist_value字节,默认值64

1-2.png

1-3.png

1-4.png

补充:ziplist本身没有排序功能,而且没有键值对的概念,因此需要有zset通过编码实现:

  • ZipList是连续内存,因此score和element是紧挨在一起的两个entry,element在前,score在后
  • score越小越接近队首,score越大越接近队尾,按照score值升序排列

1-5.png

注意事项

  1. 有序集合中的元素是唯一的,但分数(score)可以重复。
  2. 插入、删除、查找的时间复杂度都是 O(log(N))。对于获取排名(排行榜)的操作,Redis 有序集合是非常高效的。

1.4 ZSet常用命令

ZSet的常见命令有:

  • ZADD key [NX|XX] [CH] [INCR] score member [score member ...] :添加一个或多个元素到zset ,如果已经存在则更新其score值
  • ZREM key member [member ...] :删除zset中的一个指定元素
  • ZSCORE key member : 获取zset中的指定元素的score值
  • ZRANK key member:获取指定元素在zset 中的排名(从0开始)
  • ZCARD key:获取zset中的元素个数
  • ZCOUNT key min max:统计score值在给定范围内的所有元素的个数
  • ZINCRBY key increment member:让zset中的指定元素自增,步长为指定的increment值
  • ZRANGE key start stop [WITHSCORES]:按返回有序集合中的,下标在 之间的元素(有 WITHSCORES 会显示评分)
  • zrevrange key start stop [WITHSCORES] :
  • ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]:返回score值介于到之间(含两端)的成员,limit offset count即是偏移数目(score从小到大)
  • zrevrangebyscore key max min [WITHSCORES] [LIMIT offset count] :根据score值从大到小排列
  • ZDIFF、ZINTER、ZUNION:求差集、交集、并集

注意:所有的排名默认都是升序,如果要降序则在命令的Z后面添加REV即可,例如:

  • 升序获取sorted set 中的指定元素的排名:ZRANK key member

  • 降序获取sorted set 中的指定元素的排名:ZREVRANK key memeber

127.0.0.1:6379>  zadd zset1 1 first 2 second 3 third 4 four  #往zset添中加一个或多个元素
(integer) 4
127.0.0.1:6379> zrange zset1 0 -1                    #返回有序集合中、下标在<start> <end>之间的元素(有 WITHSCORES 会显示评分)。0 -1 表示所有元素
1) "first"
2) "second"
3) "third"
4) "four"
127.0.0.1:6379> zrevrange zset1 0 -1
1) "four"
2) "third"
3) "second"
4) "first"
127.0.0.1:6379> zscore zset1 third                #获取zset中的third元素的score值
"3"
127.0.0.1:6379> zrank zset1 third                 #返回third在集合中的排名,从0开始
(integer) 2
127.0.0.1:6379> zrevrank zset1 third
(integer) 1
127.0.0.1:6379> zrangebyscore zset1 -inf +inf     #给zset集合中的元素从小到大排序,-inf:负无穷,+inf:正无穷。返回score值介于-inf到+inf之间(含两端)的成员(score从小到大)
1) "first"
2) "second"
3) "third"
4) "four"
127.0.0.1:6379> zrangebyscore zset1 -inf +inf withscores    #从小到大排序并输出键值
1) "first"
2) "1"
3) "second"
4) "2"
5) "third"
6) "3"
7) "four"
8) "4"
127.0.0.1:6379> zrangebyscore zset1 -inf 1 withscores      #指定负无穷到1的范围
1) "first"
2) "1"
127.0.0.1:6379> zrem zset1 four                            #移除zset集合中指定的元素
(integer) 1
127.0.0.1:6379> zcard zset1                                #查看zset集合中元素个数
(integer) 3
127.0.0.1:6379> zrangebyscore zset1 1 2 withscores         #根据score值从小到大排列
1) "first"
2) "1"
3) "second"
4) "2"
127.0.0.1:6379> zrevrangebyscore zset1 2 1 withscores      #根据score值从大到小排列
1) "second"
2) "2"
3) "first"
4) "1"
127.0.0.1:6379> zcount zset1 1 2                           #统计score值在1到2之间的元素个数
(integer) 2

1-6.png

二、ZSet底层结构详解

2.1 数据结构

有序集合Zset底层实现会根据实际情况选择使用压缩列表(ziplist)或者跳跃表(skiplist):当元素较少或总体元素占用空间较少时,使用压缩列表ZipList来实现;当不符合使用压缩列表的条件时,使用跳表SkipList+ 字典hashtable来实现。

  • Redis ZSet 的底层实现为跳跃列表和哈希表两种,跳跃列表保证了元素的排序和快速的插入性能,哈希表则提供了快速查找的能力。

  • 当元素数量不多时,HT和SkipList的优势不明显,而且更耗内存。因此zset还会采用ZipList结构来节省内存,不过需要同时满足两个条件:

    • 元素数量小于zset_max_ziplist_entries,默认值128
    • 每个元素都小于zset_max_ziplist_value字节,默认值64

2-1.png

具体细节可参考本文1.3小节

2.2 压缩列表ZipList

ZipList是一种特殊的“双端链表”(并非链表),由一系列特殊编码的连续内存块组成,像内存连续的数组。可以在任意一端进行压入/弹出操作,并且该操作的时间复杂度为O(1)。

2-2.png

压缩列表 底层数据结构:本质是一个数组,增加了列表长度、尾部偏移量、列表元素个数、以及列表结束标识,有利于快速寻找列表的首尾节点;但对于其他正常的元素,如元素2、元素3,只能一个个遍历,效率仍没有很高效。

2-3.png

2-4.png

属性 类型 长度 说明
zlbytes uint32_t 4字节 一个 4 字节的整数,表示整个压缩列表占用的字节数量,包括 <zlbytes> 自身的大小
zltail uint32_t 4字节 一个 4 字节的整数,记录压缩列表表尾节点距离压缩列表的起始地址有多少字节,通过这个偏移量,可以确定表尾节点的地址
zllen uint16_t 2字节 一个 2 字节的整数,表示压缩列表中的节点数量。最大值为UINT16_MAX(65534),如果超过这个数,此处会记录为65535,但节点的真实数量需要遍历整个压缩列表才能计算出
entry 列表节点 不定 压缩列表中的元素,每个元素都由一个或多个字节组成,节点的长度由节点保存的内容决定。每个元素的第一个字节(又称为"entry header")用于表示这个元素的长度以及编码方式
zlend uint8_t 1字节 一个字节,特殊值0xFF(十进制255),表示压缩列表的结束

2-5.png

注意:

  • 如果查找定位首个元素或最后1个元素,可以通过表头 “zlbytes”、“zltail_offset” 元素快速获取,复杂度是 O(1)。但是查找其他元素时,就没有这么高效了,只能逐个查找下去,比如 entryN 的复杂度就是 O(N)

  • ZipList虽然节省内存,但申请内存必须是连续空间,如果内存占用较多,申请效率较低。

2.3 跳表详解

学习一个新知识,从三方面分析:WHAT、WHY、HOW

2.3.1 跳表是什么(what)

**SkipList(跳表)**首先是链表,在有序链表的基础上,增加了多级索引,通过多级索引位置的转跳,实现了快速查找元素。但与传统链表相比有几点差异:

  • 元素按照升序排列存储
  • 节点可能包含多个指针,指针跨度不同

2-6.png

在 Redis 源码中,跳跃表的结构定义如下:

typedef struct zskiplistNode {
    robj *obj;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned int span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;
  • zskiplistNode 结构体表示跳跃表中的一个节点,包含元素对象(obj)、分数(score)、指向前一个节点的指针(backward)和一个包含多个层的数组(level)。每一层都包含一个指向下一个节点的指针(forward)和一个表示当前节点到下一个节点的跨度(span)。
  • zskiplist 结构体表示一个跳跃表,包含头节点(header)、尾节点(tail)、跳跃表中的节点数量(length)和当前跳跃表的最大层数(level)。

跳表查找、插入和删除操作的时间复杂度都是 O(logN)。

2-7.png

2-8.png

SkipList的特点

  • 跳跃表是一个双向链表,每个节点都包含score和ele值
  • 节点按照score值排序,score值一样则按照ele字典排序
  • 每个节点都可以包含多层指针,层数是1到32之间的随机数
  • 不同层指针到下一个节点的跨度不同,层级越高,跨度越大
  • 增删改查效率与红黑树基本一致,实现却更简单

对于一个单链表来说,即使链表中的数据是有序的,如果我们想要查找某个数据,也必须从头到尾的遍历链表,很显然这种查找效率是十分低效的,时间复杂度为O(n)。

普通链表想查找元素27,只能从链表头部一个个往后遍历,需要遍历6次 才能找到元素27

2-9.png

2.3.2 跳表怎么做的(how)

跳表怎么做的(how):建立多级索引

如建立一级索引

2-10.png

如果觉得慢,可以建立二级索引

2-11.png

当数据量特别大的时候,跳表的时间复杂度为 O(logN)。其本身利用的思想,有点类似于二分法。

2.3.3 为什么需要跳表(WHY)/跳表高效的动态插入和删除

因为普通链表查找一个元素 时间复杂度O(n);而跳表查找的时间复杂度为O(logn),查找速度更快。不仅如此,删除、插入等操作的时间复杂度也是O(logn)

  • 跳表这个动态数据结构,不仅支持查找操作,还支持动态的插入、删除操作,而且插入、删除操作的时间复杂度也是 O(logn)。
  • 对于单纯的单链表,需要遍历每个结点来找到插入的位置。但是对于跳表来说,因为其查找某个结点的时间复杂度是 O(logn),所以这里查找某个数据应该插入的位置,时间复杂度也是 O(logn)。

2.3.4 ZSet中的跳表

SkipList作为ZSet的存储结构,整体存储结构如下图,核心点主要是包括一个dict对象和一个skiplist对象。dict保存key、value,key为元素,value为分值;skiplist保存的有序的元素列表,每个元素包括元素和分值。

2-12.png

上图中 zskiplist 结构包含以下属性:

  • header:指向跳表的表头节点
  • tail:指向跳表的表尾节点
  • level:记录目前跳表内,层数最大的那个节点层数(表头节点的层数不计算在内)
  • length:记录跳表的长度,也就是跳表目前包含节点的数量(表头节点不计算在内)

位于 zskiplist 结构右侧是四个 zskiplistNode 结构,该结构包含以下属性:

  • 层(level):节点中用 L1、L2、L3 等字样标记节点的各个层,L1 代表第一层,L2 代表第二层,以此类推。每个层都带有两个属性:前进指针和跨度。前进指针用于访问位于表尾方向的其它节点,而跨度则记录了前进指针所指向节点和当前节点的距离。
  • 后退(backward)指针:节点中用 BW 字样标识节点的后退指针,它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。
  • 分值(score):各个节点中的 1.0、2.0 和 3.0 是节点所保存的分值。在跳跃表中,节点按各自所保存的分值从小到大排列。
  • 成员对象(obj):各个节点中的 o1、o2 和 o3 是节点所保存的成员对象。

2.4 什么时候采用压缩列表、什么时候采用跳表

什么时候采用压缩列表、什么时候采用跳表呢

  • 有序集合保存的元素数量小于128个
  • 有序集合保存的所有元素的长度小于64字节

上述 1且2的时候,采用压缩列表;否则采用跳表

三、Redis跳表与MySQL B+树

3.1 对比

Redis跳表

3-1.png

3-2.png

B+Tree

3-3.png

MySQL B+树

3-4.png

相比于标准的B+树,InnoDB使用的B+树有如下特点:

  • B+ 树的叶子节点之间是用「双向链表」进行连接,既能向右遍历、也能向左遍历
  • B+ 树点节点内容是数据页,数据页里存放了用户的记录以及各种信息,每个数据页默认大小是 16 KB

区别

MySQL 的 B+ 树、Redis 的跳表都是用于存储有序数据的数据结构,但它们有一些关键的区别,使得它们在不同的场景和用途中各有优势。

  • 结构差异:B+ 树是一种多路搜索树,每个节点可以有多个子节点,而跳表是一种基于链表的数据结构,每个节点只有一个下一个节点,但可以有多个快速通道指向后面的节点。

  • 空间利用率:B+ 树的磁盘读写操作是以页(通常是 4KB)为单位的,每个节点存储多个键值对,可以更好地利用磁盘空间,减少 I/O 操作。而跳表的空间利用率相对较低。

  • 插入和删除操作:跳表的插入和删除操作相对简单,时间复杂度为 O(logN),并且不需要像 B+ 树那样进行复杂的节点分裂和合并操作。

  • 范围查询:B+ 树的所有叶子节点形成了一个有序链表,因此非常适合进行范围查询。而跳表虽然也可以进行范围查询,但效率相对较低。

因此,B+ 树和跳表不能简单地相互替换。在需要大量进行磁盘 I/O 操作和范围查询的场景(如数据库索引)中,B+ 树可能是更好的选择;而在主要进行内存操作,且需要频繁进行插入和删除操作的场景(如 Redis)中,跳表可能更有优势。

3.2 MySQL为什么用B+树,而不是跳表

MySQL是持久化数据库、即存储到磁盘上,因此查询时要求更少磁盘 IO,且 Mysql 是读多写少的场景较多,显然 B+ 树更加适合Mysql。

Redis是直接操作内存的、并不需要磁盘io;而MySQL需要去读取磁盘io,所以MySQL使用b+树的方式去减少磁盘io。B+树原理是 叶子节点存储数据、非叶子节点存储索引,每次读取磁盘页时就会读取一整个节点,每个叶子节点还要指向前后节点的指针,其目的是最大限度地降低磁盘io

数据在内存中读取 耗费时间是磁盘IO读取的百万分之一,而Redis是内存中读取数据、不涉及IO,因此使用了跳表,跳表模型是更快更简单的方式

3.3 ZSet为什么用跳表,而不是B+树/红黑树/二叉树

1)ZSet为什么不用B+树,而用跳表

  • 时间复杂度优势:跳表是一种基于链表的数据结构,可以在O(log n)的时间内进行插入、删除和查找操作。而B树需要维护平衡,操作的时间复杂度较高,通常为O(log n)或者更高。在绝大多数情况下,跳表的性能要优于B树。

  • 简单高效:跳表的实现相对简单,并且容易理解和调试。相比之下,B树的实现相对复杂一些,需要处理更多的情况,例如节点的分裂和合并等操作。

  • 空间利用率高:在关键字比较少的情况下,跳表的空间利用率要优于B树。B树通常需要每个节点存储多个关键字和指针,而跳表只需要每个节点存储一个关键字和一个指针。

  • 并发性能好:跳表的插入和删除操作比B树更加简单,因此在并发环境下更容易实现高性能。在多线程读写的情况下,跳表能够提供较好的并发性能。

总的来说,Redis选择跳表作为有序集合数据结构的底层实现,是基于跳表本身的优点:时间复杂度优势、简单高效、空间利用率高和并发性能好。这使得Redis在处理有序集合的操作时能够获得较好的性能和并发能力。Redis是内存数据库、不存在IO的瓶颈,而B+树纯粹是为了MySQL这种IO数据库准备的。B+树的每个节点的数量都是一个MySQL分区页的大小。

2)ZSet为什么不用红黑树、二叉树

红黑树、二叉树查找一个元素的时间复杂度也是O(logn)

3-5.png

  • ZSet有个核心操作,范围查找:跳表效率比红黑树高,跳表可以做到 logn 时间复杂度内,快速查找,找到区间起点、依次往后遍历即可,但红黑树范围查找的效率没有跳表高(每一层加了指针)
  • 跳表实现比红黑树及平衡二叉树简单、易懂:可以有效控制跳表的索引层级来控制内存的消耗,

四、Hash、B+树、跳表的比较

数据结构 实现原理 key查询方式 查找效率 存储大小 插入、删除效率
Hash 哈希表 支持单key 接近O(1) 小,除了数据没有额外的存储 O(1)
B+树 平衡二叉树扩展而来 单key,范围,分页 O(logn) 除了数据,还多了左右指针,以及叶子节点指针 O(logn),需要调整树的结构,算法比较复杂
跳表 有序链表扩展而来 单key,分页 O(logn) 除了数据,还多了指针,但是每个节点的指针小于<2,所以比B+树占用空间小 O(logn),只用处理链表,算法比较简单

参考

Redis常见面试题:ZSet底层数据结构,SDS、压缩列表ZipList、跳表SkipList

Redis数据结构:Zset类型全面解析

redis的zset底层数据结构,你真的懂了吗?

相关文章
|
18天前
|
存储 消息中间件 NoSQL
Redis数据结构:List类型全面解析
Redis数据结构——List类型全面解析:存储多个有序的字符串,列表中每个字符串成为元素 Eelement,最多可以存储 2^32-1 个元素。可对列表两端插入(push)和弹出(pop)、获取指定范围的元素列表等,常见命令。 底层数据结构:3.2版本之前,底层采用**压缩链表ZipList**和**双向链表LinkedList**;3.2版本之后,底层数据结构为**快速链表QuickList** 列表是一种比较灵活的数据结构,可以充当栈、队列、阻塞队列,在实际开发中有很多应用场景。
|
16天前
|
Dart 安全 编译器
Flutter结合鸿蒙next 中数据类型转换的高级用法:dynamic 类型与其他类型的转换解析
在 Flutter 开发中,`dynamic` 类型提供了灵活性,但也带来了类型安全性问题。本文深入探讨 `dynamic` 类型及其与其他类型的转换,介绍如何使用 `as` 关键字、`is` 操作符和 `whereType&lt;T&gt;()` 方法进行类型转换,并提供最佳实践,包括避免过度使用 `dynamic`、使用 Null Safety 和异常处理,帮助开发者提高代码的可读性和可维护性。
68 1
|
18天前
|
存储 NoSQL Redis
Redis常见面试题:ZSet底层数据结构,SDS、压缩列表ZipList、跳表SkipList
String类型底层数据结构,List类型全面解析,ZSet底层数据结构;简单动态字符串SDS、压缩列表ZipList、哈希表、跳表SkipList、整数数组IntSet
|
2天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
14 2
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
66 0
|
1月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
52 0
|
1月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
59 0
|
1月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
80 0
|
3天前
|
存储 安全 Linux
Golang的GMP调度模型与源码解析
【11月更文挑战第11天】GMP 调度模型是 Go 语言运行时系统的核心部分,用于高效管理和调度大量协程(goroutine)。它通过少量的操作系统线程(M)和逻辑处理器(P)来调度大量的轻量级协程(G),从而实现高性能的并发处理。GMP 模型通过本地队列和全局队列来减少锁竞争,提高调度效率。在 Go 源码中,`runtime.h` 文件定义了关键数据结构,`schedule()` 和 `findrunnable()` 函数实现了核心调度逻辑。通过深入研究 GMP 模型,可以更好地理解 Go 语言的并发机制。
|
15天前
|
消息中间件 缓存 安全
Future与FutureTask源码解析,接口阻塞问题及解决方案
【11月更文挑战第5天】在Java开发中,多线程编程是提高系统并发性能和资源利用率的重要手段。然而,多线程编程也带来了诸如线程安全、死锁、接口阻塞等一系列复杂问题。本文将深度剖析多线程优化技巧、Future与FutureTask的源码、接口阻塞问题及解决方案,并通过具体业务场景和Java代码示例进行实战演示。
36 3

相关产品

  • 云数据库 Tair(兼容 Redis)
  • 推荐镜像

    更多