zipList quickList

HBryce24

于 2025-03-12 21:58:00 发布

阅读量609

点赞数 7

分类专栏： Redis 文章标签： redis

本文链接：https://blog.youkuaiyun.com/HBryce24/article/details/146209965

版权

Redis 专栏收录该内容

3 篇文章

订阅专栏

以下是通过文字描述结合图示解释 ZipList（压缩列表） 和 QuickList（快速列表） 的结构和设计原理。

1. ZipList（压缩列表）

设计目标

内存紧凑：通过连续内存布局减少指针开销，适合存储小规模数据。
减少碎片：所有数据项紧密排列，无额外指针。

结构示意图

┌───────────┬─────────┬─────────┬───┬─────────┬──────────┐
│ zlbytes   │ zltail  │ zllen   │...│ entry1  │  zlend   │
│ (4 bytes) │ (4)     │ (2)     │   │         │ (1 byte) │
└───────────┴─────────┴─────────┴───┴─────────┴──────────┘
                ▲
                │
         指向最后一个 entry 的偏移量

zlbytes：整个 ziplist 占用的内存字节数（含头部）。
zltail：最后一个 entry 的起始位置偏移量（用于快速定位尾部）。
zllen：entry 的数量（若超过 65535，则需遍历计算实际数量）。

entry：实际存储的数据项，结构如下：

┌──────────────┬──────────────┬──────────────┐
│ prevlen      │ encoding     │ content      │
│ (1/5 bytes)  │ (1/2/5 bytes)│ (变长)       │
└──────────────┴──────────────┴──────────────┘

prevlen：前一个 entry 的长度（支持向前遍历）。
- 若前一个 entry 长度 < 254 字节，prevlen 占 1 字节。
- 否则，prevlen 占 5 字节（首字节固定为 0xFE，后 4 字节为实际长度）。
encoding：当前 entry 的数据类型和长度编码。
content：实际存储的数据（整数或字节数组）。

zlend：固定值 0xFF，标记 ziplist 的结束。

优点

内存利用率高，无指针开销。
适合存储少量小数据（如哈希表的字段、列表的短元素）。

缺点

插入/删除性能低：需移动后续数据，最坏时间复杂度 O(N)。
连锁更新风险：若某个 entry 的 prevlen 长度变化（如从 1 字节扩展为 5 字节），可能导致后续所有 entry 的 prevlen 连锁更新。

2. QuickList（快速列表）

设计目标

平衡内存与性能：将多个 ziplist 节点通过双向链表连接，避免单一 ziplist 的扩展性问题。
支持压缩：允许对中间节点进行 LZF 压缩，进一步节省内存。

结构示意图

           QuickList 结构
┌───────────┐    ┌───────────┐    ┌───────────┐
│ QuickNode │◄──►│ QuickNode │◄──►│ QuickNode │
└─────┬─────┘    └─────┬─────┘    └─────┬─────┘
      │                │                │
      ▼                ▼                ▼
   ┌───────┐        ┌───────┐        ┌───────┐
   │ZipList│        │ZipList│        │ZipList│
   │ (Entry│        │ (Entry│        │ (Entry│
   │  ...) │        │  ...) │        │  ...) │
   └───────┘        └───────┘        └───────┘

QuickNode：双向链表节点，包含：
- 指向前后节点的指针（prev 和 next）。
- 指向一个 ziplist 的指针。
- ziplist 的字节大小、元素数量、压缩标记等元数据。
ZipList：每个 QuickNode 指向一个独立的 ziplist。

关键优化

分块存储：
- 每个 ziplist 的大小可配置（默认 8KB），避免单个 ziplist 过大导致的性能问题。
- 插入/删除操作仅影响局部 ziplist，无需移动全局数据。
压缩深度：
- 通过 list-compress-depth 参数控制压缩策略：
  - 0：不压缩（默认）。
  - 1：首尾节点不压缩（保证头尾操作性能），中间节点压缩。
  - N：首尾各 N 个节点不压缩，其余压缩。
遍历优化：
- 支持正向和反向遍历（双向链表特性）。

优点

内存利用率接近 ziplist，但插入/删除性能更优。
支持压缩，进一步节省内存。
避免单一 ziplist 的连锁更新问题。

缺点

少量额外指针开销（双向链表节点信息）。
需要合理配置 ziplist 大小和压缩深度。

总结对比

特性	ZipList	QuickList
内存效率	极高（无指针开销）	高（分块 ziplist + 少量指针）
插入/删除性能	低（需移动数据，可能连锁更新）	高（局部操作，无连锁更新）
适用场景	小规模数据（如哈希表字段、短列表元素）	中大规模列表（如消息队列、长列表存储）
压缩支持	不支持	支持（LZF 压缩中间节点）
实现复杂度	简单	中等（需管理链表和 ziplist 的协同）