下图为字符串三种长度结构的示意图(来源)：
如果 encoding 以 11 开头，就表示数据类型是整数。
#define ZIP_INT_16B (0xc0 | 0<<4) #define ZIP_INT_32B (0xc0 | 1<<4) #define ZIP_INT_64B (0xc0 | 2<<4) #define ZIP_INT_24B (0xc0 | 3<<4) #define ZIP_INT_8B 0xfe #define ZIP_INT_IMM_MIN 0xf1 /* 11110001 */ #define ZIP_INT_IMM_MAX 0xfd /* 11111101 */整数一共有 6 种编码，说起来麻烦，看图吧(来源)。
看了上图的最后一个类型，可能有小伙伴就有疑问：为啥没有 11111111 ？
答：因为 11111111 表示 zlend (十进制的 255，十六进制的 oxff) data
data 表示真实存的数据，可以是字符串或者整数，从编码可以得知类型和长度。知道长度，就知道 data 的起始位置了。
比较特殊的是，整数 1 ~ 13 (0001 ~ 1101)，因为比较短，刚好可以塞在 encoding 字段里面，所以就没有 data。
连锁更新通过上面的分析，我们知道：
前个节点的长度小于 254 的时候，用 1 个字节保存 prevlen
前个字节的长度大于等于 254 的时候，用 5 个字节保存 prevlen
现在我们来考虑一种情况：假设一个压缩列表中，有多个长度 250 ~ 253 的节点，假设是 entry1 ~ entryN。
因为都是小于 254，所以都是用 1 个字节保存 prevlen。
如果此时，在压缩列表最前面，插入一个 254 长度的节点，此时它的长度需要 5 个字节。
也就是说 entry1.prevlen 会从 1 个字节变为 5 个字节，因为 prevlen 变长，entry1 的长度超过 254 了。
这下就糟糕了，entry2.prevlen 也会因为 entry1 而变长，entry2 长度也会超过 254 了。
然后接着 entry3 也会连锁更新。。。直到节点不超过 254， 噩梦终止。。。
这种由于一个节点的增删，后续节点变长而导致的连续重新分配内存的现象，就是连锁更新。最坏情况下，会导致整个压缩列表的所有节点都重新分配内存。
每次分配空间的最坏时间复杂度是 \(O(n)\)，所以连锁更新的最坏时间复杂度高达 \(O(n^2)\) !
虽然说，连锁更新的时间复杂度高，但是它造成大的性能影响的概率很低，原因如下：
压缩列表中需要需要有连续多个长度刚好为 250 ~ 253 的节点，才有可能发生连锁更新。实际上，这种情况并不多见。
即使有连续多个长度刚好为 250 ~ 253 的节点，连续的个数也不多，不会对性能造成很大影响
因此，压缩列表插入操作，平均复杂度还是 \(O(n)\).
总结：压缩列表是一种为节约内存而开发的顺序型数据结构，是 ZSET、HASH 和 LIST 的底层实现之一。
压缩列表有 3 种字符串类型编码、6 种整数类型编码
压缩列表的增删，可能会引发连锁更新操作，但这种操作出现的几率并不高。