Redis源码之压缩列表

压缩列表是列表键和哈希键的底层实现，用于存放小的字符串及数字。

主要数据结构
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，而且代码可读性也不太好*