什么是压缩列表

压缩列表 ziplist 在 redis 中的应用也非常广泛，它是我们常用的 zset ，list 和 hash 结构的底层实现之一。当我们的容器对象的元素个数小于一定条件时，redis 会使用 ziplist 的方式储存，来减少内存的使用。

    > hset test_hash me sidfate
    (integer) 1
    > object encoding test_hash
    "ziplist"

为什么要在元素较少的时候使用 ziplist ？

因为 redis 中的集合容器中，很多情况都用到了链表的实现，元素和元素之间通过储存的关联指针有序的串联起来，但是这样的指针往往是 随机I/O，也就是指针地址是不连续的（分布不均匀）。而我们的 ziplist 它本身是一块连续的内存块，所以它的读写是 顺序I/O，从底层的磁盘读写来说，顺序I/O 的效率肯定是高于 随机I/O 。你可能会问了，那为什么不都用 顺序I/O 的 ziplist 代替 随机I/O 呢，因为 ziplist 是连续内存，当你元素数量多了，意味着当你创建和扩展的时候需要操作更多的内存，所以 ziplist 针对元素少的时候才能提升效率。

ziplist 如何减少内存使用的呢？

接下来让我们从源码中一探究竟。

源码结构

题外话：每当你想要去探究一个项目的源码的时候，首先应该去看的就是它的注释，好的注释即是文档。同时也告诉我们平时开始也要注意注释的编写。

首先从源码的注释中我们可以了解一些基础信息：

ziplist 是经过特殊编码的双向列表结构，用来提高内存使用效率。它可以储存字符串或者整数值，其中整数值被编码成实际的整数，而不是字符串形式。它可以在 O(1) 时间内对列表的两端进行 push 和 pop 操作。但是，因为每个操作都需要重新分配 ziplist 使用的内存，所以实际的复杂度与 ziplist 使用的内存大小有关。

ziplist 结构的布局如下：

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

属性	字节数	含义
zlbytes	4	压缩列表占用的内存字节数：在对压缩列表进行内存重分配，或者计算 zlend 的位置时使用。
zltail	4	压缩列表表尾节点的偏移量：用来倒序遍历压缩列表。
zllen	2	记录了压缩列表包含的节点数量：当这个属性的值小于 UINT16_MAX （65535）时，这个属性的值就是压缩列表包含节点的数量；当这个值等于 UINT16_MAX 时，节点的真实数量需要遍历整个压缩列表才能计算得出。
entry[]	待定	节点数组，包含元素的具体信息
zlend	1	特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。

ziplist中的每个节点 entry 的结构如下：

<prevlen> <encoding> <entry-data>

redis 为了节约内存在 ziplist 的 entry 这个结构上有很多骚操作，让我来一一说明。

prevlen

prevlen 表示前一个元素的长度，以便能够从后向前遍历列表。它有一套特别的编码方式：如果这个长度小于254字节，那么它占用1个字节；当长度大于或等于254时，占用5个字节，第一个字节被设置为254 (0xFE)，其余的4个字节采用前一个条目的长度作为值。prevlen 用 5 bytes表示时，不代表长度一定大于等于254，这是为了减少 realloc 和 memmove 提高效率。

为什么临界值是 254 ？我们来算一笔，一个字节最大能储存值为255，那临界值应该是255啊，别忘了我们还有个 zlend，它的值是0xFF（255），为了避免混淆，所以用254区分。

encoding

encoding 表示元素的编码，它取决于元素的内容。当元素是一个字符串时，编码的第一个字节的前2位将保存用于存储字符串长度的编码类型，然后是字符串的实际长度。当条目是整数时，前2位都设置为1。下面的2位用于指定在这个报头之后将存储哪种类型的整数。对不同类型和编码的概述如下。第一个字节总是足以确定条目的类型。

|00pppppp| - 1 字节

长度小于或等于63字节的字符串，63可以用6个字节表示，所以 pppppp 表示字符串的实际长度。
|01pppppp|qqqqqqqq| - 2 字节

长度小于或等于16383字节（14 位）的字符串。
|10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| - 5 字节

长度大于16383（14位）的字符串，后4个字节代表长度。
|11000000| - 3 字节

11000000 + int16（2字节）。
|11010000| - 5 字节

11010000 + int32（4字节）。
|11100000| - 9 bytes

11010000 + int64（8字节）。
|11110000| - 4 bytes

11110000 + 24位有符号整数（3字节）。
|11111110| - 2 bytes

11110000 + int8（1字节）。
|1111xxxx|

极小整数，xxxx 的范围只能是 (0001~1101)，也就是1~13，但是因为0000、1110、1111都被占用了。读取到的 value 需要将 xxxx 减 1，也就是整数 0~12 就是最终的 value。
|11111111|

表示 ziplist 的结束，也就是 zlend 的值 0xFF。

如果你觉得看的混乱了，别慌，上面的不需要全部记住，下面我会用一个鲜活的栗子（官方例子）来总结下。以下是一个包含了字符串 “2” 和 “5” 的压缩列表：

[0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
      |             |          |       |       |     |
   zlbytes        zltail    zllen     "2"     "5"   end

最前面的4个字节的代表着数字 0x0f = 15（zlbytes = 15），表示这个 ziplist 总共占用了15个字节。紧跟着的4个字节代表数字 0x0c = 12（zltail = 12），说明最后一个元素的偏移量是12，也就是 “5” 这个元素到 ziplist 开头的长度。接着是 zllen = 2，代表总共有2个元素。之后就是实际储存 “2” 和 “5” 的 entry。解读下 “2” 为什么是 00 f3，00表示前一个元素长度为0，因为它是第一个元素，f3 是 0x11110011，也就是我们的 1111xxxx encoding类型，3 - 1 = 2正好是我们的 “2”，“5” 也同理。最后是 ff 结尾表示结束。

有没有童鞋注意到官方例子总我们储存的是字符串的 “2” 和 “5”，但是 redis 把它当成了整数来储存？这一点其实是 redis 故意做的，很多地方都会做类似处理，目的么，还是为了减少内存消耗。

最后我们再看一个储存字符串的例子，我们把上面的 “5” 换成 “Hello World”，那么原先的 “5” 这个 entry 会变成：

[02] [0b] [48 65 6c 6c 6f 20 57 6f 72 6c 64]

至于为什么的话，你们就对照的上面的自己试一遍，就当做练习题了。