基本概述

ZipList虽节省内存但是申请内存必须是连续的，如果内存占用很大，申请内存效率就会很低，可以限制ZipList长度和entry大小；

实在要存储大量数据，超出ZipList最佳上限了，此时可以创建多个ZipList来分片存储数据；

数据拆分后比较分散，不方便管理和查找，多个ZipList需要建立联系，

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

配置

限制每个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做压缩：

除了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩。通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数是控制首尾不压缩的节点个数：

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

默认值为 0：

源码

QuickList的和QuickListNode的结构源码：

完整结构：

特点

• 是一个节点为ZipList的双端链表
• 节点采用ZipList，解决了传统链表的内存占用问题
• 控制了ZipList大小，解决连续内存空间申请效率问题
• 中间节点可以压缩，进一步节省了内存