理解 Redis 的 ziplist 和 listpack：小白入门指南理解 Redis 的 ziplist 和 lis

理解 Redis 的 ziplist 和 listpack：小白入门指南

Redis 是一个超快的内存数据库，广泛用于缓存、实时分析等场景。它的高性能和高效内存使用离不开底层的数据结构，比如 ziplist 和 listpack。如果你对这些术语完全陌生，别担心！这篇博客将用通俗易懂的语言为你讲解这两种 Redis 底层数据结构，介绍它们的作用、区别以及演变过程。

ziplist 和 listpack 是什么？

简单来说，ziplist 和 listpack 是 Redis 用来紧凑存储小量数据的特殊数据结构。它们就像是高效的“压缩包”，让 Redis 在存储少量数据时既节省内存又保持快速访问。它们主要用于存储 Redis 的列表（List） 、哈希（Hash）和有序集合（Sorted Set） ，但仅限于数据量较小时。

ziplist：Redis 早期（7.0 版本之前）使用的一种数据结构，用于以内存高效的方式存储小型列表、哈希或有序集合。
listpack：Redis 5.0 引入并在 7.0 版本完全取代 ziplist 的改进版数据结构，解决了 ziplist 的一些问题。

你可以把 ziplist 和 listpack 想象成行李箱：它们都把数据紧紧地塞进一个连续的内存块来节省空间，但“打包方式”有所不同。

为什么 Redis 需要这些结构？

Redis 的核心优势是速度和内存效率。当你存储一个小型列表（比如只有几个元素）或小型哈希时，如果使用复杂的数据结构（比如链表或哈希表），会浪费很多内存。ziplist 和 listpack 的设计目标是：

节省内存：通过将数据紧凑存储在一个连续的内存块中，减少内存碎片和开销。
保持高效：尽管结构紧凑，Redis 仍然可以快速读取和修改数据。
支持多种数据类型：它们可以灵活存储列表、哈希和有序集合的元素。

简单来说，ziplist 和 listpack 是 Redis 在处理“小数据”时的秘密武器。

ziplist 的工作原理

ziplist 是一个序列化的、紧凑的内存结构，它将所有数据存储在一个连续的内存块中。它的结构可以分为以下部分：

头部（Header） ：存储元信息，比如 ziplist 的总字节数、尾部偏移量等。
条目（Entries） ：实际存储的数据，每个条目包含：
- 前一个条目长度：记录前一个条目占用的字节数，方便反向遍历。
- 编码信息：说明当前数据的类型（比如整数还是字符串）和长度。
- 实际数据：存储具体的值（比如一个数字或短字符串）。
尾部（End Marker） ：一个特殊的标志（通常是 0xFF），表示 ziplist 结束。

ziplist 的优点

内存高效：通过连续存储和紧凑编码，ziplist 尽量减少内存浪费。
简单操作：支持快速插入、删除和遍历（特别是正向遍历）。

ziplist 的缺点

连锁更新问题：如果插入或修改一个条目导致它的长度变化，可能会触发后续条目的“前一个条目长度”字段更新，形成连锁反应，影响性能。
复杂性：编码规则复杂，维护和扩展起来有一定难度。
遍历效率：反向遍历需要依赖“前一个条目长度”，效率不如正向遍历。

由于这些问题，Redis 团队开发了 listpack 作为替代品。

listpack 的工作原理

listpack 是 ziplist 的“升级版”，它保留了紧凑存储的核心思想，但改进了设计以解决 ziplist 的问题。listpack 的结构与 ziplist 类似，但有一些关键变化：

头部（Header） ：仍然存储元信息，但设计更简单。
条目（Entries） ：每个条目包含：
- 编码信息：说明数据类型和长度。
- 实际数据：存储具体的值。
- 条目长度：直接记录当前条目占用的字节数（而不是前一个条目长度）。
尾部（End Marker） ：与 ziplist 类似，表示结束。

