目录
ZipList名叫压缩链表,但本质不是用链表实现的
ZipList中所有存储长度的数值均采用小端字节序,即低位字节在前,高位字节在后。例如:数值0x1234,采用小端字节序后实际存储值为:0x3412
压缩列表的最大特点,就是它被设计成一种内存紧凑型的数据结构,占用一块连续的内存空间,不仅可以利用 CPU 缓存,而且会针对不同长度的数据,进行相应编码,这种方法可以有效地节省内存开销。
压缩列表结构设计
压缩列表是 Redis 为了节约内存而开发的,它是由连续内存块组成的顺序型数据结构,有点类似于数组。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。
属性 | 类型 | 长度 | 用途 |
---|---|---|---|
zlbytes | uint32_t | 4 字节 | 记录整个压缩列表占用的内存字节数 |
zltail | uint32_t | 4 字节 | 记录压缩列表表尾节点距离压缩列表的起始地址有多少字节,通过这个偏移量,可以确定表尾节点的地址。 |
zllen | uint16_t | 2 字节 | 记录了压缩列表包含的节点数量。 最大值为UINT16_MAX (65534),如果超过这个值,此处会记录为65535,但节点的真实数量需要遍历整个压缩列表才能计算得出。 |
entry | 列表节点 | 不定 | 压缩列表包含的各个节点,节点的长度由节点保存的内容决定。 |
zlend | uint8_t | 1 字节 | 特殊值 0xFF (十进制 255 ),用于标记压缩列表的末端。 |
在压缩列表中,如果我们要查找定位第一个元素和最后一个元素,可以通过表头三个字段(zllen)的长度直接定位,复杂度是 O(1)。而查找其他元素时,就没有这么高效了,只能逐个查找,此时的复杂度就是 O(N) 了,因此压缩列表不适合保存过多的元素。
创建ZipList源码
unsigned char *ziplistNew(void) {
//计算空ziplist的长度并且申请内存
//zlbytes和zltail的类型是32位无符号整数,zllen是16位无符号整数,共10字节
unsigned int bytes = ZIPLIST_HEADER_SIZE+ZIPLIST_END_SIZE;
unsigned char *zl = zmalloc(bytes);
ZIPLIST_BYTES(zl) = intrev32ifbe(bytes);
ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(ZIPLIST_HEADER_SIZE);
//写入节点数量
ZIPLIST_LENGTH(zl) = 0;
//结束标志
zl[bytes-1] = ZIP_END;
return zl;
}
压缩列表节点(entry)结构
ZipList 中的Entry并不像普通链表那样记录前后节点的指针,因为记录两个指针要占用16个字节,浪费内存。而是采用了下面的结构
- previous_entry_length:记录前一节点的长度,占1个或5个字节。(造成连续更新的原因)
<1> 如果前一节点的长度小于254字节,则采用1个字节来保存这个长度值
<2> 如果前一节点的长度大于254字节,则采用5个字节来保存这个长度值,第一个字节为0xfe,后四个字节才是真实长度数据- encoding:编码属性,记录content的数据类型(字符串还是整数)以及长度,占用1个、2个或5个字节
- contents:负责保存节点的数据,可以是字符串或整数
encoding编码属性
ZipListEntry中的encoding编码分为字符串和整数两种:
- encoding是以“00”、“01”或者“10”开头,则证明content是字符串
- encoding是以“11”开头,则证明content是整数,且encoding固定只占用1个字节
字符串
编码 | 编码长度 | 字符串大小 |
---|---|---|
|00pppppp| | 1 bytes | <= 63 bytes |
|01pppppp|qqqqqqqq| | 2 bytes | <= 16383 bytes |
|10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| | 5 bytes | <= 4294967295 bytes |
例如,我们要保存字符串:“ab”和 “bc”,小端字节序存储
整数
编码 | 编码长度 | 整数类型 |
---|---|---|
11000000 | 1 bytes | int16_t(2 bytes) |
11010000 | 1 bytes | int32_t(4 bytes) |
11100000 | 1 bytes | int64_t(8 bytes) |
11110000 | 1 bytes | 24位有符整数(3 bytes) |
11111110 | 1 bytes | 8位有符整数(1 bytes) |
1111xxxx | 1 bytes | 直接在xxxx位置保存数值,范围从0001~1101,减1后结果为实际值 |
如果当前节点的数据是整数,则 encoding 会使用 1 字节的空间进行编码,也就是 encoding 长度为 1 字节。通过 encoding 确认了整数类型,就可以确认整数数据的实际大小了,比如如果 encoding 编码确认了数据是 int16 整数,那么 data 的长度就是 int16 的大小。
连锁更新问题!!!
ZipList的每个Entry都包含previous_entry_length来记录上节点的大小,长度是1个或5个字节:
如果前一节点的长度小于254字节,则采用1个字节来保存这个长度值
如果前一节点的长度大于等于254字节,则采用5个字节来保存这个长度值,第一个字节为0xfe,后四个字节才是真实长度数据
问题情景:现在,假设我们有N个连续的、长度为250~253字节之间的entry,因此entry的previous_entry_length属性用1个字节即可表示,如图所示:
这时,如果将一个长度大于等于 254 字节的新节点加入到压缩列表的表头节点,即新节点将成为 e1 的前置节点,如下图:
因为 e1 节点的 prevlen 属性只有 1 个字节大小,无法保存新节点的长度,此时就需要对压缩列表的空间重分配操作,并将 e1 节点的 prevlen 属性从原来的 1 字节大小扩展为 5 字节大小。此后,多米诺牌的效应就此开始。后面的entry中的prevlen记录前一个entry的大小,都将被迫扩容。
这种在特殊情况下产生的连续多次空间扩展操作就叫做【连锁更新】,就像多米诺牌的效应一样,第一张牌倒下了,推动了第二张牌倒下;第二张牌倒下,又推动了第三张牌倒下....,
压缩列表优缺点
优点:
- 压缩列表的可以看做一种连续内存空间,用于保存的节点数量不多的场景,节省内存空间,查询性能也能得到保证,即使发生连锁更新,也是能接受的。
缺点:
- 如果保存的元素数量增加了,或是元素变大了,会导致内存重新分配,最糟糕的是会有连锁更新的问题
- 数据过多,导致链表过长,可能影响查询性能