redis:list的底层实现--压缩列表_redis list 压缩-CSDN博客

本文链接：https://blog.csdn.net/Fly_as_tadpole/article/details/88212436

压缩列表是list和hash的底层实现之一。为了节约内存而开发的。

什么时候使用？

1）当list中的只包含少量列表项，每个列表项要么只包含小整数，要么就是长度比较短的字符串。

2）当hash里包含的kv都是小整数或者短字符串的话。

Redis压缩列表原理与应用

压缩列表是一种数据结构，这种数据结构的功能是将一系列数据与其编码信息存储在一块连续的内存区域，这块内存物理上是连续的，逻辑上被分为多个组成部分，其目的是在一定可控的时间复杂读条件下尽可能的减少不必要的内存开销，从而达到节省内存的效果，这么介绍有点玄乎，我们先一起看看它的实现原理吧，Redis3.2版本中，作者对压缩列表的实现在ziplist.h和ziplist.c中。

压缩列表原理

我认为将数据按照一定规则存储在内存中可以用“编码”这个词描述，因此下面会常用“编码”这个词。

总体编码

上面说到压缩列表是一块连续的内存区域，这块内存区域布编码示意图大致如下：

Redis压缩列表内存编码示意图

常态的压缩列表内存编码如上图所示，整个内存块区域内分为五个部分，下面分别介绍着五个部分：

zlbytes：存储一个无符号整数，固定四个字节长度，用于存储压缩列表所占用的字节，当重新分配内存的时候使用，不需要遍历整个列表来计算内存大小。

zltail：存储一个无符号整数，固定四个字节长度，代表指向列表尾部的偏移量，偏移量是指压缩列表的起始位置到指定列表节点的起始位置的距离。

zllen：压缩列表包含的节点个数，固定两个字节长度，源码中指出当节点个数大于2^16-2个数的时候，该值将无效，此时需要遍历列表来计算列表节点的个数。

entryX：列表节点区域，长度不定，由列表节点紧挨着组成。每个节点可以保存一个字节数组或者是一个整数值！

zlend：一字节长度固定值为255，用于表示列表结束。

列表元素编码

上面介绍了压缩列表的总体内存布局，对于初entryX区域以外的四个区域的长度都是固定的，下面再看看entryX区域的编码情况。

每个列表节点由三部分组成：

压缩列表节点编码示意图

每个压缩列表节点区域头部包含两部分，一部分叫做previous length，另一部分叫encoding，最后是主体内容，叫做content，下面分别介绍他们：

previous length

用于存储上一个节点的长度，因此压缩列表可以从尾部向头部遍历（利用 ztail 和privious_entry_length），即当前节点位置减去上一个节点的长度即得到上一个节点的起始位置。previous length的长度可能是1个字节或者是5个字节，如果上一个节点的长度小于254，则该节点只需要一个字节就可以表示前一个节点的长度了，如果前一个节点的长度大于等于254，则previous length的第一个字节为254，后面用四个字节表示当前节点前一个节点的长度。这么做很有效地减少了内存的浪费。

encoding

节点的encoding保存的是节点的content的内容类型以及长度，encoding类型一共有两种，一种字节数组一种是整数，encoding区域长度为1字节、2字节或者5字节长。Redis作者巧妙的利用了前两个字节来表示content存储的内容类型和encoding区域的长度，我们先看看字节数组类型的encoding内容：

content为字节数组的encoding内容

再看看整数编码类型的encoding内容：

content为整数的encoding内容

content

content区域用于保存节点的内容，节点内容类型和长度由encoding决定，上面可以看出目前content的内容类型有整数类型和字节数组类型，且某些条件下content的长度可能为0。

相信到这里，我们都明白了压缩列表的原理，压缩列表并不是对数据利用某种算法进行压缩，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。下面我们看看压缩列表在Redis中的应用领域。

Redis中压缩列表的应用

Redis中，不同的数据类型广泛地应用了压缩列表编码，整理如下表：

连锁更新

