Redis中的压缩列表ziplist——《Redis设计与实现》读书笔记 (包括思维导图及xmind源文件)

简介：

压缩列表ziplist是为了节约内存而开发的，由一系列特殊编码的连续内存块组成的顺序型数据结构

• 一个压缩列表可以包含多个节点
• 一个节点保存一个字节数组或者一个整数值

组成部分
zlbytes：整个压缩列表占用的字节数
zltail：表尾距离起始地址有多少字节
zlen：压缩列表包含的节点数量
entry：保存数据的节点、节点长度由节点的内容决定
zlend：标记位0xFF，标记压缩列表末端
例子

表示这个压缩列表占用0x50个字节、尾部节点在0x3c处、节点个数为3个
只要用开始指针 p 加上偏移量 60 ， 就可以计算出表尾节点 entry3 的地址

节点

每个压缩列表节点都由 previous_entry_length 、 encoding 、 content 三个部分组成

previous_entry_length

记录前一个节点的长度

• 1字节表示: 如果前一节点的长度小于 254 字节， 那么 previous_entry_length 属性的长度为 1 字节：
  前一节点的长度就保存在这一个字节里面。

• 5字节表示: 如果前一节点的长度大于等于 254 字节， 那么 previous_entry_length 属性的长度为 5 字节：
  其中属性的第一字节会被设置为 0xFE （十进制值 254）， 而之后的四个字节则用于保存前一节点的长度。

如果我们有一个指向当前节点起始地址的指针 c ， 那么我们只要用指针 c 减去当前节点 previous_entry_length 属性的值， 就可以得出一个指向前一个节点起始地址的指针 p

从尾部到头部逆向遍历的过程就是如此实现

encoding

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

字节数组编码:

• 00bbbbbb 1 字节 长度小于等于 63 字节的字节数组。
• 01bbbbbb xxxxxxxx 2 字节 长度小于等于 16383 字节的字节数组。
• 10______ aaaaaaaa bbbbbbbb cccccccc dddddddd 5 字节 长度小于等于 4294967295
  的字节数组。

整数编码:

• 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 属性决定。

00表示的是长度小于63字节的数组
对应的数组为hello world

连锁更新

特殊情况：
在一个压缩列表中， 有多个连续的、长度介于 250 字节到 253 字节之间的节点 e1 至 eN

因为 e1 至 eN 的所有节点的长度都小于 254 字节， 所以记录这些节点的长度只需要 1 字节长的 previous_entry_length 属性

假如现在要在压缩列表头部加入一个长度为256字节以上的节点

现在e1的previous已经不能用1位来表示，需要用5位来表示，所以e1节点需要更新，同时后面的节点也需要往后移动

同样的，因为e1现在的长度现在+5超过了256个字节，所以e2的previpus也需要升级为5位，同样的e3…eN

除了添加节点需要更新，删除也需要更新

连锁更新在最坏情况下需要对压缩列表执行 N 次空间重分配操作， 而每次空间重分配的最坏复杂度为 O(N) ， 所以连锁更新的最坏复杂度为 O(N^2)
尽管连锁更新的复杂度较高， 但它真正造成性能问题的几率是很低的，它的时间复杂度平均为O(N)

思维导图：

思维导图Xmind文件