redis数据结构- 压缩列表

皮皮特的AI工厂
495 阅读8分钟

「这是我参与2022首次更文挑战的第26天，活动详情查看：2022首次更文挑战」。

1. 介绍

居左压缩列表(ziplist)是哈希键的底层实现之一。它是经过特殊编码的双向链表，和整数集合(intset)一样，是为了提高内存的存储效率而设计的。当保存的对象是小整数值，或者是长度较短的字符串，那么redis就会使用压缩列表来作为哈希键的实现。

键入一个只包含短字符串和小整数值的hashmap,查看建对象的编码,就会看到他的编码实际上使用的是压缩列表

image.png

键入一个只包含短字符串和小整数值的列表,查看建对象的编码,就会看到他的编码实际上使用的是压缩列表

注: redis版本为3.0.6 image.png

但是在redis 3.2以后，quicklist作为列表键的实现底层实现之一，代替了压缩列表。

注: redis版本为4.0.9 image.png

2.压缩列表的结构

压缩列表是Redis为了节约内存开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构. 一个压缩列表可以包含任意多个节点(entry), 每个节点可以保存一个字节数组或者一个整数值.

压缩列表的各个组成部分如下图所示:

image.png

  • zlbytes: 占用4字节, 记录整个压缩列表占用的字节数
  • zltail: 占用4字节,记录压缩列表表尾节点距离压缩列表的起始地址有多少字节,通过这个偏移量可以定位表尾节点的地址
  • zllen: 占用2字节, 几句了压缩列表包含的节点数量,当节点数量小于65535时适用, 大于65535需要遍历列表
  • entryX: 压缩列表的各个节点
  • zlend: 占用1字节, 值为0xFF,标记压缩列表末端

压缩列表的数据结构如下:

struct ziplist<T> {
 
    int32 zlbytes;
 
    int32 zltail_offset;
 
    int16 zllength;
 
    T[] entries;
 
    int8 zlend;
 
}

3.压缩列表节点的构成

每个压缩列表可以保存一个字节数组或者一个整数值,其中,字节数组可以是以下三种长度的一种:

  • 长度小于等于63字节的字节数组
  • 长度小于等于16383字节的字节数组
  • 长度小于等于4294967295字节的字节数组

而整数值可以是以下六种长度的其中一种:

  • 4位长,介于0至12之间的无符号整数
  • 1字节长的有符号整数
  • 3字节长的有符号整数
  • int16_t
  • int32_t
  • int64_t

每个压缩列表都由previous_entry_len、encoding、content三个部分组成,如下图所示,接下来看一下这三个组成部分

image.png

3.1 previous_entry_len

节点的previous_entry_len属性以字节为单位,记录了压缩列表中前一节点的长度,previous_entry_len 属性的长度可以是1字节或者5字节:

  • 如果前一节点的长度小于254字节,那么previous_entry_len属性的长度为1字节,前一节点的长度就会保存在这一个字节里面
  • 如果前一节点的长度大于等于254字节,那么previous_entry_len属性的长度为5字节,其中属性的第一字节会被设置成0xFE(十进制值254),而后的4个字节则用于保存前一节点的长度 因为节点的previous_entry_len属性记录了前一个节点的长度,所以程序可以通过指针运算,根据当前节点的起始地址来计算出前一个节点的起始地址.

压缩列表的从表尾向表达的遍历操作就是使用这一原理实现的,只要我们拥有了一个指向某个节点起始地址的指针,那么通过这个指针以及这个节点的previous_entry_len属性,程序就可以一直向前一个节点回溯,最终达到压缩列表的表头节点.

3.2 encoding

节点的encoding属性记录了节点的content属性所保存数据类型以及长度

  • 一字节、两字节或者五字节长,值的最高位为00、01或者10的是字节数组编码
  • 一字节长,值的最高位以11开头的是整数编码
