Redis 中的 Ziplist 和 Quicklist 数据结构的特点是什么？

回答重点

Ziplist：

• 简单、紧凑、连续存储，适用于小数据量场景，但对大量数据或频繁的修改操作不太友好。
• 适合小数据量场景，例如短列表、小哈希表等，因为它的内存紧凑，可以大幅减少内存使用

Quicklist：

• 通过将链表和 Ziplist 结合，既实现了链表的灵活操作，又能节省内存，在 Redis 3.2 之后成为 List 的默认实现。
• Quicklist 是为了替代纯链表而设计的，适用于需要频繁对列表进行插入、删除、查找等操作的场景，并且数据量可能较大。它在存储多个元素时，既保留了链表的灵活性，又具备压缩列表的内存优势。

扩展知识

Ziplist

Ziplist（压缩列表）是一种紧凑的数据结构，它将所有元素紧密排列存储在单个连续内存块中，十分节省空间。

这些元素可以是字符串或整数，且每个元素的存储都紧凑地排列在一起。

以下是 ziplist 的具体结构：

• zlbytes：记录整个 ziplist 所占用的字节数。
• zltail：记录 ziplist 中最后一个节点距离 ziplist 起始地址的偏移量。
• zllen：记录 ziplist 中节点的个数。
• entry：各个节点的数据。
• zlend：特殊值 0xFF，用于标记 ziplist 的结束。

entry 更详细的结构如下，会记录前一个节点的长度和编码：

也因为 entry 需要记录前一个元素的大小，如果前面插入的元素很大，则已经存在的 entry 的 pre_entry_length 字段需要变大，它又变大后续的节点也需要变，所以可能导致连锁更新的情况，影响性能。

查询需按顺序遍历所有元素，逐个检查是否匹配查询条件。

特点：

• 紧凑性：所有元素紧密排列在一起，没有额外的内存开销，适合存储少量数据。
• 顺序访问：由于元素是按顺序存储的，顺序访问性能较好，但随机访问性能较差。

在 Redis 中的应用：

• 列表（List）：当列表长度小于一定阈值（默认 512 个元素）且每个元素的长度小于 64 字节时，Redis 会使用 Ziplist 存储列表。
• 哈希表（Hash）：当哈希表中键值对的数量少于一定阈值（默认 512 对）且每个键和值的长度都小于 64 字节时，Redis 会使用 Ziplist 存储哈希表。

Quicklist

Quicklist 结合了 Ziplist 和双端链表的优点，每个 Quicklist 节点都是一个 Ziplist，它限制了单个 Ziplist 的大小，降低级联更新产生的影响。

特点：

• 高效内存利用：结合了 Ziplist 的内存紧凑性和双端链表的快速插入、删除操作。
• 降低级联更新产生的影响。

在 Redis 中的应用：

• 列表（List）：当列表长度超过 Ziplist 的阈值时，Redis 会使用 Quicklist 存储列表。