Redis底层数据结构之quicklist

redis底层数据结构已完结👏👏👏：

• ☑️redis底层数据结构之SDS
• ☑️redis底层数据结构之ziplist
• ☑️redis底层数据结构之quicklist
• ☑️redis底层数据结构之Dict
• ☑️redis底层数据结构之IntSet
• ☑️redis底层数据结构之ZSkipList

一、概述

QuickList是由多个 ziplist 组成的双向链表，每个 ziplist 存储一定数量的元素。优点:结合了 ziplist 和双向链表的优点，既节省空间，又提升了修改操作的性能。使用场景: 在列表键元素较多或包含较大元素时使用。

ziplist补充(ziplist缺点-链式扩容&级联更新)
当一个entry被插入的时候，我们需要设置下一个entry中的prevlen字段为新插入entry的长度。会发生如下的情况：新插入entry的长度超过了254[>=254]，那么下一个entry的prelen需要5个字节记录该长度，但是呢，此时下一个entry的prevlen字段此时只有一个字节，所以需要对下一个entry进行grown[扩容]，更糟糕的是，下个entry因为扩容导致长度超过254，还会引起下下个entry的扩容…，这种现象呢就是级联更新，简单点来说就是，因为一个entry的插入导致之后的entry都需要重新扩容和记录前一个entry的prevlen现象称之为“级联更新”。

从 Redis 6.2 版本开始，quicklist 的底层实现由原来的 ziplist 改为了 listpack。Listpack 是 ziplist 的升级版本，主要是为了解决ziplist中存在的一些问题，比如，ziplist中扩展元素长度时可能需要进行昂贵的重新分配操作。listpack 提供了更好的性能和内存使用效率，在保持与 ziplist 类似的密集存储方式的同时，允许更大的单个元素大小，并且有更强的扩展性。listpack和ziplist对象结构的不同是，listpack将prevlen替换为了curlen，从而有效避免级联更新。并将且将culen字段放在entry结构的最后面。这样做是为了，能够通过total-bytes定位到最后一个element的末尾位置然后获取到curlen从而找到前一个element的位置，从而实现从后往前遍历。

补充说明listpack和ziplist
参考博客 ziplist和listpack

• ziplist包括三大部分，<头部，entry，尾部>。头部包含"zlbytes,zltail,zllen"；尾部包含"zlend标记ziplist的结尾"；entry包括"prevlen,encoding,entry_data"。由于prevlen记录方式存在级联更新的问题，小于254字节需要1字节内存，大于等于254字节需要5字节内存。
• listpack包括三大部分，<头部，entry，尾部>。头部包含"zlbytes,zllen"相比与ziplist少了zltail；entry包括"encoding,entry_data,curlen"；尾部包含"zlend标记listpack的结尾"。由于entry中的prevlen由curlen取代，所以不再有级联更新的问题。
• 不论是"ziplist"还是"listpack"获取len的方式都是一样的：
  先判断头部中zllen字段存储的数值与UNIT16_MAX的关系
  小于UNIT16_MAX，直接返回zllen
  大于等于UNIT16_MAX需要从头到尾遍历获取元素总数
  如果新得到的元素总数小于UINT16_MAX，重新设置zllen的数值

二、quicklist结构

(直达源码–>src/quicklist.h)

基于listpack(V6.2)

/* quicklist is a 40 byte struct (on 64-bit systems) describing a quicklist.
* 'count' is the number of total entries.
* 'len' is the number of quicklist nodes.
* 'compress' is: 0 if compression disabled, otherwise it's the number
*                of quicklistNodes to leave uncompressed at ends of quicklist.
* 'fill' is the user-requested (or default) fill factor.
* 'bookmarks are an optional feature that is used by realloc this struct,
*      so that they don't consume memory when not used. */
typedef struct quicklist {
   quicklistNode *head;
   quicklistNode *tail;
   unsigned long count;        /* total count of all entries in all listpacks */
   unsigned long len;          /* number of quicklistNodes */
   signed int fill : QL_FILL_BITS;       /* fill factor for individual nodes */
   unsigned int compress : QL_COMP_BITS; /* depth of end nodes not to compress;0=off */
   unsigned int bookmark_count: QL_BM_BITS;
   quicklistBookmark bookmarks[];
} quicklist;

