redis之Zset 底层原理

本文详细解析了Redis中的ZSet数据结构,介绍了ziplist(双向链表形式)和skiplist(跳跃表形式)的编码条件、结构及优缺点,重点讲解了ziplist的内存连续性限制和skiplist的随机层数设计。

Zset 有两种编码格式 , 一种是ziplist(双向链表的形式), skiplist(跳跃表的形式),Zset会根据相应的规则来选择编码格式,

一、ziplist (压缩列表)

1.条件 :

  1. 元素个数小于128个
  2. 元素的长度小于64

ziplist采用的是双向的链表的结构实现, 且是一个特殊的双向链表,为啥特殊呢,因为链表的设计采用了连续的内存空间

2.结构:

在这里插入图片描述

在这里插入图片描述

<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>

zbytes :
整个记录了ziplist占用的字节数 (32位)
ztail :
最后一个数据实体的元素的的偏移量(32位) 这就使得我们能更加快速的找到最后一个元素,它能以O(1)的时间复杂度在表的两端提供push和pop操作
zlen :
数据实体的元素的个数 (16位),当数据量个数超出2^16-1 时,zlen会将16位全部置为1,
这时zlen 不再表示当前ziplist的数据元素个数, 此时要想知道元素个数就只能通过遍历的方式去得到。
zlentry:
ziplist中的数据实体元素
zlend :
ziplist的结束标志位 固定位数值255

不足:
因为内存地址是需要连续的,所以大量的数据的时候不适合,如果是大量的数据的话就会需要大量的连续的内存地址,这可能也是是为啥呀限制,数据超过128后要转出为跳跃表

3.zentry得结构组成

在这里插入图片描述

prerawlen :
前一个数据实体的长度,通过当前地址-prerwalen可以快速的找到前一个数据
len:
当前实体的数据长度
endcoding :
编码格式
data :
实际的数据 <value,score>

二、skiplist (跳跃表)

条件:

当不满足ziplist的条件的时候就会使用skiplist的方式,即不满足(元素个数小于128,数据长度小于64)

skiplist 结构其实由一个 score 跳跃链表 + 一个字典构成
字典中记录了每个score —>对应的value 的地址 ,只要通过跳跃表查到对应的score 就可以 在字典 中根据score 快速找到对应的value

结构:

在这里插入图片描述

与标准的跳跃表不同, 每次插入数据的时候会随机的产生一个层数,因为如果是严格的跳跃表的话,相邻两节点的层高之比固定为2:1, 这样的话就会存在在加入数据的时候,为了保证层高固定比例而必须去调整后面的节点,就会影响查找的效率
产生随机层数的源码:

#define ZSKIPLIST_MAXLEVEL 32 
#define ZSKIPLIST_P 0.25 

int zslRandomLevel(void) {
    int level = 1;
    while ((random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
        level += 1;
    return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}

每一个节点平均的指针数:=1/(1-p)

<think>嗯,用户想知道RedisZSet底层实现结构。我记得ZSet同时使用了跳表(skiplist)和字典(dict)。那这两个结构是怎么配合的呢?首先,跳表是一种有序的数据结构,支持快速查找和范围操作,而字典提供了O(1)时间复杂度的键值查询。这样设计的好处是结合了两种数据结构的优点,既保证了高效的查询,又支持范围操作。 需要确认跳表和字典如何保持数据一致性。根据引用的资料,zset结构里同时包含跳表和字典,元素通过指针共享,所以不会有重复存储的问题。这样内存使用上更高效。 另外,用户可能想知道为什么选择跳表而不是B+树。根据引用[2],跳表的时间复杂度与平衡树相当,但实现更简单,空间利用率更高,且更适合内存数据库。B+树更适合磁盘IO优化的场景,比如MySQL,而Redis作为内存数据库,跳表更适合其需求。 还要解释插入和查询的具体过程。比如插入时,跳表需要找到合适的位置并随机生成层数,字典则更新键值对。查询时,字典直接返回分值,跳表处理范围查询。可能用户会问为什么不用红黑树?跳表的并发性能更好,维护相对简单。 需要确保回答结构清晰,分点说明跳表和字典的作用,结合引用中的信息,说明它们的协同工作原理,以及选择跳表的原因。同时生成相关问题,比如优化方法、对比B+树等,帮助用户深入理解。</think>### Redis ZSet底层数据结构实现原理 RedisZSet(有序集合)通过**跳表(SkipList)**和**字典(Dict)**两种数据结构协同实现,兼顾高效查询和范围操作的需求。以下是具体实现细节: --- #### 1. **数据结构定义** ZSet的定义如下: ```c typedef struct zset { zskiplist *zsl; // 跳表,用于支持范围操作和有序性 dict *dict; // 字典,用于实现O(1)的键值查询 } zset; ``` - **跳表(zskiplist)**:存储有序的元素及其分值(score),支持快速插入、删除和范围查询。 - **字典(dict)**:以元素为键(key)、分值为值(value),提供O(1)时间复杂度的单元素查询。 --- #### 2. **跳表的核心作用** 跳表通过多层链表实现高效的有序操作: - **节点结构**:每个跳表节点包含: ```c typedef struct zskiplistNode { sds ele; // 元素值(字符串) double score; // 分值(用于排序) struct zskiplistNode *backward; // 后退指针 struct zskiplistLevel { struct zskiplistNode *forward; // 前进指针 unsigned long span; // 跨度(用于范围查询优化) } level[]; // 多层索引 } zskiplistNode; ``` - **插入过程**:新节点的层数由**随机算法**生成(如幂次定律),平均时间复杂度为$O(\log n)$[^1]。 - **范围操作**:支持`ZRANGE`、`ZRANK`等命令,时间复杂度为$O(\log n + k)$(k为返回元素数量)[^2]。 --- #### 3. **字典的核心作用** 字典通过哈希表实现快速单元素查询: - **键值对存储**:键为元素(如字符串),值为分值(如浮点数)。 - **查询优化**:例如`ZSCORE`命令直接从字典中获取分值,时间复杂度为$O(1)$。 --- #### 4. **协同工作原理** - **数据一致性**:跳表和字典共享元素值和分值的存储(通过指针引用),避免内存冗余。 - **插入示例**: 1. 向字典中插入键值对`(element, score)`。 2. 向跳表中插入节点,根据`score`排序。 - **删除示例**: 1. 从字典中删除键`element`。 2. 从跳表中删除对应节点。 --- #### 5. **为何选择跳表而非B+树?** - **时间复杂度**:跳表的查询、插入、删除均为$O(\log n)$,与B+树相当。 - **实现复杂度**:跳表无需复杂的旋转或再平衡操作,代码更简单。 - **内存效率**:跳表的索引层通过概率生成,空间利用率更高。 - **适用场景**:B+树适合磁盘IO优化(如数据库),而Redis作为内存数据库,跳表更契合其需求。 --- #### 6. **性能优势** - **范围查询**:跳表的双向链表特性支持快速范围遍历。 - **并发优化**:跳表的分层结构更易实现无锁并发(如Redis 6.0的多线程IO模型)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值