每个节点的previous_entry_length属性都记录了前一个节点的长度

如果前一个节点的长度小于254，那么previous_entry_length属性需要用1字节长的空间来保存这个长度值
如果前一个节点的长度大于等于254，那么previous_entry_length属性需要5字节长的空间来保存这个长度值
考虑这样一种情况：在一个压缩列表中，有多个连续的、长度介于250字节到253字节之间的节点e1至eN
|zlbytes|zltail|zllen|e1|e2|e3|...|eN|zlend|
因为e1至eN的所有节点的长度都小于254字节，所以记录这些节点的长度只需要1字节长的previous_entry_length属性，换句话说，e1至eN的所有节点的previous_entry_length属性都是1字节长的。
如果我们将一个长度大于等于254字节的新节点new设置到压缩列表的表头节点，那么new将成为e1的潜质节点。
此时e1到eN的每个节点的previous_entry_length属性都要扩展为5字节以符合压缩列表对节点的要求，程序需要不断的对压缩列表进行空间重分配操作。
Redis将这种在特殊情况下产生的多次空间扩展操作称之为“连锁更新”。
除了添加新节点可能会引发连锁更新之外，删除节点也可能会连锁更新。
因为连锁更新在最坏情况下需要对压缩列表执行N次空间重分配操作，而每次空间重分配的最坏复杂度为O(N)，所以连锁更新的最坏复杂度为O(N2)。
注意的是，尽管连锁更新的复杂度较高，但它真正赵成性能问题的几率是很低的：
首先，压缩列表里要恰好有多个连续的、长度介于250字节至253字节之间的节点，连锁更新才有可能被引发，在实际中，这种情况并不多见；
其次，即使出现连锁更新，但只要更新的节点数量不多，就不会对性能造成任何影响：比如说，对三五个节点进行连锁更新是绝对不会影响性能的；

Redis中数据结构类型与压缩列表的应用

上表总结了压缩列表编码在Redis不同的数据类型中的应用，Redis一共支持五种数据结构类型，其中有三种数据结构在一定条件下会应用压缩列表，至于什么条件后面会分析，值得一提的是Redis当前支持的GEO（地理位置）对压缩列表也有应用，具体此处不做讨论。

Redis压缩列表应用分析

上面部分介绍了Redis压缩列表的原理与应用，下面简单分析一下，主要从通过试图回答一些问题来分析：Redis为什么使用压缩列表？使用压缩列表的好处是什么？使用压缩列表的好处还有什么？压缩列表的应用对与我们使用内存有没有什么启发？

Redis对于每种数据结构、无论是列表、哈希表还是有序集合，在决定是否应用压缩列表作为当前数据结构类型的底层编码的时候都会依赖一个开关和一个阈值，开关用来决定我们是否要启用压缩列表编码，阈值总的来说通常指当前结构存储的key数量有没有达到一个数值（条件），或者是value值长度有没有达到一定的长度（条件）。任何策略都有其应用场景，不同场景应用不同策略。为什么当前结构存储的数据条目达到一定数值使用压缩列表就不好？压缩列表的新增、删除的操作平均时间复杂度为O(N)，随着N的增大，时间必然会增加，他不像哈希表可以以O(1)的时间复杂度找到存取位置，然而在一定N内的时间复杂度我们可以容忍。然而压缩列表利用巧妙的编码技术除了存储内容尽可能的减少不必要的内存开销，将数据存储于连续的内存区域，这对于Redis本身来说是有意义的，因为Redis是一款内存数据库软件，想办法尽可能减少内存的开销是Redis设计者一定要考虑的事情。

另外，经过仔细琢磨，我认为使用压缩列表的好处除了节约内存之外，还有减少内存碎片的作用，我把这种行为叫做"合并存储"，也就是将很多小的数据块存储在一个比较大的内存区域，试想想，如果我们将要存储的数据都是很小的条目，我们为每一个数据条目都单独的申请内存，结果是这些条目将有可能分散在内存的每一个角落，最终导致碎片增加，这是一件令人头疼的事情。