1. 从双向链表到 ziplist：Redis 为什么非要自己造一个"链表"
很多人第一次见到 ziplist 时都会有个疑问：Redis 里面明明有双向链表，为什么还要搞一个 ziplist 出来？这个疑问背后，其实藏着 Redis 对内存效率近乎偏执的追求。
传统的双向链表，每个节点除了存储数据本身，还需要额外存储两个指针（prev 和 next）。在 64 位系统上，一个指针就是 8 字节，两个就是 16 字节。如果存储的数据本身只有十几个字节，那光指针开销就比数据还大。更糟糕的是，链表的每个节点都是独立 malloc 出来的，内存碎片率高，节点在内存里物理分散，遍历时无法充分利用 CPU 缓存，高速缓存命中率上不去。
ziplist 的思路完全不同：它把所有的 entry 按照顺序紧密排列在一块连续的内存空间里，每个 entry 不再用指针来串联，而是通过"前一个 entry 的长度 + 当前 entry 的编码信息"来推算下一个 entry 的位置。这样既保留了从头到尾、从尾到头的双向遍历能力，又把指针开销降到了极致。
我用一个简单的例子来感受一下差距。假设要存储三个小字符串：hello、world、ziplist。双向链表在每个节点上要花 16 字节存指针，三个节点就是 48 字节的纯开销；而 ziplist 只需要在每个 entry 里用 1 字节存前驱长度、1 字节存编码信息，剩余全部是数据本身。数据量越大，这个差距越明显。
所以 ziplist 的核心定位就一句话：面向小数据量场景的、内存密度极高的顺序型数据结构。它不是一个通用的链表替代品，而是 Redis 在特定阈值内为了节省内存所做的专项优化。
1.1 ziplist 内存布局：一个字节能省就省的设计哲学
ziplist 的整个结构就是一块连续内存，从头部到尾部依次划分成五个区域。理解这块布局，是理解后续所有源码逻辑的前提。
以 32 位系统上存储少量短字符串的 ziplist 为例，内存中大致长这样：
- zlbytes：4 字节，记录整个 ziplist 占用的总字节数，用于在需要扩展时快速判断长度。
- zltail：4 字节，记录从头到最后一个 entry 起始位置之间的偏移量，让程序能从头部直接跳到尾部，无需遍历。
- zllen：2 字节，记录 entry 的总数量。
- entries：若干连续排列的 entry，每个 entry 又由 prevlen、encoding、data 三个部分组成。
- zlend：1 字节，固定值 255（0xFF），标记 ziplist 的结束。
这里有一个非常精妙的取舍：zllen 只分配了 2 字节，最大只能表达 65535。当 entry 数量超过这个值时，zllen 就固定为 65535，真实数量只能靠遍历统计。为什么 Redis 宁可让你遍历，也不肯把 zllen 扩成 4 字节？因为绝大多数 ziplist 根本达不到这个数量级，2 字节换来的是每个 ziplist 节省 2 字节的头部开销。头部虽小，但 Redis 里可能存在成千上万个 ziplist，累积起来就是可观的几百 MB 内存。
1.2 prevlen：1 字节与 5 字节的切换逻辑
每个 entry 的起始位置是 prevlen 字段，它记录前一个 entry 的总字节长度。这个字段本身不是定长的，而是根据前一个 entry 的长度动态选择：
- 前一个 entry 长度小于 254 字节：prevlen 只占 1 字节，直接存长度值。
- 前一个 entry 长度大于等于 254 字节：prevlen 占 5 字节，第一字节固定为 0xFE，后四字节以小端序存储真实长度。
为什么阈值偏偏是 254？因为 0xFF 已经被 zlend 占用了。如果 prevlen 也用 0xFF 来标记"长编码"，遍历到末尾时就会产生歧义，分不清当前字节到底是 ziplist 结束标记，还是一个 entry 的前驱长度标记。所以长编码的标志字节必须避开 0xFF，选 0xFE 是合理的。
从表尾向表头遍历时，Redis 依靠 zltail 先跳到最后一个 entry 的起始位置，然后根据当前 entry 自己的长度往前推，找到它的 prevlen，再通过 prevlen 跳到前一个 entry。这套逻辑不依赖任何指针，纯粹靠长度推算，所以每个 entry 的长度字段是否准确，直接决定整个结构能否被正确解析。
1.3 encoding 与 data：数据越长，编码越宽，但绝不浪费
encoding 字段是 ziplist 的灵魂，它负责告诉解析器：后面这份数据到底是什么、占多少字节。
对于字符串，ziplist 按长度分了三档编码：
- 长度不超过 63 字节：encoding 占 1 字节，高 2 位为 00，低 6 位存字符串长度。
- 长度不超过 16383 字节：encoding 占 2 字节，高 2 位为 01，低 14 位存字符串长度。
- 长度大于 16383 字节：encoding 占 5 字节，高 2 位为 10，低 32 位存字符串长度。
对于整数，ziplist 的编码更极致，直接按整数的大小选择存储宽度：
- 0 到 12 之间的整数：连 data 字节都不需要，直接编码进 encoding 里。
- int8：占 2 字节，第一个字节高 4 位为 1100，第二个字节存值。
- int16：占 2 字节，第一个字节高 4 位为 1101，第二个字节存值。
- int24：较新版本引入，占 4 字节，第一字节高 4 位为 1110，后三字节存值。
- int32：占 4 字节，第一字节高 4 位为 1111，后四字节存值。
- int64：占 8 字节，第一字节高 4 位为 1111，后八字节存值。
这个设计最值得学习的一点是：Redis 在编码时不是简单地"能表达就行"，而是尽可能地"用最少的字节来表达"。整数 12 和字符串 "12" 在 ziplist 里的存储方式是截然不同的，前者直接嵌进 encoding 里，后者要额外占用 data 空间。这种对数据类型的感知和处理能力，是通用序列化框架里很少见到的。
2. 级联更新：ziplist 最隐蔽也最值得警惕的代价
2.1 什么是级联更新（Cascade Update）
级联更新是 ziplist 的经典话题。先描述一下触发场景：
假设 ziplist 里有连续一串 entry，每个 entry 的长度都在 250 到 253 字节之间。这种情况下，每个 entry 记录前驱长度时，只需要 1 字节就能存下。此时所有 entry 的 prevlen 都是 1 字节。
现在，我们往中间插入一个新 entry，它的长度恰好是 300 字节。这个新 entry 的下一个 entry，它的 prevlen 原本是 1 字节，现在必须升级成 5 字节才能存下 300 这个值。于是问题来了：prevlen 从 1 字节变成 5 字节，会导致这个 entry 自身总长度增加 4 字节，那么它下下一个 entry 的前驱长度也变了，也要同步升级 prevlen。如此一环扣一环地传导下去，直到遇到一个长度小于 254 字节的 entry 才停下来。
最坏情况下，整个 ziplist 的所有 entry 都得重新分配内存、移动数据，插入操作的复杂度从 O(1) 恶化到 O(N)。删除操作也同理——当某个 entry 的前驱长度从 254 以上降为 254 以下时，它的 prevlen 从 5 字节回退到 1 字节，同样会引发连锁的长度变化。
2.2 为什么不直接固定 prevlen 为 5 字节
不少初学者会问：与其搞这么复杂的动态编码，为什么不把每个 entry 的 prevlen 都固定成 5 字节，彻底消灭级联更新？
答案是内存开销不可接受。假设 ziplist 里有 100 万个 entry，每个 prevlen 固定 5 字节，相比动态编码时常见的 1 字节，要额外多出约 4 百万字节，也就是差不多 4 MB。Redis 是内存数据库，任何一个无谓的固定开销都可能被放大成全局性的内存浪费。绝大多数 ziplist 的 entry 长度都远小于 254 字节，1 字节编码才是常态，级联更新在真实业务里属于极小概率事件。
另一种替代方案是像普通链表那样，用指针来定位前驱。但指针在 64 位系统上是 8 字节，远大于 1 字节的 prevlen，而且破坏了连续内存布局，彻底放弃了缓存友好的特性。ziplist 用"连续内存 + 变长编码"换来了极高的内存密度，代价就是偶尔出现的级联更新，这个取舍我认为相当划算。
2.3 日常开发中如何应对级联更新
级联更新虽然听着吓人，但实际工程里并不需要过度恐慌。绝大多数业务数据不会出现"连续上百个 entry 的长度都在 250 到 253 字节"这种极端场景。真正值得警惕的场景有两类：
第一类是批量写入长字符串。如果你系统的某些 key，value 是很大的字符串或序列化对象，而且这些对象长度恰好落在 250 到 253 字节附近，那么每次插入都可能引发级联更新的连锁反应。
第二类是删除场景。删除一个大 entry 后，它的后继 prevlen 可能从 5 字节回退到 1 字节，这同样会触发连锁更新。如果删除操作非常频繁且数据长度分布极端，就可能在 DELETE 命令上出现意外的耗时。
如果想观察级联更新的实际发生，可以在 Redis 源码里给 ziplistCascadingUpdate 相关路径加日志，或者在测试环境构造一串长度在 250 到 253 字节之间的字符串，然后插入一个长 entry，观察内存分配次数和耗时变化。这种"实验性验证"比凭空担忧有用得多。
3. ziplist 的查找与遍历：位运算主导的高效解析
3.1 按索引查找的完整路径
ziplist 的查找入口是 ziplistIndex，它支持正索引和负索引。正索引从 0 开始，指表头方向；负索引从 -1 开始，指表尾方向。源码的处理逻辑是：先根据索引正负，决定从 zlbytes 方向还是 zltail 方向出发，然后沿着 prevlen 逐个跳转。
需要注意的一点是：ziplist 并不支持 O(1) 的随机访问。哪怕只是取第 100 个元素，也必须从头或尾部遍历，逐条解析出每个 entry 的 prevlen 和 encoding，才能确定下一个 entry 的起始位置。Redis 给 ziplist 设置 128 个 entry 的数量上限（list-max-ziplist-size 可配置），就是为了保证在这个规模下，遍历的代价足够小。
很多人会误以为 zltail 能带来"直接跳到末尾"的能力，实际上 zltail 只是拿到了最后一个 entry 的偏移量，它帮助的是一次从尾到头的遍历，而不是 O(1) 地取最后一个元素的值。想取最后一个 entry 的数据，仍然要先解析它的 encoding 和 data 字段。
3.2 从 ziplist 到跳表：Redis 的"规模分治"思路
理解 ziplist 的定位之后，再看 Redis 的整体数据结构布局就清晰很多。Redis 对同一个逻辑结构，在不同规模下会采用不同的物理实现。
比如有序集合（zset），当元素数量少、元素长度短时，底层用 ziplist 存储，保证内存密度；当元素数量超过阈值或者某个元素长度超过 64 字节时，就升级成 skiplist 加 dict 的组合结构，让大规模数据享受 O(logN) 的查找效率。
这个"规模分治"的思路在 Redis 7.0 之后的 listpack 设计中也延续了下来。listpack 是 ziplist 的替代者，本质上是同一思想的演进版。对我们做系统设计的人来说，这个思路最大的启示是：没有必要让一种数据结构适配所有场景。小数据量追求紧凑和低开销，大数据量追求性能和可扩展性，按需切换，才是工程上的常态。
3.3 遍历时容易被忽视的边界条件
ziplist 没有哨兵节点，一切遍历都必须靠 zlend 的 0xFF 来判断是否到达末尾。每次移动指针后，都必须做一个安全检查：如果当前位置的值是 0xFF，说明 ziplist 结束了；否则才继续解析 entry。
解析 5 字节 prevlen 时，还有另一个容易踩的坑：直接用 uint32_t 指针去强转内存地址并取值，这在某些 CPU 架构上会因为内存对齐问题导致崩溃。Redis 源码的做法是逐字节拷贝拼接，既不依赖对齐规则，也保证了跨平台可移植性。你自己移植或者仿写这块代码时，务必沿用逐字节拷贝的方式，不要想当然地用强转。
4. ziplist 的三种核心操作与内存分配策略
4.1 插入操作：__ziplistInsert 的执行链路
插入操作对外暴露的是 ziplistInsert，内部真正干活的是 __ziplistInsert。整个流程可以拆成六步：
第一步，根据索引定位到插入位置 p。
第二步，计算新 entry 需要的总长度 reqlen。这一步要综合考虑 prevlen 编码、encoding 编码和 data 长度三部分的实际占用。
第三步，读取 p 位置前一个 entry 的长度，决定新 entry 的 prevlen 是 1 字节还是 5 字节。
第四步，判断是否触发级联更新。如果触发，需要先计算需要额外扩展的字节数，然后一次性完成内存重分配。
第五步，调用 ziplistResize 重新分配内存，把插入点之后的所有数据后移。
第六步，在新位置上写入新 entry 的 prevlen、encoding 和 data，然后更新 zltail 和 zllen。
这里最关键的注意点是：ziplist 的一切操作函数，在可能触发 realloc 时，都会返回新的 ziplist 头指针。调用方如果不接收这个返回值，还继续使用旧的指针，就会踩到"realloc 后旧指针失效"的经典坑。在业务代码里封装 ziplist 操作时，一定要以返回值作为最新指针继续使用。
4.2 删除操作：__ziplistDelete 的批量搬迁
删除操作的逻辑与插入对称，但实现上更依赖"批量搬迁"的思路。先定位要删除的第一个 entry，然后从它开始，逐条跳过所有待删除的 entry，找到第一个不需要删除的 entry，接着一次性把这段区间之后的所有数据前移，最后统一更新 zltail 和 zllen。
批量删除的核心收益在减少 memmove 次数。如果逐个删除，每次都触发一次数据搬移，性能会差很多。Redis 源码里处理删除时，先计算出待删除区间的总字节数，再执行一次 memmove，这个细节值得我们在写类似代码时借鉴。
删除同样需要处理级联更新。删除一个长 entry 后，它的后继 prevlen 可能从 5 字节回退到 1 字节，引发的连锁反应和插入场景没有本质区别。测试用例里，删除触发的级联更新往往是比插入更难构造的场景，排查问题时也要记得覆盖。
4.3 内存重分配与数据搬迁的实现细节
ziplist 的内存重分配统一走 ziplistResize，内部封装了 zrealloc。Redis 对 zrealloc 的特殊约定是：如果新长度为 0，就释放内存并返回 NULL，此时调用方要处理空指针的情况。ziplist 内部分配内存后，会有专门的断言和校验逻辑，确保新内存非空。
另一个细节是：插入和删除涉及的数据搬移统一使用 memmove，而不是 memcpy。memcpy 在源和目的区域重叠时是未定义行为，memmove 则保证了重叠场景下的正确性。ziplist 里的数据搬移，源和目的区域几乎必然重叠，所以 memmove 是唯一正确的选择。
在实际业务里，如果需要批量往一个 ziplist 里插入大量 entry，千万不要逐个调用 ziplistInsert。每调一次就可能触发一次 realloc 和数据搬移，效率极低。更合理的做法是：把新数据整体构造完成后，直接替换掉旧的 ziplist，把多次 realloc 合并成一次。
5. 从 ziplist 到 listpack：编码演变背后的设计取舍
5.1 ziplist 的编码转换：小数据变大后发生了什么
当 ziplist 里的 entry 数量超过 list-max-ziplist-size 配置的阈值，或者单个 entry 的长度超过 list-max-ziplist-value（默认 64 字节）时，Redis 会执行编码转换。
以哈希类型为例，转换逻辑是：把 ziplist 里的每一对 field 和 value 依次读出，写入哈希表的 dict 结构中，最后释放旧的 ziplist。整个转换是一次性的全量操作，不是增量完成的。
这意味着，如果某个 key 的数据规模从小突然膨胀到大，Redis 需要一次性分配一块较大的哈希表空间，并重新插入所有元素，这个过程可能带来明显的耗时和内存峰值。在业务高峰期，如果预先知道某些 key 会快速增长，最好提前做好容量规划，避免在流量高峰触发转换导致延迟抖动。
5.2 listpack 是如何消灭级联更新的
listpack 是 Redis 7.0 中用来替代 ziplist 的紧凑数据结构，它解决的核心问题正是级联更新。
ziplist 的请求链问题是每个 entry 存的是前一个 entry 的长度，前驱一变，后续全部跟着变。listpack 做了一个调整：每个 entry 保存的是当前 entry 自身的长度，而不是前一个 entry 的长度。这样在插入或删除时，受影响的范围只限于当前节点本身和它的 immediate 邻居，不会像 ziplist 那样一环扣一环地传递下去。
listpack 还统一了编码格式。每种类型都通过 encoding 字段的高 4 位标识类型，解析时不再像 ziplist 那样混杂多种位模式，逻辑上直观不少。如果你在选择数据结构方案时，既想要 ziplist 的内存紧凑性，又不想承担级联更新的风险，listpack 是最合适的选择。
6. 通过 ziplist 源码还能学到什么
6.1 内存紧凑编码的设计范式
ziplist 是研究内存紧凑编码的绝佳样本。它从头到尾贯彻了一个核心思想：任何能少用 1 字节的地方，绝不多用 1 字节。
这个思想可以提炼成三条范式：
- 变长编码：根据数据实际大小动态选择编码宽度，而不是固定占位。
- 连续存储：所有数据放在一块连续内存里，最大化 CPU 缓存命中率。
- 末端哨兵：用 0xFF 做终止标记，避免额外的长度字段。
这三条范式在现代数据结构中反复出现，比如压缩算法里的变长整数（Varint）、列式存储里的编码推断。掌握了 ziplist 的编码思路，再回头看其他紧凑结构，会有一通百通的感觉。
6.2 从 ziplist 看 Redis 的防御性编程
ziplist 源码里可以看到大量防御性判断：指针为空时直接返回；长度检查不通过时拒绝操作；转换过程中出错时回退到原有结构。Redis 对运行安全极为看重，任何一句可能导致崩溃的代码都不允许存在。
比如查找函数在每次迭代时，都会先校验当前指针是否越界，再解析数据。这套"先校验、再使用"的风格，在其他 Redis 模块里也处处可见。对我们写业务代码的启发是：凡是涉及外部输入或不可信长度的场景，都要先做边界校验再执行动作，宁可多写几个 if，也不要留一个崩溃隐患。
6.3 学习 ziplist 的推荐路径
如果你想系统学习 ziplist，我建议按下面的路径走：
第一步，把 ziplist 的编码规则手抄一遍。prevlen、encoding、data 三种字段的编码规则，抄一遍比看十遍都记得牢。
第二步，打开源码，从 ziplistNew 开始，按顺序读 ziplistPush、ziplistIndex、ziplistInsert、ziplistDelete。读的同时，最好在纸上画一下内存布局和指针移动过程。
第三步，把 ziplist 和 listpack 对照着读，重点看 listpack 为了消除级联更新，到底改变了哪些编码约定。
第四步，也是最重要的一步：写一个小实验程序，在内存里构建一个 ziplist-like 结构，打印每个字节的十六进制值，验证你对编码规则的理解是否准确。理论再熟，不如亲手验证一次。
7. 动手验证：用一个小实验理解 ziplist 编码规则
7.1 实验目标与准备
下面我用一段简化的 Python 脚本，手工构建 ziplist 并解析它。这个脚本不依赖 Redis 源码，只需要 Python 内置的 struct 模块就能跑，目的是让你直观看到 ziplist 的核心编码规则。
7.2 构建与解析脚本
import struct def build_entry(prevlen, data): if prevlen < 0xFE: prevlen_bytes = struct.pack('<B', prevlen) else: prevlen_bytes = struct.pack('<BI', 0xFE, prevlen) if len(data) < 64: encoding = bytes([0x00 | len(data)]) payload = data.encode('utf-8') else: encoding = struct.pack('<H', 0x01 << 14 | len(data)) payload = data.encode('utf-8') return prevlen_bytes + encoding + payload def parse_ziplist(raw): zlbytes = struct.unpack('<I', raw[0:4])[0] zltail = struct.unpack('<I', raw[4:8])[0] zllen = struct.unpack('<H', raw[8:10])[0] print('zlbytes:', zlbytes) print('zltail:', zltail) print('zllen:', zllen) pos = 10 entries = [] while pos < len(raw) and raw[pos] != 0xFF: prevlen = raw[pos] if prevlen == 0xFE: prevlen = struct.unpack('<I', raw[pos+1:pos+5])[0] pos += 5 else: pos += 1 encoding = raw[pos] pos += 1 if (encoding >> 6) == 0: slen = encoding & 0x3F entries.append(raw[pos:pos+slen].decode('utf-8')) pos += slen else: entries.append(f'type-{encoding >> 6}') pos += 1 print('entries:', entries) entries = [b'hello', b'world', b'ziplist'] raw = bytearray() prev_len = 0 for e in entries: raw += build_entry(prev_len, e) prev_len = len(e) + 1 + (1 if len(e) < 64 else 2) ziplist = struct.pack('<IIH', len(raw) + 11, 10, len(entries)) + bytes(raw) + b'\xff' parse_ziplist(ziplist)这段脚本简化了整数编码和 5 字节字符串编码，但核心的 prevlen、短字符串 encoding 逻辑是完整的。运行后，打印的 entries 列表应该会正确还原出存储的字符串。
7.3 实验的重点观察项
建议你按三个阶段逐步观察：
第一阶段，看 zlbytes、zllen 是否和预期一致。手工构建时 zltail 是写死的，真实 ziplist 里它应该是最后一个 entry 的起始偏移量，但通过修改代码你也一样能体会到它的作用。
第二阶段，修改某个 entry 的长度，让它的 prevlen 从 1 字节变成 5 字节，观察后续 entry 起始位置的变化，相当于在验证级联更新的长度传递逻辑。
第三阶段，尝试放进一个长度超过 16383 的字符串，观察 encoding 字段从 1 字节升级到 5 字节的过程，这会让你对大字符串编码路径有直觉。
这种"手动构造 + 观察字节"的方式，比单纯读源码更能建立直觉。读代码时“感觉懂了”和亲手验证后的“真的懂了”，差距非常大。
8. 我的实践经验与最后提醒
8.1 在业务中合理调整 ziplist 相关配置
如果你的 Redis 版本还在 7.0 之前，哈希和有序集合还在使用 ziplist 编码，那配置参数值得认真调一下。默认的 list-max-ziplist-size 是 128，list-max-ziplist-value 是 64。
在真实业务里，如果频繁读取的哈希 key 字段很多，可以考虑适当调小 size 阈值，提前切换到 dict 编码，避免数据膨胀时才做昂贵的转换。如果单个 value 经常是长字符串，比如序列化后的 JSON 对象，则应该调小 value 阈值，因为大字符串会显著降低 ziplist 的内存密度优势。
8.2 排查大 key 与慢查询时，多想想底层结构
我在实际排查中遇到过不少次"某个哈希 key 突然变慢"的情况，最后定位下来都是因为元素数量超过了 ziplist 阈值，触发了一次全量编码转换。转换过程本身的耗时并不大，但转换后查询路径和内存使用模式都会变化，如果恰好在高并发时段触发，延迟抖动会相当明显。
还有一个容易被忽略的点：编码转换不只是数据结构变化，还意味着旧内存释放、新内存分配，可能导致内存碎片率上升。如果你在 INFO 命令里看到 mem_fragmentation_ratio 显著高于 1.5，同时又有大量元素数量在阈值附近徘徊的 key，可以考虑主动重建这些 key，把编码统一到合适的形式。
8.3 读源码要带着问题去读
最后分享一点个人体会：读 ziplist 这类源码，千万不要从头到尾一行一行地读，那样很容易在细节里迷失。我建议带着这几个问题去读：
- ziplist 是如何做到双向遍历的？
- 为什么 ziplist 会有级联更新？
- 连续内存结构在插入和删除时，最关键的代价是什么？
- 为什么 listpack 能彻底消除级联更新？
带着问题去读，边读边对照内存布局示意图，读完之后再用实验脚本验证一遍编码规则。这样一轮下来，你会发现 Redis 的整体设计思路清晰了很多。ziplist 只是 Redis 内存数据结构中的一小块拼图，但它浓缩了紧凑编码、内存分配、防御性编程和性能取舍的几乎所有核心命题，非常值得花时间读透。
