Redis 中对于 Set 类型的底层实现，直接采用了 hashTable（哈希表）。但对于 Hash、ZSet、List 集合的底层实现进行了特殊的设计，使其保证了 Redis 的高性能。
# 一、两种实现的选择
对于Hash 与ZSet 集合，其底层的实现实际有两种：压缩列表zipList，与跳跃列表skipList。这两种实现对于用户来说是透明的，但用户写入不同的数据，系统会自动使用不同的实现。
当同时满足以配置文件 redis.conf 中相关集合元素数量阈值与元素大小阈值两个条件，使用的就是压缩列表 zipList，只要有一个条件超出使用的就是跳跃列表 skipList。例如，对于 ZSet 集合中这两个条件如下：
● 集合元素个数小于redis.conf 中 zset-max-ziplist-entries 属性的值，其默认值为 128
● 每个集合元素大小都小于 redis.conf 中zset-max-ziplist-value 属性的值，其默认值为 64字节
# 二、ziplist
先看第一种压缩列表ziplist，通常称为压缩列表，是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构由三部分构成：head、entries 与 end。这三部分在内存上是连续存放的。
它的底层结构如下图所示：
# 1、head
head 又由三部分构成：
● zlbytes：占 4 个字节，用于存放整个zipList 列表的数据结构所占的字节数，也就是列表长度，它包括 zlbytes本身的长度。
● zltail：占 4 个字节，用于存放 zipList 中最后一个 entry 在整个数据结构中的偏移量（字节）。该数据的存在可以快速定位列表的尾 entry 位置，以方便操作。
● zllen：占 2 字节，用于存放列表包含的 entry 个数。由于其只有 16 位，所以 zipList 最多可以含有的 entry 个数为 216-1 = 65535 个。
# 2、entries
entries 是真正的列表，由很多的列表元素 entry 构成。由于不同的元素类型、数值的不同，从而导致每个entry 的长度不同。
每个entry 由三部分构成：
● prevlength：该部分用于记录上一个 entry 的长度，以实现逆序遍历。默认长度为 1 字节，只要上一个 entry 的长度<254 字节，prevlength 就占 1字节，否则其会自动扩展为 5 字节长度。
● encoding：该部分用于标志后面的 data 的具体类型。如果 data 为整数类型，encoding固定长度为 1 字节。如果 data 为字符串类型，则 encoding 长度可能会是 1 字节、2 字节或 5 字节。data 字符串不同的长度，对应着不同的 encoding 长度。
● data：真正存储的数据。数据类型只能是整数类型或字符串类型。不同的数据占用的字节长度不同。
# 3、end
end 只包含一部分，称为 zlend。占 1 个字节，值固定为 255，即二进制位为全 1，表示一个 zipList 列表的结束。
# 三、listPack
对于 ziplist，实现复杂，为了逆序遍历，每个 entry 中包含前一个entry 的长度，这样会导致在 ziplist 中间修改或者插入 entry 时需要进行级联更新。即当保存的元素数量增加或者元素变大时，压缩列表的内存空间需要进行重新分配，这可能导致性能问题，尤其是在发生连锁更新的情况下。
连锁更新是指当压缩列表中的某个节点需要更新，并且更新后的长度超过了原节点的长度时，就会触发连锁更新。这种更新会导致整个压缩列表的内存空间重新分配，影响了访问性能。
因此，由于连锁更新可能导致多次内存重分配，进而影响压缩列表的访问性能，所以压缩列表在保存的节点数量较多或者经常发生节点更新的情况下并不适用。只有在节点数量较少的情况下，即使发生连锁更新，对性能的影响也是可以接受的。
在高并发的写操作场景下会极度降低 Redis 的性能。为了实现更紧凑、更快的解析，更简单的实现，重写实现了 ziplist，并命名为 listPack。
在 Redis 7.0 中，已经将 zipList 全部替换为了 listPack，但为了兼容性，在配置中也保留了 zipList 的相关属性。
listPack 也是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构也由三部分构成：head、entries 与 end，且这三部分在内存上也是连续存放的。
listPack 与zipList 的重大区别在head 与每个entry 的结构上，表示列表结束的end 与zipList的 zlend 是相同的，占一个字节，且 8 位全为 1。
# 1、head
head 由两部分构成：
● totalBytes：占 4 个字节，用于存放 listPack 列表整体数据结构所占的字节数，包括totalBytes 本身的长度。
● elemNum：占 2 字节，用于存放列表包含的 entry 个数。其意义与 zipList 中 zllen 的相同。与 zipList 的 head 相比，没有了记录最后一个entry 偏移量的 zltail。
# 2、entries
entries 也是 listPack 中真正的列表，由很多的列表元素 entry 构成。由于不同的元素类型、数值的不同，从而导致每个 entry 的长度不同。但与 zipList 的 entry 结构相比，listPack的 entry 结构发生了较大变化。
其中最大的变化就是没有了记录前一个entry 长度的 prevlength，而增加了记录当前 entry 长度的element-total-len。而这个改变仍然可以实现逆序遍历，但却避免了由于在列表中间修改或插入entry 时引发的级联更新。
每个entry 仍由三部分构成：
● encoding：该部分用于标志后面的 data 的具体类型。如果 data 为整数类型，encoding长度可能会是 1、2、3、4、5 或 9 字节。不同的字节长度，其标识位不同。如果 data为字符串类型，则encoding 长度可能会是 1、2 或 5 字节。data 字符串不同的长度，对应着不同的 encoding 长度。
● data：真正存储的数据。数据类型只能是整数类型或字符串类型。不同的数据占用的字节长度不同。
● element-total-len：该部分用于记录当前 entry 的长度，用于实现逆序遍历。由于其特殊的记录方式，使其本身占有的字节数据可能会是 1、2、3、4 或 5 字节。
# 3、end
与zipList的 zlend 是相同的，占一个字节，且 8 位全为 1，表示结束。
# 四、skipList
skipList，跳跃列表，简称跳表，是一种随机化的数据结构，基于并联的链表，实现简单，查找效率较高。简单来说跳表也是链表的一种，只不过它在链表的基础上增加了跳跃功能。也正是这个跳跃功能，使得在查找元素时，能够提供较高的效率。
# 1、skipList原理
假设有一个带头尾结点的有序链表。
在该链表中，如果要查找某个数据，需要从头开始逐个进行比较，直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点，或者找到最后尾结点，后两种都属于没有找到的情况。同样，当我们要插入新数据的时候，也要经历同样的查找过程，从而确定插入位置。
为了提升查找效率，在偶数结点上增加一个指针，让其指向下一个偶数结点。
这样所有偶数结点就连成了一个新的链表（简称高层链表），当然，高层链表包含的节点个数只是原来链表的一半。此时再想查找某个数据时，先沿着高层链表进行查找。当遇到第一个比待查数据大的节点时，立即从该大节点的前一个节点回到原链表中进行查找。例如，若想插入一个数据 20，则先在（8，19，31，42）的链表中查找，找到第一个比 20 大的节点 31，然后再在高层链表中找到 31 节点的前一个节点 19，然后再在原链表中获取到其下一个节点值为 23。比 20 大，则将 20 插入到 19 节点与 23 节点之间。若插入的是 25，比节点23 大，则插入到 23 节点与 31 节点之间。
该方式明显可以减少比较次数，提高查找效率。如果链表元素较多，为了进一步提升查找效率，可以将原链表构建为三层链表，或再高层级链表。层级越高，查找效率就会越高 。
# 2、存在的问题
这种对链表分层级的方式从原理上看确实提升了查找效率，但在实际操作时就出现了问题：由于固定序号的元素拥有固定层级，所以列表元素出现增加或删除的情况下，会导致列表整体元素层级大调整，但这样势必会大大降低系统性能。
例如，对于划分两级的链表，可以规定奇数结点为高层级链表，偶数结点为低层级链表。对于划分三级的链表，可以按照节点序号与 3 取模结果进行划分。但如果插入了新的节点，或删除了原来的某些节点，那么必定会按照原来的层级划分规则进行重新层级划分，那么势必会大大降低系统性能。
# 3、算法优化
为了避免前面的问题，skipList 采用了随机分配层级方式。即在确定了总层级后，每添加一个新的元素时会自动为其随机分配一个层级。这种随机性就解决了节点序号与层级间的固定关系问题。
上图演示了列表在生成过程中为每个元素随机分配层级的过程。从这个 skiplist 的创建和插入过程可以看出，每一个节点的层级数都是随机分配的，而且新插入一个节点不会影响到其它节点的层级数。只需要修改插入节点前后的指针，而不需对很多节点都进行调整。这就降低了插入操作的复杂度。
skipList 指的就是除了最下面第 1 层链表之外，它会产生若干层稀疏的链表，这些链表里面的指针跳过了一些节点，并且越高层级的链表跳过的节点越多。在查找数据的时先在高层级链表中进行查找，然后逐层降低，最终可能会降到第 1 层链表来精确地确定数据位置。在这个过程中由于跳过了一些节点，从而加快了查找速度。
当然skiplist的这种速度上的优化只有在节点数量庞大的前提下才会有显著的效果，这也是为什么redis配置文件中规定小数据量用压缩列表，大数据量用跳表。
# 五、quickList
快速列表（quickList）是Redis中用于实现列表（List）数据结构的底层数据结构之一。它是在Redis 3.2版本中引入的，取代了之前使用的zipList和linkedList。
快速列表本身就是一个双向无循环链表，每个节点都是一个zipList。zipList是一种紧凑存储多个数据元素的数据结构，它将多个元素按照连续的方式存储在一块连续的内存空间中，节省了存储空间。而linkedList是普通的双向链表。
快速列表将linkedList按照一定的段进行切分，每一段使用zipList来存储若干真正的数据元素。这样可以将大型列表分成多个小的zipList，每个zipList都可以紧凑地存储数据，减少了存储空间的浪费。多个zipList之间使用双向指针串接起来，形成一个完整的双向链表结构。
在配置文件中，可以通过list-max-ziplist-size属性指定每个zipList中最多可以存放多少个数据元素。当达到这个容量限制时，会自动创建一个新的zipList节点，并将新的数据元素存储在其中。
快速列表的设计吸取了zipList和linkedList的优点，避免了它们各自的不足之处。它既可以紧凑地存储数据，节省存储空间，又能够高效地支持插入、删除等操作。
# 1、检索操作
为了更深入的理解 quickList 的工作原理，通过对检索、插入、删除等操作的实现分析来加深理解。
对于 List 元素的检索，都是以其索引 index 为依据的。quickList 由一个个的 zipList 构成，每个 zipList 的 zllen 中记录的就是当前 zipList 中包含的 entry 的个数，即包含的真正数据元素的个数。根据要检索元素的 index，从 quickList 的头节点开始，逐个对 zipList 的 zllen 做 sum求和，直到找到第一个求和后sum 大于 index 的 zipList，那么要检索的这个元素就在这个 zipList 中。
# 2、插入操作
由于 zipList 是有大小限制的，所以在 quickList 中插入一个元素在逻辑上相对就比较复杂一些。假设要插入的元素的大小为 insertBytes，而查找到的插入位置所在的 zipList 当前的大小为 zlBytes，那么具体可分为下面几种情况：
● 情况一：当 insertBytes + zlBytes <= list-max-ziplist-size 时，直接插入到 zipList 中相应位置即可。
● 情况二：当 insertBytes + zlBytes > list-max-ziplist-size，且插入的位置位于该 zipList 的首部位置，此时需要查看该 zipList 的前一个 zipList 的大小 prev_zlBytes。
◆ 若 insertBytes + prev_zlBytes<= list-max-ziplist-size 时，直接将元素插入到前一个zipList 的尾部位置即可。
◆ 若 insertBytes + prev_zlBytes> list-max-ziplist-size 时，直接将元素自己构建为一个新的 zipList，并连入 quickList 中。
● 情况三：当 insertBytes + zlBytes > list-max-ziplist-size，且插入的位置位于该 zipList 的尾部位置，此时需要查看该 zipList 的后一个 zipList 的大小 next_zlBytes。
◆ 若 insertBytes + next_zlBytes<= list-max-ziplist-size 时，直接将元素插入到后一个 zipList 的头部位置即可。
◆ 若 insertBytes + next_zlBytes> list-max-ziplist-size 时，直接将元素自己构建为一个新的 zipList，并连入 quickList 中。
● 情况四：当 insertBytes + zlBytes > list-max-ziplist-size，且插入的位置位于该 zipList 的中间位置，则将当前 zipList 分割为两个 zipList 连接入 quickList 中，然后将元素插入到分割后的前面 zipList 的尾部位置。
# 3、删除操作
对于删除操作，只需要注意一点，在相应的 zipList 中删除元素后，该 zipList 中是否还有元素。如果没有其它元素了，则将该 zipList 删除，将其前后两个 zipList 相连接。
# 六、key与value中元素的数量
前面讲述的 Redis 的各种特殊数据结构的设计，不仅极大提升了Redis 的性能，并且还使得 Redis 可以支持的 key 的数量、集合value 中可以支持的元素数量可以非常庞大。
● Redis 最多可以处理 232 个 key（约 42 亿），并且在实践中经过测试，每个 Redis 实例至少可以处理 2.5 亿个 key。
● 每个 Hash、List、Set、ZSet 集合都可以包含 232 个元素。