当前位置：首页 > news >正文

原理Redis-QuickList

news 2025/8/13 23:05:52

QuickList

**问题1：**ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？

为了缓解这个问题，我们必须限制ZipList的长度和entry大小。

**问题2：**但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？

我们可以创建多个ZipList来分片存储数据

**问题3：**数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？

Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

在这里插入图片描述

为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来限制

如果值为正，则代表ZipList的允许的entry个数的最大值
如果值为负，则代表ZipList的最大内存大小，分5种情况：
- -1：每个ZipList的内存占用不能超过4kb
- -2：每个ZipList的内存占用不能超过8kb
- -3：每个ZipList的内存占用不能超过16kb
- -4：每个ZipList的内存占用不能超过32kb
- -5：每个ZipList的内存占用不能超过64kb
其默认值为 -2：

在这里插入图片描述

除了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩。

通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数是控制首尾不压缩的节点个数:

0：特殊值，代表不压缩
1：标示QuickList的首尾各有1个节点不压缩，中间节点压缩
2：标示QuickList的首尾各有2个节点不压缩，中间节点压缩
以此类推

默认值: 0

在这里插入图片描述

以下是QuickList的和QuickListNode的结构源码：

typedef struct quicklist {// 头节点指针quicklistNode *head; // 尾节点指针quicklistNode *tail; // 所有ziplist的entry的数量unsigned long count;    // ziplists总数量unsigned long len;// ziplist的entry上限，默认值 -2 int fill : QL_FILL_BITS;// 首尾不压缩的节点数量unsigned int compress : QL_COMP_BITS;// 内存重分配时的书签数量及数组，一般用不到unsigned int bookmark_count: QL_BM_BITS;quicklistBookmark bookmarks[];
} quicklist;

typedef struct quicklistNode {// 前一个节点指针struct quicklistNode *prev;// 下一个节点指针struct quicklistNode *next;// 当前节点的ZipList指针unsigned char *zl;// 当前节点的ZipList的字节大小unsigned int sz;// 当前节点的ZipList的entry个数unsigned int count : 16;  // 编码方式：1，ZipList; 2，lzf压缩模式unsigned int encoding : 2;// 数据容器类型（预留）：1，其它；2，ZipListunsigned int container : 2;// 是否被解压缩。1：则说明被解压了，将来要重新压缩unsigned int recompress : 1;unsigned int attempted_compress : 1; //测试用unsigned int extra : 10; /*预留字段*/
} quicklistNode;