本文主要是介绍原理Redis-QuickList,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
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;
QuickList的特点:
- 是一个节点为ZipList的双端链表
- 节点采用ZipList,解决了传统链表的内存占用问题
- 控制了ZipList大小,解决连续内存空间申请效率问题
- 中间节点可以压缩,进一步节省了内存
这篇关于原理Redis-QuickList的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!