关于redis: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，而且代码可读性也不太好*