压缩列表的内部数据结构
- 压缩列表
- 增加元素
- 级联更新问题
- IntSet小整数集合
压缩列表
- redis为了节约存储空间,当zset和hash容器对象中的元素比较少的时候,采用压缩列表(ziplist)进行存储,压缩列表是一块连续的存储空间,没有任何的冗余间隙。
- 数据结构
struct ziplist<T>{
int32 zlbytes; //整个压缩列表占用的空间
int32 zltail_offset; // 最后一个元素距离压缩列表其实位置的偏移量,用于快速定位最后一个节点
int16 zllength; //元素的个数
T[] entries; //元素内容列表,紧凑存储;
int8 zlend; //压缩列表的结束标志,恒为0xFF;
}
压缩列表为了支持双向,所以zltail_offset才有这个字段,用来快速的定位到最后一个元素,方便遍历。
- entry对象的数据结构
struct entry{
int<var> prevlen; // 前一个entry的字节长度
int<var> encoding;//元素内容编码
optional byte[] content; //元素内容
}
- prevlen:的字段表示前一个entry的字节长度,当压缩反向遍历的时候, 需要通过这个字段快速的定位到下一个元素的位置。它是一个变长的整数,当字符串长度小于254的时候,会用1个字节进行表示,当超过254的时候会采用5个字节进行表示,
- encoding :存储了元素内容的编码类型信息,决定了entry中的数组的元素的编码类型
增加元素
- 因为ziplist使用的紧凑存储,没有冗余的空间,意味着插入一个新的元素就需要重新的调整,需要调用realloc扩展内存,取决于当前ziplist中的内存大小,可能会重新的分配一个新的内存地址,然后将数据全部copy到新的内存地址中,也可能是在原有的基础上进行扩展
- 因为ziplist的这些优劣点,决定了ziplist不能存储太多的数据,在占用内存太多的情况下,进行重新分配内存和拷贝内存会有很大的消耗。
级联更新问题
- 前面提到,当前一个entry的长度小于254字节的时候,prevlen是用1字节进行存储,否则进行5字节进行存储,当前一个长度发生改变的情况下,导致下一个entry的prevlen的长度发生改变,继而所有后续的prevlen都会发生修改,这就是级联更新问题。
- 删除一个元素的时候也会出现这种问题,因为可能删除的元素导致后续的entry的prevlen都发生改变
IntSet小整数集合
- 当set集合中元素的个数比较小的时候,同时元素全部是整数的时候,会采用intset来存储数据,intset是紧凑的数组结构,同时支持16,32,64位整数。
struct intset<T>{
int32 encoding; //决定整数位是16,32,64位
int32 length; //元素的个数
int<T> contents; // 整数数组,可以是16,32,64位;
}