基于ziplist

typedef struct quicklist {
   // quicklist头结点
   quicklistNode *head;
   // quicklist 尾节点
   quicklistNode *tail;
   // 所有的ziplist中的entry总数量
   unsigned long count; /* total count of all entries in all ziplists */
   // ziplist节点数量
   unsigned long len;   /* number of quicklistNodes */
   // ziplist中entry的上限，默认为-2，和redis中配置的 list-max-ziplist-size 一致
   int fill : QL_FILL_BITS;  /* fill factor for individual nodes */
   // 首尾节点不压缩的个数，若设置为1，则首尾节点各有一节点不压缩；设置为0，则代表所有节点不压缩
   unsigned int compress : QL_COMP_BITS; /* depth of end nodes not to compress;0=off */
   // 内存重分配时的书签数量及数组，一般用不到
   unsigned int bookmark_count: QL_BM_BITS;
   quicklistBookmark bookmarks[];
} quicklist;

三、quicklistNode结构

基于listpack(V6.2)

/* quicklistNode is a 32 byte struct describing a listpack for a quicklist.
* We use bit fields keep the quicklistNode at 32 bytes.
* count: 16 bits, max 65536 (max lp bytes is 65k, so max count actually < 32k).
* encoding: 2 bits, RAW=1, LZF=2.
* container: 2 bits, PLAIN=1 (a single item as char array), PACKED=2 (listpack with multiple items).
* recompress: 1 bit, bool, true if node is temporary decompressed for usage.
* attempted_compress: 1 bit, boolean, used for verifying during testing.
* dont_compress: 1 bit, boolean, used for preventing compression of entry.
* extra: 9 bits, free for future use; pads out the remainder of 32 bits */
typedef struct quicklistNode {
   struct quicklistNode *prev;
   struct quicklistNode *next;
   unsigned char *entry;
   size_t sz;             /* entry size in bytes */
   unsigned int count : 16;     /* count of items in listpack */
   unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
   unsigned int container : 2;  /* PLAIN==1 or PACKED==2 */
   unsigned int recompress : 1; /* was this node previous compressed? */
   unsigned int attempted_compress : 1; /* node can't compress; too small */
   unsigned int dont_compress : 1; /* prevent compression of entry that will be used later */
   unsigned int extra : 9; /* more bits to steal for future usage */
} quicklistNode;

基于ziplist

typedef struct quicklistNode {
   // 前一个节点（ziplist）指针
   struct quicklistNode *prev;
   // 后一个节点（ziplist）指针
   struct quicklistNode *next;
   // 当前节点ziplist指针
   unsigned char *zl;
   // 当前节点ziplist的字节大小，即zlbytes
   unsigned int sz;             /* ziplist size in bytes */
   // 当前节点ziplist中entry的数量
   unsigned int count : 16;     /* count of items in ziplist */
   // 编码方式:1-ziplist; 2-lzf压缩模式
   unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
   // 数据容器类型：1-其他（预留扩展类型）；2-ziplist
   unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
   // 是否被压缩：1-说明被解压，将来要重新压缩。
   unsigned int recompress : 1; /* was this node previous compressed? */
   // 测试字段
   unsigned int attempted_compress : 1; /* node can't compress; too small */
   // 预留字段
   unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

四、优缺点

优点：

• 快表的节点大小固定，可以有效地避免内存碎片的发生。
• 快表支持动态增加和删除节点，可以随着数据的增长而自动扩容或缩容，不需要预先分配空间。
• 快表的节点采用ziplist的紧凑存储方式，使得节点访问和遍历的效率较高。同时，快表支持从头和尾部两个方向同时遍历节点。

缺点：

• 快表的节点大小固定，如果节点中的元素数量较少，会造成一定的空间浪费。
• 快表中的元素只能是整数或字节数组，不支持其他数据类型的存储。
• 快表的插入和删除操作的效率较低，因为在插入或删除元素时，需要移动后面的元素，可能会导致大量的内存复制操作。如果需要频繁进行插入和删除操作，建议使用其他数据结构，例如链表。
• 当快表中的元素数量较大时，遍历整个快表的效率也可能较低，因为快表是由多个节点组成的链表，需要依次遍历每个节点才能访问所有元素。