蜻蜓点水说说Redis的ziplist的奥秘

本篇博客参考：

上篇博客中，我给大家蜻蜓点水般的介绍了Redis中SDS的奥秘，说明Redis之所以那么快，还有一个很重要、但是经常被大家忽视的一点，那就是Redis精心设计的数据结构。本篇博客，还是继续这个话题，给大家介绍下Redis另外一种底层数据结构：ziplist。

在Redis中，有五种基本数据类型，除了上篇博客提到的String，还有list，hash，zset，set，其中list，hash，zset都间接或者直接使用了ziplist，所以说理解ziplist也是相当重要的。

ziplist是什么意思

我刚开始看ziplist的时候，总觉得zip这个单词甚是熟悉，好像在日常使用电脑的时候经常看到，于是我百度了下：

哦哦，怪不得那么熟悉，原来就是“压缩”的意思，那ziplist就可以翻译成“压缩列表”了。

为什么要有ziplist

有两点原因：

普通的双向链表，会有两个指针，在存储数据很小的情况下，我们存储的实际数据的大小可能还没有指针占用的内存大，是不是有点得不偿失？而且Redis是基于内存的，而且是常驻内存的，内存是弥足珍贵的，所以Redis的开发者们肯定要使出浑身解数优化占用内存，于是，ziplist出现了。
链表在内存中，一般是不连续的，遍历相对比较慢，而ziplist可以很好的解决这个问题。

来看看ziplist的存在

zadd programmings 1.0 go 2.0 python 3.0 java

创建了一个zset，里面有三个元素，然后看下它采用的数据结构：

debug object  programmings

"Value at:0x7f404ac30c60 refcount:1 encoding:ziplist serializedlength:36 lru:2689815 lru_seconds_idle:9"

HSET website google "www.g.cn

创建了一个hash，只有一个元素，看下它采用的数据结构：

debug object website

"Value at:0x7f404ac30ac0 refcount:1 encoding:ziplist serializedlength:30 lru:2690274 lru_seconds_idle:14"

可以很清楚的看到，zset和hash都采用了ziplist数据结构。

当满足一定的条件，zset和hash就不再使用ziplist数据结构了：

debug object website

"Value at:0x7f404ac30ac0 refcount:1 encoding:hashtable serializedlength:180 lru:2690810 lru_seconds_idle:2"

可以看到，hash的底层数据结构变成了hashtable。

szet就不做实验了，感兴趣的小伙伴们可以自己实验下。

至于这个转换条件是什么，放到后面再说。

好奇的你们，肯定会尝试看下list的底层数据结构是什么，发现并不是ziplist：

LPUSH languages python

debug object languages

"Value at:0x7f404c4763d0 refcount:1 encoding:quicklist serializedlength:21 lru:2691722 lru_seconds_idle:22 ql_nodes:1 ql_avg_node:1.00 ql_ziplist_max:-2 ql_compressed:0 ql_uncompressed_size:19"

可以看到，list采用的底层数据结构是quicklist，并不是ziplist。

在低版本的Redis中，list采用的底层数据结构是ziplist+linkedList，高版本的Redis中，quicklist替换了ziplist+linkedList，而quicklist也用到了ziplist，所以可以说list间接使用了ziplist数据结构。这个quicklist是什么，不是本篇博客的内容，暂且不表。

探究ziplist

ziplist源码：ziplist源码

ziplist源码的注释写的非常清楚，如果英语比较好，可以直接看上面的注释，如果你英语不是太好，或者没有一定的钻研精神，还是看看我写的博客吧。

ziplist布局

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

这是在注释中说明的ziplist布局，我们一个个来看，这些字段是什么：

zlbytes：32bit无符号整数，表示ziplist占用的字节总数（包括本身占用的4个字节）；
zltail：32bit无符号整数，记录最后一个entry的偏移量，方便快速定位到最后一个entry；
zllen：16bit无符号整数，记录entry的个数；
entry：存储的若干个元素，可以为字节数组或者整数；
zlend：ziplist最后一个字节，是一个结束的标记位，值固定为255。

Redis通过以下宏定义实现了对ziplist各个字段的存取：

// 假设char *zl 指向ziplist首地址

// 指向zlbytes字段

#define ZIPLIST_BYTES(zl)       (*((uint32_t*)(zl)))

// 指向zltail字段(zl+4)

#define ZIPLIST_TAIL_OFFSET(zl) (*((uint32_t*)((zl)+sizeof(uint32_t))))

// 指向zllen字段(zl+(4*2))

#define ZIPLIST_LENGTH(zl)      (*((uint16_t*)((zl)+sizeof(uint32_t)*2)))

// 指向ziplist中尾元素的首地址

#define ZIPLIST_ENTRY_TAIL(zl)  ((zl)+intrev32ifbe(ZIPLIST_TAIL_OFFSET(zl)))

// 指向zlend字段，指恒为255（0xFF）

#define ZIPLIST_ENTRY_END(zl)   ((zl)+intrev32ifbe(ZIPLIST_BYTES(zl))-1)

entry的构成

从ziplist布局中，我们可以很清楚的知道，我们的数据被保存在ziplist中的一个个entry中，我们下面来看看entry的构成。

<prevlen> <encoding> <entry-data>

我们再来看看这三个字段是什么：

prevlen：前一个元素的字节长度，便于快速找到前一个元素的首地址，假如当前元素的首地址是x，那么(x-prevlen)就是前一个元素的首地址。
encoding：当前元素的编码，这个字段实在是太复杂了，我们放到后面再说；
entry-data：实际存储的数据。

