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

本篇博客参考：

Redis 深度历险：核心原理与应用实践

Redis内部数据结构详解(4)——ziplist

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来判断存储数据的类型的：

1. 00xxxxxx 最大长度位 63 的短字符串，后面的6个位存储字符串的位数；
2. 01xxxxxx xxxxxxxx 中等长度的字符串，后面14个位来表示字符串的长度；
3. 10000000 aaaaaaaa bbbbbbbb cccccccc dddddddd 特大字符串，需要使用额外 4 个字节来表示长度。第一个字节前缀是10，剩余 6 位没有使用，统一置为零；
4. 11000000 表示 int16；
5. 11010000 表示 int32；
6. 11100000 表示 int64；
7. 11110000 表示 int24；
8. 11111110 表示 int8；
9. 11111111 表示 ziplist 的结束，也就是 zlend 的值 0xFF；
10. 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，但是一旦开始学习了，才发现我们先前掌握的只是皮毛。验证了一句话，知道的越多，不知道的越多。

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