Redis 列表（List）的压缩列表（`ziplist`）与双向链表（`linkedlist`）编码转换条件

好的，各位看官，欢迎来到“Redis 列表编码变形记”特别节目！我是你们的老朋友，代码界的段子手，bug 界的终结者。今天，咱们就来聊聊 Redis 列表（List）这个小东西，它那灵活多变的编码方式，以及它在压缩列表（ziplist）和双向链表（linkedlist）之间“华丽转身”的故事。

开场白：Redis 列表，远不止你看到的那么简单！

说起 Redis 列表，大家可能会觉得：不就是个能存一堆字符串的玩意儿嘛，有什么好讲的？ 咳咳，少年，你还是太年轻了！Redis 列表的背后，藏着一颗追求极致性能的心。为了在不同的场景下发挥最佳效能，它可是准备了两套“战袍”：

• 压缩列表（ziplist）： 一身紧身衣，轻巧灵活，适合身材娇小（元素少且小）的时候。
• 双向链表（linkedlist）： 一身宽松的汉服，雍容华贵，适合身材丰满（元素多且大）的时候。

那么问题来了，Redis 列表是如何判断自己该穿哪套衣服的呢？ 这就是我们今天要深入探讨的编码转换条件！

第一幕：压缩列表（ziplist）——小而美的典范

想象一下，你是一个生活在寸土寸金的大都市里的打工人，房间不大，但你却想尽可能地塞下更多的东西。怎么办？压缩！把一切都压缩到极致！

压缩列表（ziplist）就是 Redis 为了节省内存而设计的一种特殊编码方式。它并不是真正的列表，而是一块连续的内存空间，通过一系列特殊的编码方式，将列表中的元素紧凑地排列在一起。

压缩列表的优点：

• 节省内存： 这是它最大的优点，也是它存在的意义。通过紧凑的存储方式，可以有效地减少内存占用。
• 读取速度快： 由于元素在内存中是连续存储的，所以读取速度相对较快。

压缩列表的缺点：

• 修改效率低： 如果在压缩列表的中间插入或删除元素，需要移动大量的内存数据，效率较低。
• 容易引发连锁更新： 压缩列表的每个节点都保存了前一个节点的长度信息。如果前一个节点的长度发生了变化，可能会导致后续节点的长度信息也需要更新，从而引发连锁更新，降低性能。

压缩列表的内部结构：

为了更好地理解压缩列表的编码转换，我们先来简单了解一下它的内部结构。

| 字段 | 描述 4. len： 记录压缩列表包含的节点数量。 占用4个字节。

5. entryX： 压缩列表包含的每个节点。节点的长度取决于节点保存的内容。

第二幕：双向链表（linkedlist）——雍容华贵的大佬

如果说压缩列表是小户型公寓，那么双向链表（linkedlist）就是豪华别墅。它不追求极致的紧凑，而是更注重灵活性和可扩展性。

双向链表的优点：

• 插入和删除效率高： 在链表的任何位置插入或删除元素，只需要修改指针即可，效率很高。
• 可扩展性强： 链表可以动态地扩展，不需要预先分配固定大小的内存空间。

双向链表的缺点：

• 内存占用高： 每个节点都需要额外的指针来指向前一个节点和后一个节点，因此内存占用相对较高。
• 读取速度慢： 由于元素在内存中不是连续存储的，所以读取速度相对较慢。

双向链表的内部结构：

双向链表由多个节点组成，每个节点包含以下信息：

• prev： 指向前一个节点的指针。
• next： 指向后一个节点的指针。
• value： 节点保存的数据。

第三幕：编码转换的触发条件——从“紧身衣”到“汉服”的华丽变身

好了，铺垫了这么多，终于到了我们今天的重头戏：Redis 列表的编码转换条件！ 简单来说，当 Redis 列表满足以下任一条件时，就会从压缩列表（ziplist）编码转换为双向链表（linkedlist）编码：

1. 列表元素数量超过 list-max-ziplist-entries 配置： 这个配置项定义了压缩列表可以容纳的最大元素数量。 默认值为512. 也就是说，当列表中的元素数量超过512个时，Redis 就会觉得“这身紧身衣太小了，穿不下了！”，然后果断换上宽松舒适的“汉服”。
2. 列表中任一元素的长度超过 list-max-ziplist-value 配置： 这个配置项定义了压缩列表中元素的最大长度（以字节为单位）。 默认值为64. 如果列表中出现了“巨无霸”级别的元素，Redis 就会觉得“这身紧身衣太紧了，勒得慌！”，然后毫不犹豫地换上雍容华贵的“汉服”。