prevlen

prevlen字段是变长的：

前一个元素的长度小于254字节时，prevlen用1个字节表示；
前一个元素的长度大于等于254字节时，prevlen用5个字节进行表示，此时，prevlen的第一个字节是固定的254（0xFE）（作为这种情况的一个标志），后面4个字节才表示前一个元素的长度。

encoding

下面就要介绍下encoding这个字段了，在此之前，大家可以到阳台吹吹风，喝口热水，再做个深呼吸，最后再做一个心理准备，因为这个字段实在是太复杂了，搞不好，看的时候，一下子吐了。。。如果实在无法理解，直接略过这一段吧。

Redis为了节约空间，对encoding字段进行了相当复杂的设计，Redis通过encoding来判断存储数据的类型，下面我们就来看看Redis是如何根据encoding来判断存储数据的类型的：

00xxxxxx 最大长度位 63 的短字符串，后面的6个位存储字符串的位数；
01xxxxxx xxxxxxxx 中等长度的字符串，后面14个位来表示字符串的长度；
10000000 aaaaaaaa bbbbbbbb cccccccc dddddddd 特大字符串，需要使用额外 4 个字节来表示长度。第一个字节前缀是10，剩余 6 位没有使用，统一置为零；
11000000 表示 int16；
11010000 表示 int32；
11100000 表示 int64；
11110000 表示 int24；
11111110 表示 int8；
11111111 表示 ziplist 的结束，也就是 zlend 的值 0xFF；
1111xxxx 表示极小整数，xxxx 的范围只能是 (0001~1101), 也就是1~13。

如果是第10种情况，那么entry的构成就发生变化了：

<prevlen> <encoding>

因为数据已经存储在encoding字段中了。

可以看出Redis根据encoding字段的前两位来判断存储的数据是字符串（字节数组）还是整型，如果是字符串，还可以通过encoding字段的前两位来判断字符串的长度；如果是整形，则要通过后面的位来判断具体长度。

entry的结构体

我们上面说了那么多关于entry的点点滴滴，下面将要说的内容可能会颠覆你三观，我们在源码中可以看到entry的结构体，上面有一个注释非常重要：

/* We use this function to receive information about a ziplist entry.

 * Note that this is not how the data is actually encoded, is just what we

 * get filled by a function in order to operate more easily. */

typedef struct zlentry {

    unsigned int prevrawlensize; /* Bytes used to encode the previous entry len*/

    unsigned int prevrawlen;     /* Previous entry len. */

    unsigned int lensize;        /* Bytes used to encode this entry type/len.

                                    For example strings have a 1, 2 or 5 bytes

                                    header. Integers always use a single byte.*/

    unsigned int len;            /* Bytes used to represent the actual entry.

                                    For strings this is just the string length

                                    while for integers it is 1, 2, 3, 4, 8 or

                                    0 (for 4 bit immediate) depending on the

                                    number range. */

    unsigned int headersize;     /* prevrawlensize + lensize. */

    unsigned char encoding;      /* Set to ZIP_STR_* or ZIP_INT_* depending on

                                    the entry encoding. However for 4 bits

                                    immediate integers this can assume a range

                                    of values and must be range-checked. */

    unsigned char *p;            /* Pointer to the very start of the entry, that

                                    is, this points to prev-entry-len field. */

} zlentry;

重点看上面的注释。一句话解释：这个结构体虽然定义出来了，但是没有被使用，因为如果真的这么使用的话，那么entry占用的内存就太大了。

ziplist的存储形式

Redis并没有像上篇博客介绍的SDS一样，封装一个结构体来保存ziplist，而是通过定义一系列宏来对数据进行操作，也就是说ziplist是一堆字节数据，上面所说的ziplist的布局和ziplist中的entry的布局只是抽象出来的概念。

为什么不能一直是ziplist

在文章比较前面的部分，我们做了实验来证明，满足一定的条件后，zset、hash的底层存储结构不再是ziplist，既然ziplist那么牛逼，Redis的开发者也花了那么多精力在ziplist的设计上面，为什么zset、hash的底层存储结构不能一直是ziplist呢？

因为ziplist是紧凑存储，没有冗余空间，意味着新插入元素，就需要扩展内存，这就分为两种情况：

分配新的内存，将原数据拷贝到新内存；
扩展原有内存。

所以ziplist 不适合存储大型字符串，存储的元素也不宜过多。

ziplist存储界限

那么满足什么条件后，zset、hash的底层存储结构不再是ziplist呢？在配置文件中可以进行设置：

hash-max-ziplist-entries 512  # hash 的元素个数超过 512 就必须用标准结构存储

hash-max-ziplist-value 64  # hash 的任意元素的 key/value 的长度超过 64 就必须用标准结构存储

zset-max-ziplist-entries 128  # zset 的元素个数超过 128 就必须用标准结构存储

zset-max-ziplist-value 64  # zset 的任意元素的长度超过 64 就必须用标准结构存储

对于这个配置，我只是一个搬运工，并没有去实验，毕竟没有人会去修改这个吧，感兴趣的小伙伴可以试验下。

看到了吧，Redis真不是想象中的那么简单，需要研究的东西还是挺多，也挺复杂的，如果我们不去学习，可能觉得自己完全掌握了Redis，但是一旦开始学习了，才发现我们先前掌握的只是皮毛。验证了一句话，知道的越多，不知道的越多。

本篇博客到这里就结束了。