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

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个字节存储上一个元素的长度，依此类推，修改一个元素的内容，需要修改后面所有的元素。这就是连锁更新。