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