Redis 源码解析 - 压缩列表(ziplist)

Redis 中的压缩列表（ziplist）是一种为了节省内存而设计的高效紧凑型数据结构，尤其适用于存储小尺寸的整数值和短字符串。它能够有效地存储列表、集合和哈希类型的少量元素，也是有序集合（sorted set）中成员分数和成员值对的一种潜在实现方式。

结构概述

压缩列表不是通过传统的结构体数组来实现的，而是一个连续的字节数组，其内部结构包含了一系列编码后的元素。每个元素由长度（Lenght）字段、内容（Content）字段和可能存在的前置/后置长度（Pre-/Post-length）字段组成。在连续的内存区域内，各元素紧密排列在一起，形成了一个逻辑上的链表结构。

内部结构特点

1. Header: 压缩列表的开头通常包含两个字段，分别是记录整个压缩列表占用内存字节数的 zlbytes 和记录最后一个元素距离列表头部的偏移量的 zltail。

2. Entries: 每个元素由长度字段和内容字段组成，长度字段用于指示内容字段的长度。内容字段可以是一个整数或者是字节数组。对于整数，Redis 采用特殊的编码方式来减少存储空间；对于字符串，直接存储字节内容。

3. 编码方式：

   • 整数值根据大小有不同的编码格式，例如，小整数可以用单个字节表示，较大的整数则使用更复杂的编码格式。
   • 字符串也有类似优化，短字符串直接存储，较长的字符串则采用 LZF 压缩算法进行压缩存储。

4. 连锁更新：
   当某个元素发生变化时，可能导致其后的元素位置发生改变，此时 Redis 采取了“连锁更新”策略来最小化因元素移动引发的内存重分配。

5. Tail: 压缩列表的末尾有一个特殊的结尾标记，标志着列表的结束。

源码解析要点

• 在 Redis 源码中，ziplist.c 文件包含了与压缩列表相关的几乎所有操作函数，如创建、插入、删除、查找、遍历、更新等。
• 创建压缩列表通常调用 ziplistNew 函数，初始化时并不预先分配具体大小的内存，而是随着元素的增加动态扩展。
• 插入元素时，首先计算新元素所需的字节数，然后根据现有空间决定是否需要进行内存扩展和元素的物理移动。
• 删除元素时，同样要考虑连锁更新的情况，清理掉已删除元素的内存空间，并更新受影响的长度和偏移量字段。
• 查找操作通过遍历压缩列表，并解码每个元素的内容来完成。

通过这种紧凑的存储形式，压缩列表能够在保持数据完整性的前提下大大降低内存占用，特别是对于大量小规模数据的存储尤为有效。然而，当元素数量过多或元素尺寸增大到一定程度时，Redis 会自动转换为更通用但内存消耗更大的数据结构，如双端链表或哈希表。