Redis ziplist、quicklist 和 listpack

Mon, 03 Mar 2025 22:44:38 +0800

ziplist

为什么需要 ziplist？

由于 Redis 是一个内存型数据库，因此在使用相应的数据结构时需要1）节省内存空间，2）提高操作效率。传统的包含指向相邻节点指针的双向链表中在内存使用和操作效率上存在一些问题：

存储指针需要额外的内存空间，且该空间在指定硬件平台上是固定的。当存储的数据长度较小时，指针占用空间甚至会超过数据占用空间。
传统双向链表中相邻节点在内存中并不连续，这虽然利用了碎片化的内存空间，但是由于增加了一次额外的指针索引，遍历效率低。

ziplist 是 Redis 中设计的一种内存紧凑型的数据结构，可以用来代替传统的双向链表结构。ziplist 使用一块连续的内存空间，通过在每个节点中存储当前及前一个节点的长度来实现双向遍历，节省内存空间，操作效率高。

ziplist 是什么？

下面给出了压缩列表的结构示意图，包括 10byte 的表头元数据，若干个列表节点以及最后的 1byte 的结束标识符。

| zlbytes | zltail | zllen | entry1 | entry2 | ... | entryN | zlend |

# 各部分说明
zlbytes: 整个压缩列表占用的字节数，uint32_t(4byte)
zltail: 压缩列表表尾节点距离压缩列表的起始地址有多少字节，uint32_t(4byte)
zllen: 压缩列表包含的节点数，uint16_t(2byte)，当该属性值为 UINT16_MAX 时，真实节点数量需要遍历整个压缩列表才能得到
entry: 压缩列表节点
zlend: 用于标记压缩列表末端的特殊值(0xFF)，1byte

每个压缩列表的节点中存储的内容可以看作一个字节数组或者整数值，每个节点包含以下三部分内容：

| previous_entry_length | encoding | content |

# 各部分说明
previous_entry_length: 记录前一个节点的长度，长度为 1byte 或 5byte
    - 前一个节点长度小于 254 字节时，previous_entry_length 长度为 1 字节，记录前一个节点的长度
    - 前一个节点长度大于等于 254 字节时，previous_entry_length 长度为 5 字节，其中第一个字节设置为 0xFE，后面的四个字节用于记录前一个节点长度
encoding: 记录节点的 content 中所保存数据的类型和长度
    - 一字节(00开头)、两字节(01开头)或五字节(10开头)的表示字节数组编码，去除最高两位之后的其他位是字节数组长度
    - 一字节长(11开头)的表示整数编码，去除最高两位后的其他位可以用于标识整数的类型和位宽
content: 节点值，可以是一个字节数组或者整数值，由 encoding 属性决定

ziplist 有什么问题？

前面提到 ziplist 通过使用连续的内存块和精心设计的编码格式来保存列表数据，并实现双向检索的功能。但是，使用 ziplist 仍然存在一些缺点：

Redis on Lishengxie

Redis ziplist、quicklist 和 listpack

ziplist

为什么需要 ziplist？

ziplist 是什么？

ziplist 有什么问题？