一、从一个「翻车」的设计说起
如果回顾Redis的早期版本，你会发现List类型的底层实现，确实是经典的双向链表（adlist）。这种结构逻辑清晰明了：每个节点独立分配内存，通过prev和next指针像珍珠项链一样串起来。
但是，这种优雅背后藏着一个“内存杀手”：极度的内存碎片化。你可以想象一下，存放一大堆小数据时，情况会变得多么尴尬。
双向链表的内存现实：
[节点A]──→[节点B]──→[节点C]──→[节点D]
↑ ↑ ↑ ↑
堆上某处 堆上某处 堆上某处 堆上某处
每个节点：prev指针(8B) + next指针(8B) + value指针(8B) + 实际数据
存1000个小字符串，光指针开销就是 1000 × 24 = 24000 字节
实际数据可能才几千字节，指针比数据还多
于是，为了解决指针开销过大的问题，ziplist被引入了。它的思路很直接：把所有元素都紧凑地塞进一块连续内存里，彻底告别指针。内存利用率是上去了，但新的麻烦随之而来：任何插入或删除操作，都可能引发整块内存的重新分配。更致命的是，还存在“连锁更新”的风险——一旦触发，性能就可能断崖式下跌。
你看，两种结构各有利弊，也各有“死xue”。不过，Redis的工程师们没有简单地二选一，而是走了第三条路：取长补短，把两者的优点结合起来，让缺点相互对冲。这个智慧的结晶，就是quicklist。
二、quicklist是什么？一句话说清楚
如果用最简洁的公式来概括，那就是：quicklist = 双向链表 × listpack。
怎么理解呢？它不再让链表的每个节点只存放单个元素，而是让每个节点承载一个小型的紧凑数组，也就是listpack。一个listpack里可以存放多个元素。
quicklist 整体结构：
head tail
↓ ↓
[node1] ←──→ [node2] ←──→ [node3] ←──→ [node4]
↓ ↓ ↓ ↓
[lp: e1,e2,e3] [lp: e4,e5] [lp: e6,e7,e8] [lp: e9,e10]
每个 node 内部是一个 listpack（连续内存块）
多个 node 通过双向链表串联
这种设计的精妙之处立刻显现出来：
- 得益于listpack内部的紧凑存储，指针开销被彻底消除，内存利用率大幅提升。
- 链表节点的总数显著减少，使得维持链表结构所需的prev/next指针开销被大幅稀释。
- 每个listpack的体量都受到控制，因此即便发生内存重分配，代价也有限，完全避免了全量数据迁移的风险。
可以说是一举三得。
三、还不够：quicklist再加一层压缩
然而，仅仅是“链表套listpack”的组合拳，Redis的工程师们觉得还不够极致。他们又在quicklist之上，加入了第三层设计：LZF压缩。
这个思路非常贴合实际场景：在一个很长的列表中，两端的元素（比如进行lpush、rpop操作时）访问频率最高，而中间一大段元素可能长时间处于“冷板凳”状态。既然这些中间节点不怎么被访问，何不把它们压缩起来，进一步节省内存呢？
compress depth = 2 时的内存状态：
[node1] [node2] | [node3] [node4] ... [nodeN-3] [nodeN-2] | [nodeN-1] [nodeN]
不压缩 不压缩 | 压缩 压缩 压缩 压缩 | 不压缩 不压缩
←── 热区 ──────→|←──────────── 冷区（LZF压缩） ──────────→|←─── 热区 ──────→
参数“compress depth”就决定了链表两端各有几个节点保持原样（不压缩），而中间的所有节点则用LZF算法压缩存储。当需要访问中间某个节点时，系统会实时解压，用完后可能再重新压缩回去。这种用“计算换空间”的策略，在内存敏感的场景下非常有效。
至此，quicklist的三层架构清晰地展现在我们面前：最外层是双向链表结构，中层是listpack提供的紧凑存储，内层则是LZF针对冷数据的动态压缩。每一层都精准地解决了上一层次留下的问题，环环相扣，堪称工程权衡的典范。
四、还有一个让人琢磨的细节：节点分裂
在研究quicklist源码时，有一个操作起初让我有些费解，那就是 _quicklistSplitNode——节点分裂。究竟在什么情况下需要分裂一个节点呢？
想象这样一个场景：你试图在一个listpack的中间位置插入一个新元素，但这个listpack已经“满员”了（达到了fill参数设定的容量上限）。此时，唯一的办法就是把这个已经满载的listpack节点“一分为二”。
分裂前：
[node]: [e1][e2][e3][e4][e5] ← listpack已满，要在e3后面插入新元素
分裂过程：
step1: 以 e3 为界，创建左节点 [e1][e2][e3]
step2: 创建右节点 [e4][e5]
step3: 原节点从链表中移除
step4: 左右节点插入链表
step5: 在左节点尾部 或 右节点头部 插入新元素
分裂后：
[node_left]: [e1][e2][e3][new] ←──→ [node_right]: [e4][e5]
然而，分裂操作会带来一个新的问题：链表中可能出现大量只包含寥寥数个元素的小节点，这显然不够经济。因此，Redis在分裂之后，通常还会紧接着尝试执行相邻小节点的合并操作（_quicklistMergeNodes）。分裂是为了给新元素腾出空间，合并则是为了整理内存、提高效率。这一分一合，共同构成了quicklist节点管理的完整逻辑。
五、listpack：被低估的主角
在讨论quicklist时，listpack常常被当作一个附属品被轻描淡写地略过。但这其实低估了它的价值。作为Redis 7.x中正式取代ziplist的新一代紧凑数据结构，listpack解决了一个长期存在的核心痛点——连锁更新问题。
listpack 内存布局：
total_bytes(4B) num_elements(2B) entry...entry end(1B=0xFF)
───────────────────────────────────────────────────────────────
│ 总字节数 │ 元素个数 │ 各元素编码 │ 结束标志 │
───────────────────────────────────────────────────────────────
每个 entry 的结构： encoding + data + backlen
其中 backlen 记录当前 entry 的总长度
→ 向前遍历时只需读 backlen，不依赖前驱节点长度
→ 彻底消灭了 ziplist 的连锁更新
listpack的关键创新在于，每个entry都在尾部自带一个记录自身长度的字段（backlen）。这意味着当需要向前遍历时，只需读取本entry的backlen就能定位到前一个entry的起始位置，完全不需要知道前一个entry的具体长度。正是这个看似微小的改变，从根本上斩断了连锁更新的传递链条。这不仅仅是一次优化，更是对一个经典工程缺陷的根本性修复。