3.2.1字节数组编码
编码编码长度content属性保存的值
00bbbbbb1字节长度小于等于63字节的字节数组
01bbbbbb xxxxxxxx2字节长度小于等于16383字节的字节数组
10_ _ _ _ _ _ aaaaaaaa bbbbbbbb cccccccc dddddddd3字节长度小于等于4294967295字节的字节数组
3.2.2 整数编码
编码编码长度content属性保存的值
110000001字节int16_t 类型的整数
110100001字节int32_t 类型的整数
111000001字节int65_t 类型的整数
111100001字节24位有符号整数
111111101字节8位有符号整数
1111xxxx1字节使用这一编码的节点没有对应的contetn值,因为编码本身的xxxx四个位已经保存了一个介于0和12之间的值,所以无需content属性
3.3 content

节点的content属性负责保存节点的值,节点值可以是一个字节数组或者整数,值的类型由节点的encoding属性决定.

4. 连锁更新

前面说过,每个节点的previous_entry_len属性都记录了前一个节点的长度,现在要考虑一种情况:在一个压缩列表中,由多个连续的、长度介于250字节到253字节之间的节点e1到eN,如下图所示: image.png

因为e1至eN的所有节点的长度都小于254字节,所以记录这些节点的长度只需要1字节长的previous_entry_len属性,换句话说,e1至eN的所有节点的previous_entry_len属性都是1字节长的.

这时如果我们讲一个长度大于等于254字节的心节点new设置为压缩列表的头节点,那么new将成为e1的前置节点,如下图所示: image.png

因为e1的previous_entry_len属性仅长1字节,所以它没办法保存心节点new的长度,所以程序将对压缩列表执行空间重分配操作,并将e1节点的previous_entry_len属性从原来的1字节扩展为5字节长

现在麻烦的事来了,e1原本的长度介于250字节和253字节之间,在为previous_entry_len属性新增4个字节的空间以后,e1的长度就超过了254字节,这种长度使得使用1字节长的previous_entry_len属性事没办法保存的,因此为了让e2的previous_entry_len属性可以记录下e1的长度,程序需要对压缩列表再次执行空间重分配操作,并将e2的previous_entry_len属性从原来的1字节扩展为5字节.

正如对e1的扩展引发了对e2的扩展一样,e2的扩展也会引发对e3的扩展,而扩展e3又回引发对e4的扩展…为了让每个节点的previous_entry_len属性都符合压缩列表对节点的要求,程序要不断的对压缩列表执行空间重分配操作,直到eN为止

Redis 将这种在特殊情况下产生的连续多次执行空间重分配的草锁称为“连锁更新”(cascade update)

除了添加节点可能会引发连锁更新之外,删除节点也会引发连锁更新,在此就不再进行详细讨论了

因为连锁更新在最坏的情况下需要对压缩列表执行N次空间重分配操作,而每次空间重分配的最坏复杂度为O(N), 所以连锁更新最坏的复杂度为O(N2)

要注意的事,尽管连锁更新的复杂度较高,但它真正造成的性能问题的几率是很低的:

  • 首先,压缩列表里要恰好有多个连续的、长度介于250到253字节之间的节点,连锁更新才有可能被引发,在实际中,这种情况并不多见
  • 其次,即时出现连锁更新,但只要被更新的节点数量不多,就不会对性能造成任何影响:比如说,对三五个节点进行连锁更新,是不会影响性能的 因为上述原因,ziplistPush等命令的平均复杂度仅为O(N),在实际中,我们可以放心的使用,而不用担心连锁更新带来的对压缩列表性能的影响

5.总结

  • 压缩列表是一种为了节约内存而开发的顺序型数据结构
  • 压缩列表在3.2之前用作列表键和哈希键的底层实现之一,在3.2之后列表键用quicklist替换了压缩列表
  • 压缩列表可以包含多个节点,每个节点可以保存一个字节数组或者整数值
  • 添加或者删除压缩列表中的节点可能会引起连锁更新操作,但这种操作出现的几率并不高
avatar
文章
阅读
粉丝