用表格总结一下：

| 转换条件 | 默认值 | 说明

举例说明：

假设我们有以下配置：

• list-max-ziplist-entries = 5
• list-max-ziplist-value = 64

现在，我们向一个空的 Redis 列表（编码为 ziplist）中添加元素：

1. 添加 "hello"：列表元素数量为 1，元素长度为 5，均未超过配置，列表仍然是 ziplist 编码。
2. 添加 "world"：列表元素数量为 2，元素长度为 5，均未超过配置，列表仍然是 ziplist 编码。
3. 添加 "redis"：列表元素数量为 3，元素长度为 5，均未超过配置，列表仍然是 ziplist 编码。
4. 添加 "cluster"：列表元素数量为 4，元素长度为 7，超过了 list-max-ziplist-value，列表会转换为 linkedlist 编码。 ?

或者：

1. 添加 "a"
2. 添加 "b"
3. 添加 "c"
4. 添加 "d"
5. 添加 "e" : 列表元素数量为5，符合list-max-ziplist-entries配置，列表仍然是ziplist编码
6. 添加 "f"：列表元素数量为 6，超过了 list-max-ziplist-entries，列表会转换为 linkedlist 编码。 ?

划重点：

• 编码转换是不可逆的！一旦列表转换为 linkedlist 编码，就无法再转换回 ziplist 编码了。就像破镜难重圆，回不去了！
• list-max-ziplist-entries 和 list-max-ziplist-value 的值越小，列表越容易转换为 linkedlist 编码。
• 合理配置这两个参数，可以根据实际应用场景来平衡内存占用和性能。

第四幕：源码分析（硬核警告！）

如果你想更深入地了解编码转换的实现细节，可以去看看 Redis 的源码。相关代码主要在 t_list.c 文件中。

简单来说，当 Redis 执行 lpush、rpush 等命令向列表中添加元素时，会检查列表的编码方式，如果当前是 ziplist 编码，并且添加元素后满足了转换条件，就会调用相应的函数将列表转换为 linkedlist 编码。

（此处省略一万字源码分析，因为直接贴代码太枯燥了，而且没有注释的话，估计大家也看不懂。如果你真的感兴趣，可以自己去研究一下。）

第五幕：实战演练——用代码验证真理

光说不练假把式，咱们来做个实验，验证一下上面的理论。

import redis

# 连接 Redis
r = redis.Redis(host='localhost', port=6379, db=0)

# 清空列表
r.delete('mylist')

# 添加元素，观察编码方式的变化
for i in range(6):
    r.rpush('mylist', str(i))
    print(f"添加元素 {i} 后，列表编码方式为：{r.type('mylist')}")

# 添加一个超长元素，观察编码方式的变化
r.rpush('mylist', 'a' * 100)
print(f"添加超长元素后，列表编码方式为：{r.type('mylist')}")

运行这段代码，你会发现：

• 在添加前 5 个元素时，列表的编码方式为 list（实际上底层是 ziplist）。
• 当添加第 6 个元素时，列表的编码方式变为 list（实际上底层是 linkedlist）。
• 添加超长元素后，列表的编码方式仍然是 list（底层仍然是 linkedlist）。

这个实验证明了我们的理论是正确的！

第六幕：最佳实践——如何合理选择编码方式？

在实际应用中，我们应该如何根据实际情况来选择合适的编码方式呢？

• 小数据量、高读取频率的场景： 优先选择 ziplist 编码，可以有效地节省内存，提高读取速度。
• 大数据量、高写入频率的场景： 优先选择 linkedlist 编码，可以提高插入和删除的效率。
• 不确定场景： 可以使用 Redis 的默认配置，让 Redis 自动选择合适的编码方式。

当然，最好的方式是根据实际的压测结果来调整 list-max-ziplist-entries 和 list-max-ziplist-value 的值，以达到最佳的性能。

总结：编码转换，Redis 列表的生存之道！

好了，各位观众，今天的“Redis 列表编码变形记”就到这里了。希望通过今天的讲解，大家能够对 Redis 列表的编码转换有更深入的了解。

记住，Redis 列表之所以如此强大，不仅仅是因为它能存储字符串，更重要的是它那灵活多变的编码方式，以及它在不同的场景下都能发挥最佳效能的智慧。

就像人生一样，要学会适应不同的环境，选择最适合自己的方式，才能活出精彩！

最后，祝大家编码愉快，bug 永不相见！ ?