Redis学习——压缩列表ziplist

压缩列表（ziplist）是列表键和哈希键的底层实现之一。
当一个 列表键只包含少量列表项，并且每个列表项要么就是 最小值，要么就是长度比较短的字符串，那么Redis就会使用压缩列表来做列表键的底层实现
当一个 哈希键只包含少量键值对，并且每个键值对的键和值要么就是 小整数值，要么就是长度比较短的字符串，那么Redis就会使用压缩列表来做哈希键的底层实现。

1、压缩列表的构成

压缩列表是Redis为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型（sequential）数据结构。
一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。元素之间紧挨着存储，没有任何冗余空隙。

2、压缩列表节点的构成

2.1 previous_entry_length

因为节点的previous_entry_length属性记录了前一个节点的长度，所以程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址。

2.2 encoding

节点的encoding属性记录了节点的content属性所保存数据的类型以及长度：

2.3 content

3、连锁更新

在特殊情况下产生的连续多次空间扩展操作称之为“连续更新”。

因为连锁更新在最坏情况下需要对压缩列表执行N次空间重分配操作，而每次空间重分配的最坏复杂度为O(N)，所以连锁更新的最坏复杂度为O(N*N)
要注意的是，尽管连锁更新的复杂度较高，但它真正造成性能问题的几率是很低的：
首先，压缩列表里要恰好有多个连续的，长度介于250字节至253字节之间的节点，连锁更新才有可能被引发，在实际中，这种情况并不多见；
其次，即使出现连锁更新，但只要被更新的节点不多，就不会对性能造成任何影响。
因为以上原因，ziplistPush等命令的平均复杂度仅为O(N)，在实际中，我们可以放心地使用这些函数，而不必担心连锁更新会影响压缩列表的性能。

参考：
《Redis设计与实现》第七章 压缩列表