详解redis数据结构之紧缩列表

详解redis数据结构之紧缩列表

redis使用紧缩列表作为列表键和哈希键的底层实现之一。当一个列表键只包括少许的列表项，并且每一个列表项都是由小整数值或是短字符串组成，那末redis就会使用紧缩列表存储列表项；同理，当一个哈希表包括的键值对都是由小整数值或是短字符串组成，并且存储的键值对数目不多时，redis也会使用紧缩列表来存储哈希表。以下是紧缩列表存储结构：

• zlbytes长度为4个字节，记录了全部紧缩列表所占用的字节数
• zltail长度为4个字节，记录了紧缩列表起始位置到紧缩列表尾节点的偏移量
• zllen长度为2个字节，记录了当前紧缩列表中所具有的entry的数量
• entryX存储了实际的对象，其长度根据具体的实体而定
• zlend长度为1个字节，保存了十进制的255，用于标记紧缩列表的末端

通过上面的结构可以看出，紧缩列表存储数据的为一全部数组，在这个数组中前12个字节固定保存了zlbytes、zltail和zllen三个表征全部紧缩列表属性的数据，而后续的数组则保存了entry的数组，最后通过一个字节长度的属性zlend来记录当前紧缩列表已结束。

在上述结构中，我们并没有看到任何属性用以表征每一个entry的长度及其存储的数据类型，如字符串或是整型值，而紧缩列表整体实际上是一个数组，因此如果不对这两个类型的数据进行记录那末将没法对每个entry进行辨别。实际上，每一个entry是由三部份组成：previous_entry_length、encoding和content。

1.previous_entry_length为一个整型值，记录了前一个节点整体占用字节的长度，当前一个节点的长度小于254时，该属性占用一个字节，当前一个节点长度大于等于254时，该属性则占用5个字节，其第一个字节会保存十进制的0xFE，即十进制的254，后四个字节则保存了前一节点的长度；

2.encoding属性长度不定，其主要保存了当前节点的编码格式和节点的长度。当encoding属性的最高两位为00、01或10时，表示其存储的是字节数组。其为00时，encoding占用1个字节，其后6位保存了content属性的长度；为01时，encoding占用2个字节，其后14位保存了content属性的长度；为10时，则其后38位保存了content属性的长度。当encoding属性的最高两位为11时，表示其存储的是一个整型值，并且此时encoding属性的长度为1个字节。当11后两位，也即第三位和第四位为00时，表示存储的是int16_t类型的整数，当其为01时，表示存储的是int32_t类型的整数，当其为10时，表示存储的是int64_t类型的整数，当其为11时，表示存储的是24位有符号整数。（这四种情况后续位上的值都为0）当11后五位为1，并且最后一名为0时，表示存储的是8位有符号整数。当11后两位为11时，那末该节点就没有content属性，该节点的属性值保存在encoding属性的后四个位上，并且其值要介于0~12之间。

3.content属性保存了该节点的实际的字符串或整型数据。

感谢浏览，希望能帮助到大家，谢谢大家对本站的支持！

本文来源：https://www.yuntue.com/post/153069.html | 云服务器网，转载请注明出处！