本篇博客参考：
上篇博客中，我给大家蜻蜓点水般的介绍了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占用的字节总数（包括<zlbytes>本身占用的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 就必须用标准结构存储
对于这个配置，我只是一个搬运工，并没有去实验，毕竟没有人会去修改这个吧，感兴趣的小伙伴可以试验下。
ziplist元素太多，怎么办
在介绍ziplist布局的时候，说到ziplist用两个位来记录ziplist的元素个数，如果元素个数实在太多，两个位不够怎么办呢？这种情况下，求ziplist元素的个数只能遍历了。
看到了吧，Redis真不是想象中的那么简单，需要研究的东西还是挺多，也挺复杂的，如果我们不去学习，可能觉得自己完全掌握了Redis，但是一旦开始学习了，才发现我们先前掌握的只是皮毛。验证了一句话，知道的越多，不知道的越多。
本篇博客到这里就结束了。
