Redis中ziplist与quicklist解析与对比小结_Redis

一、背景 — 为什么要有多种“列表（list）”编码

在内存数据库 redis 中，列表（list）是常用数据类型之一，用于实现队列、堆栈、消息队列、任务队列等场景。
不同场景对内存使用与访问效率有不同要求：少量元素 → 希望节省内存；大量元素或频繁插入/删除 → 需要高性能操作。
因此redis 设计者提供了不同的“编码方式”（encoding）来存储 list 对象，以兼顾 空间效率 与 操作效率。

在历史发展中，redis 对 list 的编码方式经历了如下阶段：

早期：使用 双向链表（linkedlist） 或 压缩列表（ziplist），两种可选。
从 redis 3.2 版本起，引入 quicklist，作为新的默认结构，取代了 ziplist + linkedlist 的混合策略。

下面分别介绍 ziplist 和 quicklist 的结构与特性，然后比较优缺点。

二、ziplist —— 压缩列表（compact list）

2.1 ziplist 是什么

ziplist 是 redis 提供的一种“紧凑型列表结构（compact list）”。它将多个 list 元素连续地存放在一块 连续内存（contiguous memory block） 中。
每个 entry（元素）包含必要的 metadata（如前一个 entry 长度、当前 entry 长度、数据内容等），因此 ziplist 可以存放不同长度的数据项（字符串、整数等），而不需要为每个元素单独分配内存。
因为内存连续、元素紧凑，ziplist 在内存占用上非常高效 — 对于存储少量、短字符串／整数列表时，能节省大量内存。

ziplist结构如图所示，参考redis面试题：

下边的图也可加深理解

ziplist的各字段含义如下。

zlbytes：压缩列表的字节长度，占4b，因此压缩列表最长 2³²‑1b。
zltail：压缩列表尾元素相对于压缩列表起始地址的偏移量，占4b。
zllen：压缩列表的元素数目，占2b；当压缩列表的元素数目超过65535（2¹⁶‑1）时，zllen 无法存储，此时必须遍历整个压缩列表才能获取元素数目。
entry1、entr2y：压缩列表存储的若干个元素，可以是字节数组或者整数，长度不限；
zlend：压缩列表的结尾，占1b，固定为0xff。

对于每一个entry元素来讲

entry 结构包含三个字段：

prelen
- 记录前一个元素的长度，用于从后向前遍历。
- 前一个元素长度 < 254b → 占 1b。
- 前一个元素长度 ≥ 254b → 占 5b（首字节为 0xfe，后 4b 为实际长度）。
encoding
- 表示 data 的数据类型（整数或字节数组）。
- 长度可变（1b、2b 或 5b），通过开头的比特区分。
- 同时可包含字节数组的长度信息（如 6bit、14bit 或 32bit 表示长度）。

以下是encoding字段的元素编码

编码 (encoding) 标识 / 类型	encoding长度	说明 / 含义 (简要)
00pppppp	1b	表示一个 string，长度 ≤ 63 字节。
01pppppp + qqqqqqqq	2b	表示一个 string，长度 ≤ 2¹⁴‑1字节。
10000000 + 4 bytes length	5b	表示一个较长 string（长度 ≤ 2³²‑1字节）。
11000000	1b	表示一个 int16_t（16-bit 整数）元素。
11010000	1b	表示一个 int32_t（32-bit 整数）元素。
11100000	1b	表示一个 24-bit 整数编码（special 24-bit 整数）。
11111110	1b	表示一个 int8_t（8-bit 整数）元素。
1111xxxx	1b	xxxx表示范围为 0–12 的整数。

data
- 实际存储的数据，可以是整数或字节数组，长度由 encoding 决定。

2.2 ziplist 的适用条件（默认策略）

在 redis 配置文件（或编译时默认）中，对于 list、hash、zset 等类型，会设置参数来决定是否使用 ziplist，例如：

list-max-ziplist-entries：限制 ziplist 中元素（entry）个数
list-max-ziplist-value：限制每个 entry 的最大字节数（value 大小）

当元素数量或元素大小超过这些限制时，redis 会放弃 ziplist 编码，转为其他更适合的编码方式（在老版本可能是 linkedlist，现在是 quicklist）。

2.3 ziplist 的优点与缺点

优点：

