Redis Ziplist（压缩列表）

最新推荐文章于 2025-05-19 21:34:19 发布

一只小P熊

最新推荐文章于 2025-05-19 21:34:19 发布

阅读量3.2k

点赞数

CC 4.0 BY-SA版权

分类专栏：笔记

本文链接：https://blog.csdn.net/solo_jm/article/details/118520888

笔记专栏收录该内容

35 篇文章

订阅专栏

Redis中的ziplist是用于list、hash、zset的一种内存优化数据结构，它在节点数量少且元素为小整数或短字符串时使用。ziplist通过紧凑存储和前一个entry长度记录节省空间，但可能导致检索速度下降。其内部包含zlbytes、zltail、zllen等字段，每个entry由previous_entry_length、encoding和content组成。当插入或删除可能导致entry长度变化时，ziplist需要进行连续更新，虽然会影响性能，但在实际应用中影响较小，适用于存储少量数据的场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

简述

ziplist是Redis list、hash、zset的底层实现结构之一，当list、hash、zset中节点数量较少，并且存储的大多节点为小整数型，较短的字符串时，Redis就会使用ziplist作为list、hash、zset的底层实现。

牺牲时间换取空间

拿list来说，实现有双向链表、ziplist。当实现为双向链表时，节点会有pre和next指针，每一个指针占8个字节。而ziplist的entry中，用previous_entry_length保存上一个entry的长度，当上一个entry长度小于等于263字节时，previous_entry_length只占一个字节；大于263字节时，previous_entry_length占5个字节，并且ziplist存储是连续的内存空间，可以做压缩。当设计计算时，ziplist明显会比双向链表的指针检索慢，因此ziplist是牺牲时间换取空间的结构。

结构

在这里插入图片描述

zlbytes：记录整个ziplist的大小。
zltail：ziplist开始指针与最后一个entry之间的偏移量，通过该偏移量可以获得最后一个entry。
zllen：entry数量。
entry：存储具体数据的节点。
zlend：ziplist结尾标识。

entry

每一个entry由以下三个部分组成。
在这里插入图片描述

previous_entry_length：上一个entry的大小。
encoding：记录content的类型以及长度。
content：一个整形或者字节数组。
注：

previous_entry_length保存上一个entry的长度，当上一个entry长度小于等于263字节时，previous_entry_length只占一个字节；大于263字节时，previous_entry_length占5个字节。
可以通过previous_entry_length得到上一个entry，ziplist就是这样实现从尾到头的检索。

ziplist连续更新

假如现在ziplist中每一个entry的大小都是263字节，那么每一个entry的previous_entry_length都只占一个字节。假如此时在ziplist头部插入一个大于263的entry，那么，该entry往后的entry要把previous_entry_length修改为5个字节，而此时修改之后entry长度变为267，那么再下一个entry也要修改previous_entry_length的长度，以此类推。。。
删除节点的时候也会出现连续更新的情况。
虽然，发生连续更新时，ziplist的性能会大大的降低，但是实际情况下，极少会发生连续更新，而且ziplist都是存储少量的节点，哪怕发生一整个ziplist的更新，也不会占用大量时间。