Redis数据结构与对象6——压缩列表

压缩列表

压缩列表
: (ziplist)是列表键(list)哈希键(hash)的底层实现之一。当一个列表键只包含少量的列表项,并且每个列表项要么就是小整数值(具体见下文),要么就是长度比较短的字符串,那么Redis就会使用压缩列表来作为列表键的底层实现。:Redis3.2分支引入了quicklist,并在4.0分支用quicklist替代了ziplistlinkedlist成为了列表对象的底层编码

redis> RPUSH lst 1 3 5 10086 "hello" "world"
"6"
reids> OBJECT ENCODING lst
"ziplist"

另外,当一个哈希键只包含少量键值对,并且每个键值对的键和值要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做哈希键的底层实现。

redis> HMSET profile "name" "Jack" "age" 28 "job" "Programmer"
"OK"
reids> OBJECT ENCODING profile
"ziplist"

压缩列表的构成

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

压缩列表的各个组成部分

zlbytes zltail zllen entry1 entry2 entryN zlend

压缩列表各个组成部分详细说明

属性 类型 长度 用途
zlbytes uint32_t 4字节 记录整个压缩列表占用的内存字节数(即压缩列表总长),在对压缩列表进行内存重分配或计算zlend的位置时使用
zltail uint32_t 4字节 记录压缩列表表尾节点距离压缩列表的起始地址(即zlbytes的起始地址)有多少个字节,通过这个偏移量,程序无需遍历整个压缩列表就可以确定表尾节点(即最后一个entry)的地址
zllen uint16_t 2字节 记录了压缩列表包含的节点(即entry)数量,当这个属性的值小于UINT16_MAX(65535)时,这个属性的值就是压缩列表包含节点的数量,当这个值等于65535时,节点的真是数量需要遍历整个压缩列表才能计算得出
entryX 列表节点 不定 压缩列表包含的各个节点,节点的长度由节点保存的内容决定
zlend uint8_t 1字节 特殊值0xFF(十进制255),用于标记压缩列表的末端

压缩列表节点的构成

previous_entry_length encoding content

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

  • 长度小于等于63(2^6-1)字节的字节数组
  • 长度小于等于16383(2^14-1)字节的字节数组
  • 长度小于等于4294967295(2^32-1)字节的字节数组
    而整数值则可以是一下六种长度之一:
  • 4位长,介于0-12之间的无符号整数
  • 1字节长的有符号整数
  • 3字节长的有符号整数
  • int16_t类型整数
  • int32_t类型整数
  • int64_t类型整数

每个压缩列表节点都由previous_entry_lengthencodingcontent三个部分组成。

previous_entry_length

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

  • 如果前一节点的长度小于254字节,那么previous_entry_length属性的长度为1字节,前一个节点的长度就保存在这一个字节中(如0x05,表示前一个节点为5字节)
  • 如果前一个的长度大于254字节,那么previous_entry_length属性的长度为5字节,其中属性的第一字节会被设置为0xFE(十进制254),而之后的四个字节则用于保存前一节点的长度(如0xFE00002766,0x00002766十进制为10086,表示前一个节点长度为10086)

因为节点的previous_entry_length属性记录了前一个节点的长度,所以程序可以通过指针运算,根据当前的起始地址计算出前一个节点的起始地址。压缩列表的从表尾向表头遍历操作就是使用这一原理实现的。

encoding

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

  • 一字节、两字节或者五字节长,值的最高位为00、01或者10的是字节数组编码,这种编码表示节点的content属性保存着字节数组,数组的长度由编码除去最高两位之后的其他位记录
  • 一字节长,值的最高位以11开头的是整数编码,这种编码表示节点的content属性保存着整数值,整数值的类型和长度由编码除去最高两位之后的其他位记录

字节数组编码

编码 编码长度 content属性保存的值
00xxxxxx 1字节 长度小于等于63字节的字节数组
01xxxxxx yyyyyyyy 2字节 长度小于等于16383字节的字节数组
10______ xxxxxxxx yyyyyyyy zzzzzzzz aaaaaaaa 5字节 长度小于等于4294967295字节的字节数组

整数编码

编码 编码长度 content属性保存的值
11000000 1字节 int16_t类型的整数
11010000 1字节 int32_t类型的整数
11100000 1字节 int64_t类型的整数
11110000 1字节 24位有符号整数
11111110 1字节 8位有符号整数
1111xxxx 1字节 使用这一编码的节点没有相应的content属性,因为编码本身的xxxx四个位已经保存了一个介于0-12的值,所以它无须content属性

content

节点的content属性负责保存节点的值,节点值可以是一个字节数组或整数,值的类型和长度由节点的encoding属性决定。例如:

previous_entry_length encoding content
xxx 00001011 “hello world”
  • 编码最高位00表示节点保存的是一个字节数组
  • 编码后六位001011记录了字节数组长度为11
  • content属性保存了节点值字符串

连锁更新

前面说过,每个节点的previous_entry_length属性都记录了前一个节点的长度,现在考虑这样一种情况,在一个压缩列表中,又多个连续的、长度介于250字节到253字节之间的节点e1至eN

zlbytes zltail zllen entry1 entry2 entryN zlend

因为e1至eN所有节点的长度都小于254字节,所以记录这些节点的长度只需要1字节长的previous_entry_length属性,这时,如果我们将一个长度大于等于254字节的新节点new设置为压缩列表的表头节点

zlbytes zltail zllen new-entry entry1 entryN zlend

因为e1的previous_entry_length属性仅长1字节,无法保存新节点的长度,所以程序将对压缩列表执行空间重分配操作,并将e1节点的previous_entry_length属性从原来的1字节扩展为5字节。现在,问题来了,e1之前介于250字节到253字节,现在新增四个字节,e1长度必定大于254字节,因此e2也保存不下,得再次对压缩列表执行空间重分配操作,正如e1引发了e2的扩展,e2也会引发e3的扩展……直到eN为止。
Redis将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新(cascade)”,除了添加新节点可能会引发连锁更新之外,删除节点也可能会引发连锁更新(如下,删除small节点,entry1会扩展为5字节)。

zlbytes zltail zllen big(大于254) small(小于254) entry1 entryN zlend

因为连锁更新在最坏的情况下需要对压缩列表执行N次空间重分配操作,二每次空间重分配最坏的复杂度为O(N)(即从entry1开始分配),所以连锁更新最坏复杂度为O(N^2),即压缩列表的很多API最坏复杂度为O(N^2),如ziplistPush等。但是尽管连锁更新的复杂度较高,但是可能性几率不大,或者节点数少也不会造成太大性能问题。

总结

  • 压缩列表是一种为节约内存而开发的顺序性数据结构
  • 压缩列表被用作列表键和哈希键的底层实现之一
  • 压缩列表可以包含多个节点,每个节点可以保存一个字节数组或者整数值
  • 添加新节点到压缩列表,或者从压缩列表中删除节点,可能会引发连锁更新操作,但这种操作出现的几率并不高