Redis压缩列表数据结构

压缩列表

1. redis为了节约存储空间，当zset和hash容器对象中的元素比较少的时候，采用压缩列表(ziplist)进行存储，压缩列表是一块连续的存储空间，没有任何的冗余间隙。
2. 数据结构

struct ziplist<T>{
	int32 zlbytes; //整个压缩列表占用的空间
	int32 zltail_offset; // 最后一个元素距离压缩列表其实位置的偏移量，用于快速定位最后一个节点
	int16 zllength; //元素的个数
	T[] entries; //元素内容列表，紧凑存储；
	int8 zlend; //压缩列表的结束标志，恒为0xFF；
}
压缩列表为了支持双向，所以zltail_offset才有这个字段，用来快速的定位到最后一个元素，方便遍历。

3. entry对象的数据结构

	struct entry{
		int<var> prevlen; // 前一个entry的字节长度
		int<var> encoding;//元素内容编码
		optional byte[] content; //元素内容
	}
	

4. prevlen：的字段表示前一个entry的字节长度，当压缩反向遍历的时候， 需要通过这个字段快速的定位到下一个元素的位置。它是一个变长的整数，当字符串长度小于254的时候，会用1个字节进行表示，当超过254的时候会采用5个字节进行表示，
5. encoding ：存储了元素内容的编码类型信息，决定了entry中的数组的元素的编码类型

增加元素

1. 因为ziplist使用的紧凑存储，没有冗余的空间，意味着插入一个新的元素就需要重新的调整，需要调用realloc扩展内存，取决于当前ziplist中的内存大小，可能会重新的分配一个新的内存地址，然后将数据全部copy到新的内存地址中，也可能是在原有的基础上进行扩展
2. 因为ziplist的这些优劣点，决定了ziplist不能存储太多的数据，在占用内存太多的情况下，进行重新分配内存和拷贝内存会有很大的消耗。

级联更新问题

1. 前面提到，当前一个entry的长度小于254字节的时候，prevlen是用1字节进行存储，否则进行5字节进行存储，当前一个长度发生改变的情况下，导致下一个entry的prevlen的长度发生改变，继而所有后续的prevlen都会发生修改，这就是级联更新问题。
2. 删除一个元素的时候也会出现这种问题，因为可能删除的元素导致后续的entry的prevlen都发生改变

IntSet小整数集合

1. 当set集合中元素的个数比较小的时候，同时元素全部是整数的时候，会采用intset来存储数据，intset是紧凑的数组结构，同时支持16,32,64位整数。

struct intset<T>{
	int32 encoding; //决定整数位是16,32,64位
	int32 length; //元素的个数
	int<T> contents; // 整数数组，可以是16,32,64位；
}