压缩列表是列表键和哈希键的底层实现，用于寄存小的字符串及数字。
次要数据结构
zlentry
zlbyte: 压缩列表的字节数（蕴含 zlend）
zltail: 指向列表的最初一个元素
zllen：元素个数
zlend: 标记是否列表的开端
`/*
* 保留 ziplist 节点信息的构造
*/
typedef struct zlentry {
// prevrawlen：前置节点的长度
// prevrawlensize：编码 prevrawlen 所需的字节大小
unsigned int prevrawlensize, prevrawlen;
// len：以后节点值的长度
// lensize：编码 len 所需的字节大小
unsigned int lensize, len;
// 以后节点 header 的大小
// 等于 prevrawlensize + lensize
unsigned int headersize;
// 以后节点值所应用的编码类型
unsigned char encoding;
// 指向以后节点的指针
unsigned char *p;
} zlentry;`
有一点得留神一下：
unsigned char ziplistInsert(unsigned char zl, unsigned char p, unsigned char s, unsigned int slen);
该函数传入的参数 p、s，该元素的类型并非为 zlentry，而是
压缩列表节点
是否能够了解为须要兼容不同的下级数据类型？对外提供对立的接口？
在插入操作中，不仅须要对 s 执行转化操作，对 p 也同样须要执行转化操作。
* 有意思的一点，为了和压缩列表节点保持一致，zlentry 也提供了和压缩列表同样的元素，如 prevrawlensize, prevrawlen 这两字段对应压缩列表节点中的 previousentrylength，lensize 和 len 对应 encoding
然而这样做是否值得？本来在 zlentry 中用一个 prevrawlen 就能够示意了，当初非要加多 prevrawlensize，而且代码可读性也不太好*