redis底层数据结构之压缩列表

小灰灰 2023-06-26 05:43 19阅读 0赞

1. 问题

> 压缩列表在Redis中用来存储哪些类型的数据？

2. 介绍

压缩列表是redis为了节省内存而开发的，由一系列特殊编码的连续内存块组成的有序数据结构。

用途： zset键，哈希键

3. 底层实现

![image][]

说明：

ziplist\_bytes: 四个字节，记录占用总字节数

ziplist\_tail\_offset: 四个字节，代表第一个节点距离最后一个节点的字节数

ziplist\_length: 两个字节，代表entry节点个数

zlentry: 压缩列表实体

oxFF： 一个字节，代表固定结束符

zlentry数据结构

![20191230152641439.png][]

说明： previous\_entry\_length代表前一个节点的总字节数

encoding代表压缩列表存储数据的格式，可以存储16位，32位，64位的整数以及字符串

content代表具体的内容

4. 注意点

> 当哈希对象可以同时满足以下两个条件时， 哈希对象使用 `ziplist` 编码：
> 
> 1.  哈希对象保存的所有键值对的键和值的字符串长度都小于 `64` 字节；
> 2.  哈希对象保存的键值对数量小于 `512` 个；
> 3.  不满足上述条件，会使用hashtable

连锁更新：

> 假设原本 entry1 节点占用字节数为 211（小于 254），那么 entry2 的 previous\_entry\_length 会使用一个字节存储 entry1的字节数211，现在我们新插入一个节点 NEWEntry，这个节点比较大，占用了 512 个字节。
> 
> 那么，我们知道，NEWEntry 节点插入后，entry2 的 previous\_entry\_length 存储不了 512，那么 redis 就会重分配内存，增加 entry2 的内存分配，并分配给 previous\_entry\_length 五个字节存储 NEWEntry 节点长度。
> 
> 看似没什么问题，但是如果极端情况下，entry2 扩容四个字节后，导致自身占用字节数超过 254，就会又触发后一个节点的内存占用空间扩大，非常极端情况下，会导致所有的节点都扩容，这就是连锁更新，一次更新导致大量甚至全部节点都更新内存的分配。

5. 测试

![20191230153931126.png][]

[image]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOS8xMS8xMy8xNmU2NGE3NjRhZDFmY2Qz?x-oss-process=image/format,png
[20191230152641439.png]: https://img-blog.csdnimg.cn/20191230152641439.png
[20191230153931126.png]: https://img-blog.csdnimg.cn/20191230153931126.png