内存利用率高 — 非常节省内存空间，适合存储少量、小数据。
内存连续，有利于 cpu 缓存和遍历效率。

缺点 / 缺陷：

对修改操作（插入 / 删除 / 更新）不友好 — 因为要保持连续内存，一旦中间插入或删除，就可能触发内存重新分配和数据搬移（realloc + memcpy），代价高昂。这里会涉及连锁更新问题。
当元素较多或较大时，ziplist 会非常臃肿或重复 realloc，性能和稳定性都不理想。
因此，ziplist 更适合“短小、稳定、不频繁变更”的列表数据，不适合大数据量或高频写入场景。

三、quicklist —— 快速列表（quicklist）

3.1 quicklist 是什么

quicklist 是从 redis 3.2 开始引入的 list 编码方式，用于替代早期的 ziplist /adlist 编码。
它本质上是 双向链表 + 压缩子列表 的混合结构：一个 quicklist 是一个双向链表，而链表的每个节点（quicklistnode）内部持有一个 ziplist来存储一段连续的元素。
这样的设计兼顾了链表和 ziplist 各自的优点。

3.2 quicklist 的结构与配置参数

quicklist 的主要结构由 quicklist 和 quicklistnode 两个 c 结构体定义，在 redis 源码中（例如 quicklist.h / quicklist.c）可以查看。

结构图

在quicklist中，关键字段包括：

head / tail：指向链表头尾节点。
count：list 中所有元素entry的总数。
len：quicklistnode 节点数量。
fill：用于控制每个 ziplist 容量上限entry 数量或字节大小，通过 list-max-ziplist-size 配置项设定。
compress：用于控制压缩深度，即链表两端多少个节点不压缩，中间节点可被压缩以节省内存，通过 list-compress-depth 配置项控制。
每个 quicklistnode 包含指向内部 ziplist（或 listpack）的指针 zl，大小 sz，元素计数 count 等信息。

⚠️ 注意：在 redis 最新版本中（例如 7.x），listpack 已经逐步取代 ziplist 作为内部压缩子列表结构，但 quicklist 的设计思想不变 —— 分段 + 链表 + 压缩子列表。

3.3 quicklist 的优点

兼顾空间与效率：通过将列表拆成多个小段（ziplist），既避免了大型链表带来的内存碎片和高 overhead，也避免了大型 ziplist 带来的频繁 realloc 问题。
快速头尾操作（push/pop）：因为 quicklist 是链表结构，在头尾插入删除是 o(1) 操作，非常高效，适合队列／栈等操作频繁场景。
压缩可选：中间节点可以压缩（lzf 等算法／listpack 压缩），节省内存；而头尾保留原始以保证访问性能。
灵活适应不同场景：既适合存储小量短元素，也适合存储大量元素或长列表。

3.4 quicklist 的限制与注意事项

如果配置不当（ziplist 内部过大、压缩设置不合理），可能出现性能开销过重，或内存碎片／压缩开销问题。
quicklist 内部实现比简单链表或数组复杂，对于某些极端访问模式（大量随机访问中间、频繁跨节点访问）可能不如纯数组或其他结构高效。

quicklist 的两种极端情况如下：

1. 当 ziplist 节点过多时，quicklist 退化为双向链表。最极端的情况是每个 ziplist 节点只包含一个 entry，即一个元素对应一个节点。
2. 当 ziplist 节点过少时，quicklist 退化为 ziplist。最极端的情况是整个 quicklist 中只含有一个 ziplist 节点。

对于非常频繁的随机访问或修改，可能需要谨慎评估是否适合使用列表结构。

四、ziplist vs quicklist —— 对比总结

特性 / 维度	ziplist	quicklist
内存布局	连续内存 block（compact）	链表 + 多个 ziplist／listpack segments
内存开销	低，连续、紧凑	较高（链表＋子列表）但比纯链表低
适合场景	元素少、数据小、读不频繁修改	元素多、队列 / 栈 / 批量 push/pop / 变长频繁
插入／删除性能	中间插入删除开销大（可能 memcpy）	头尾 o(1)，节点级调整，较稳定
内存碎片	几乎无	较少（链表 + 子列表）
压缩 / 节省空间	默认紧凑	可配置压缩，兼顾效率
redis 中默认支持	早期版本	redis 3.2+ 默认