listpack 的改进

消除了连锁更新：listpack 记录的是当前条目的长度，而不是前一个条目的长度。因此，修改一个条目不会影响其他条目，避免了连锁更新问题。
更简单的编码：listpack 的编码规则更统一，维护和扩展更方便。
更高的灵活性：listpack 支持更高效的插入和删除操作，尤其在小型数据场景下。

listpack 的优点

更高的内存效率：通过优化编码和结构，listpack 比 ziplist 更节省内存。
更好的性能：消除了连锁更新，插入和修改操作更稳定。
更易维护：代码更简洁，未来扩展更方便。

ziplist 和 listpack 在 Redis 中的应用

在 Redis 中，ziplist 和 listpack 主要用于以下场景：

小型列表（List） ：当列表元素数量少且每个元素较小时，Redis 使用 ziplist 或 listpack 来存储，而不是双向链表（quicklist）。
小型哈希（Hash） ：当哈希的键值对数量少且键值较短时，Redis 使用 ziplist 或 listpack，而不是哈希表。
小型有序集合（Sorted Set） ：当元素数量少时，Redis 使用 ziplist 或 listpack，而不是跳表（skiplist）。

什么时候不用 ziplist/listpack？

当数据量变大（比如列表元素超过一定数量，或哈希键值对过多），Redis 会自动将 ziplist 或 listpack 转换为更适合大数据的结构，比如：

列表：转换为 quicklist。
哈希：转换为哈希表。
有序集合：转换为跳表 + 哈希表。

这个转换的阈值由 Redis 的配置参数控制，比如：

list-max-ziplist-size（针对 ziplist 的列表）
hash-max-ziplist-entries（针对 ziplist 的哈希）
listpack-max-entries（针对 listpack，Redis 7.0 后）

ziplist 到 listpack 的演变

Redis 5.0：引入 listpack 作为实验性功能，主要用于 stream 数据结构。
Redis 7.0：listpack 完全取代 ziplist，成为小型列表、哈希和有序集合的默认底层数据结构。

为什么替换？因为 listpack 解决了 ziplist 的核心问题（连锁更新、复杂编码），同时在内存效率和性能上更胜一筹。Redis 7.0 的这一变化让系统更简洁、更高效。

小白总结：ziplist 和 listpack 有什么不同？

特性	ziplist	listpack
引入时间	Redis 早期	Redis 5.0（7.0 完全取代 ziplist）
内存效率	高	更高
连锁更新	存在，可能影响性能	不存在，性能更稳定
编码复杂性	较复杂	更简单，易维护
应用场景	小型列表、哈希、有序集合	同 ziplist，但在 Redis 7.0 后更广泛

举个生活化的例子

想象你有一个小笔记本，用来记录朋友的电话号码：

ziplist：你把所有号码写在一页上，每个号码前面写上“前一个号码的长度”。如果某个号码变长（比如加了区号），你得调整后面所有号码的“前一个长度”记录，费时费力。
listpack：你还是把号码写在一页上，但每个号码前面只写“自己的长度”。改一个号码时，只需更新自己的记录，不会影响其他号码，省事多了！

这就是 ziplist 和 listpack 的区别：listpack 更“聪明”，管理起来更轻松。

结语

ziplist 和 listpack 是 Redis 用来存储小型数据的“秘密武器”。它们通过紧凑的内存布局和高效的操作，让 Redis 在处理小规模列表、哈希和有序集合时既省内存又快速。ziplist 是 Redis 早期的选择，而 listpack 是更现代、更优化的升级版，在 Redis 7.0 后完全取代了 ziplist。

希望这篇博客让你对这两种数据结构有了初步了解！如果你想深入学习，可以查看 Redis 的源码（比如 ziplist.c 和 listpack.c），或者实验 Redis 的配置参数，看看它们如何影响性能。有什么疑问？欢迎留言讨论！