redis原理之底层数据结构(二)-压缩列表

时间:2024-07-16 06:57:48

1.绪论

压缩列表是redis最底层的结构之一,比如redis中的hash,list在某些场景下使用的都是压缩列表。接下来就让我们看看压缩列表结构究竟是怎样的。

2.ziplist

2.1 ziplist的组成

在低版本中压缩列表是由ziplist实现的,我们来看看他的结构

可以看出压缩列表由如下几个字段组成:
1.zlbytes:4个字节的总长度;
2.zltail: 4个字节最后一个元素的指针;
3.zllen:2个字节总的元素个数;
4.多个entry元素;
5.zlend:压缩列表的结尾标志。

每个entry元素由3部分组:
1.previous_entry_length:1个字节或者5个字节,上一个entry的长度,当上一个元素大小小于255个自己,当前字段为1个字节,当超过255个字节,当前字段为5个字节;
2.encoding:通过1个字节,用来表示存储的内容是什么类型,比如int16或者int32,或者是字符串数组;
3.content:真正存储的内容数据,如果是存储的字符串,会存储字符串的长度和内容。

2.2 ziplist的缺点

2.2.1 连锁更新

ziplist为了解决从节点后向前遍历的问题,所以每个entry都存储了前一个节点的长度previous_entry_length,而redis一直秉持着对节约内存的优秀品质,如果前一个节点的数量小于255个字节,就用1个字节来存储长度,但是大于的话就用5个字节来存储长度。现在假设ziplist有5个entry,而且刚好5个entry的长度254,刚好每个previous_entry_length都是一个字节来存储长度,现在假设第一个entry加了一些数据,导致长度,大于了255个字节,第二个元素的previous_entry_length需要用5个字节来存储前一个元素的长度,导致第二个entry的总长度也增加了,并且超过了255个字节,所以第3个元素的previous_entry_length也需要用5个字节存储上一个元素的长度,依此类推,修改一个元素的内容,需要修改后面所有的元素。这就是连锁更新。

3.listpack

在高版本的redis中,为了解决连锁更新问题,redis采用listpack来实现压缩列表。listpack和ziplist差不多,但是有个区别就是每个entry记录的是本entry的长度,而不是上一个entry的长度,所以每个entry长度的改变只会影响自己,而不会影响到其他的entry。

3.1 listpack的组成


1.tot-bytes:4个字节的总长度
2.num-elements:entry的总个数
3.多个entry
4.end-bytes:1个字节的结束标识


每个entry由3部分组成:
1.encoding:1个字节,用来标识content存储的内容的编码,整数或者字符串
2.content:每个entry存储的内容
3.back-len:当前entry的长度,这是和ziplist的主要区别