Redis为不同大小的集合数据设计了多种内部编码，小规模数据使用紧凑连续内存结构，以减少内存碎片和指针开销。ziplist和listpack都属于这类紧凑编码，但listpack是为了解决ziplist的固有缺陷而引入的替代方案。理解它们的演进过程，有助于在调优Redis内存和性能时做出更合理的选择。
ziplist的内存布局与设计思路
ziplist是一种特殊的双向链表，但它不使用指针连接，而是将所有数据存储在连续内存块中。该内存块的起始部分记录了整体元数据，包括zlbytes（整个ziplist占用的字节数）、zltail（尾节点相对起始地址的偏移量）和zllen（节点数量）。后面紧跟着各个节点entry，每个entry由三部分组成：prevlen、encoding和实际数据data。prevlen记录前一个节点的长度，这样可以从后向前遍历；encoding标记当前节点data的类型和长度，对于小整数和短字符串使用不同长度的编码，最大程度节省空间。最后以固定字节0xFF作为结束标记。
这种设计的目标非常明确：对于元素数量不多且每个元素较小的集合，如果使用普通的链表，每个节点需要额外存储指针，内存开销大而且不连续导致缓存不友好。ziplist通过连续分配和紧凑编码，显著降低了内存占用。但是，正因为它依赖prevlen字段来支持反向遍历，也埋下了连锁更新的隐患。
在实际使用中，ziplist适用于元素数量较少、单元素长度较短的数据结构。例如早期的Redis list、hash和zset在满足一定条件时都会选择ziplist作为内部编码。Redis通过配置项如list-max-ziplist-entries和list-max-ziplist-value来控制这些结构何时使用ziplist。不过，这种配置方式在后续版本中也随着ziplist被listpack取代而发生了变化。
ziplist的连锁更新问题分析
连锁更新是ziplist最著名的缺陷。问题根源在于entry中的prevlen字段大小可变：如果前一个节点的长度小于254字节，prevlen可以用1个字节表示；如果大于等于254字节，则prevlen需要扩展为5个字节（第1个字节为0xFE标记，后4个字节存储实际长度）。当插入或删除一个节点导致某个节点的长度跨越254这个临界值时，紧跟其后的节点的prevlen字段就必须从1字节变为5字节，或者相反。这样一来，后续节点的总长度也会改变，如果这个长度变化又跨过了254，就会继续影响下一个节点，形成连锁反应。
举一个具体例子：假设一个ziplist中有多个连续的节点，每个节点长度都在250到253字节之间，那么每个节点的prevlen字段都只用1字节。此时在它们前面插入一个长度为254字节的新节点，那么第一个被插入位置后面的节点的prevlen必须扩展成5字节，导致该节点总长度增加4字节，可能超过254，于是下一个节点的prevlen也需要扩展，以此类推。最坏情况下，所有后续节点都会被修改，插入操作的时间复杂度会退化为O(N^2)。即使实际触发条件比较苛刻，这种极端情况仍然可能造成明显的延迟抖动。
Redis的quicklist结构通过将ziplist作为链表节点来限制单次操作影响范围，降低了连锁更新的发生概率，但并没有从本质上消除问题。此外，ziplist还有其他一些限制，比如查找元素需要顺序扫描，不能像skiplist那样支持高效的范围查询等，但连锁更新是推动Redis引入listpack的关键原因。
listpack的编码设计与改进
listpack在Redis 5.0中被引入，最初用于Stream的消费组等场景，后来逐渐推广到hash、zset等结构。listpack同样使用连续内存，但每个元素的编码方式与ziplist完全不同。一个listpack由头部、多个元素和尾部标记组成。头部记录了总字节数和元素数量，尾部以一个固定字节0xFF结束。每个元素没有prevlen字段，而是由两部分核心组成：encoding和data，最后还有一个backlen字段。backlen记录当前元素的实际长度（包括encoding和data的总长度），并且backlen本身采用反向编码，从后往前读取时能够确定backlen占用的字节数。
这种设计的关键在于：元素之间不再相互依赖前一个节点的长度，因此插入或删除某个元素时，只需要修改相邻元素的backlen（如果长度跨越编码边界）以及头部记录，但不会引发级联修改。backlen位于元素末尾，遍历时如果需要反向移动，可以先读取backlen得到整个元素长度，再向前跳转。由于backlen长度只取决于当前元素本身，不会因为前一个元素变化而被迫改变编码宽度，连锁更新问题被彻底消除。
listpack的encoding设计也做了优化，支持更多整数类型和短字符串的高效表示。例如，对于0到127之间的非负整数，直接以一个字节存储；对于更大的整数则使用变长编码；对于字符串，根据长度使用不同的前缀。虽然编码复杂度比ziplist略高，但换来的是稳定性。在内存占用方面，listpack与ziplist基本相当，某些场景下甚至更优。
Redis中ziplist到listpack的迁移过程
随着listpack的成熟，Redis在新版本中逐步将其作为小集合的默认紧凑编码。以hash类型为例，旧版本使用ziplist编码，配置项hash-max-ziplist-entries和hash-max-ziplist-value控制转换阈值；新版本中这些配置项被替换为hash-max-listpack-entries和hash-max-listpack-value。类似地，zset的配置也从zset-max-ziplist-entries变为zset-max-listpack-entries。Redis 7.0开始，listpack已经全面取代ziplist用于这些数据结构的默认紧凑编码，而ziplist虽然仍被保留用于兼容旧数据，但新写入的小集合不再使用ziplist。
开发者可以通过OBJECT ENCODING命令查看一个key的实际内部编码。例如，当hash键只包含少量小字段时，返回的编码可能是listpack而不是hashtable。如果从旧版本升级，已经存在的ziplist编码数据不会自动转换，只有在发生写操作导致编码切换时才会迁移到新的默认编码。也可以使用DEBUG HTSTATS等命令观察编码分布，但更直接的方式是OBJECT ENCODING。
以下是一个使用Redis命令查看编码并调整listpack阈值的示例：
CONFIG SET hash-max-listpack-entries 512 CONFIG SET hash-max-listpack-value 64 HSET user:1001 name "Alice" age 30 city "Beijing" OBJECT ENCODING user:1001
上述示例中，先调整hash的listpack参数，然后写入少量字段，再通过OBJECT ENCODING检查结果，通常会显示listpack。如果字段数量或值大小超过阈值，编码会自动升级为hashtable。
总的来说，从ziplist到listpack的演进是Redis在内存效率与操作稳定性之间的一次重要权衡。listpack保留了紧凑内存布局的优势，同时消除了级联更新带来的性能风险，让Redis在处理小集合时更加可靠。理解这一演进过程，有助于在实际运维中合理设置阈值，并在升级版本时评估编码变化带来的影响。