为什么需要quicklist 假设你已经知道了ziplist的缺陷： 虽然节省空间，但是申请内存必须是连续的，如果内存占用比较多，申请效率低要存储大量数据，超过了ziplist的最佳上限后，性能有影响 借鉴分片思想，可以把大量的数据分片存储到多个ziplist中，每个ziplist的长度和大小都在最佳上限之下，这样虽然解决了单个ziplist空间申请和数据存储的问题，但是又有了新的挑战：数据

列表 文章目录 列表压缩列表-ziplistziplist 定义级联更新 快速列表-quicklistquicklistNode 定义quicklist 定义quicklist常用操作其他操作quicklist 相对于普通链表优点quick应用场景在redis 中使用quicklist 列表数据类型可以存储一组按插入顺序排序的字符串，他很灵活，支持两端插入、弹出数据可以充当栈和

目录 一、概述二、quicklist结构三、quicklistNode结构四、优缺点 上一篇 redis底层数据结构之ziplist 一、概述 QuickList是由多个 ziplist 组成的双向链表，每个 ziplist 存储一定数量的元素。优点:结合了 ziplist 和双向链表的优点，既节省空间，又提升了修改操作的性能。使用场景: 在列表键元素较多或包含较大元素

目录 为什么使用快速列表quicklist 对比双向链表 对比压缩列表ziplist quicklist结构 节点结构quicklistNode quicklist  管理ziplist信息的结构quicklistEntry  迭代器结构quicklistIter  quicklist的API 1.创建快速列表 2.创建快速列表节点 3.头插quicklistPushHea

ziplist设计上的问题，每一次增删改都需要计算前面元素的空间和长度（prevlen），这种设计缺陷非常明显，因此引入了quicklist的设计。 quicklist quicklist实际就是双端链表，链表里的每一个节点都是ziplist，这样就可以避免减少了数据插入时内存空间的重新分配，以及内存数据的拷贝。同时每一个节点都会限制ziplist的大小，如果ziplist里面插入的entry

QuickList **问题1：**ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？ 为了缓解这个问题，我们必须限制ZipList的长度和entry大小。 **问题2：**但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？ 我们可以创建多个ZipList来分片存储数据 **问题3：**数据拆分后比较分散，不方便

QuickList **问题1：**ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？ 为了缓解这个问题，我们必须限制ZipList的长度和entry大小。 **问题2：**但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？ 我们可以创建多个ZipList来分片存储数据 **问题3：**数据拆分后比较分散，不方便

本文首发于公众号：Hunter后端 原文链接：Redis数据结构七之listpack和quicklist 本篇笔记介绍 listpack 和 quicklist 两种结构 按照顺序，本来应该先介绍 quicklist 的结构，quicklist 在 7.0 之前的版本是由双向链表和压缩列表构成的，但是在 7.0 版本已经变成了由双向链表和 listpack 实现，所以在这里我们先介绍一下