👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家

📕系列专栏：Spring源码、JUC源码、Kafka原理、分布式技术原理、数据库技术

🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦

🍂博主正在努力完成2023计划中：源码溯源，一探究竟

📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀

动态字符串SDS

SDS 简介

无论是 Redis 的 Key 还是 Value，其基础数据类型都是字符串。例如，Hash 型 Value 的field 与 value 的类型、List 型、Set 型、ZSet 型 Value 的元素的类型等都是字符串。虽然 Redis是使用标准 C 语言开发的，但并没有直接使用 C 语言中传统的字符串表示，而是自定义了一种字符串。这种字符串本身的结构比较简单，但功能却非常强大，称为简单动态字符串，Simple Dynamic String，简称 SDS。

注意，Redis 中的所有字符串并不都是 SDS，也会出现 C 字符串。C 字符串只会出现在字符串"字面常量"中，并且该字符串不可能发生变更。

SDS 结构

SDS 不同于 C 字符串。C 字符串本身是一个以双引号括起来，以空字符'\0'结尾的字符序列。但 SDS 是一个结构体，定义在 Redis 安装目录下的 src/sds.h 中：

c 复制代码

struct sdshdr {
    // 字节数组，用于保存字符串
    char buf[];
    // buf[]中已使用字节数量，称为 SDS 的长度
    int len;
    // buf[]中尚未使用的字节数量
    int free;
}

例如执行 SET country "China"命令时，键 country 与值"China"都是 SDS 类型的，只不过一个是 SDS 的变量，一个是 SDS 的字面常量。"China"在内存中的结构如下：

通过以上结构可以看出，SDS 的 buf 值实际是一个 C 字符串，包含空字符'\0'共占 6 个字节。但 SDS 的 len 是不包含空字符'\0'的。

该结构与前面不同的是，这里有 3 字节未使用空间。

SDS 的优势

C 字符串使用 Len+1 长度的字符数组来表示实际长度为 Len 的字符串，字符数组最后以空字符'\0'结尾，表示字符串结束。这种结构简单，但不能满足 Redis 对字符串功能性、安全性及高效性等的要求。

防止"字符串长度获取"性能瓶颈

对于 C 字符串，若要获取其长度，则必须要通过遍历整个字符串才可获取到的。对于超长字符串的遍历，会成为系统的性能瓶颈。

但，由于 SDS 结构体中直接就存放着字符串的长度数据，所以对于获取字符串长度需要消耗的系统性能，与字符串本身长度是无关的，不会成为 Redis 的性能瓶颈。

保障二进制安全

C 字符串中只能包含符合某种编码格式的字符，例如 ASCII、UTF-8 等，并且除了字符串末尾外，其它位置是不能包含空字符'\0'的，否则该字符串就会被程序误解为提前结束。而在图片、音频、视频、压缩文件、office 文件等二进制数据中以空字符'\0'作为分隔符的情况是很常见的。故而在 C 字符串中是不能保存像图片、音频、视频、压缩文件、office 文件等二进制数据的。

但 SDS 不是以空字符'\0'作为字符串结束标志的，其是通过 len 属性来判断字符串是否结束的。所以，对于程序处理 SDS 中的字符串数据，无需对数据做任何限制、过滤、假设，只需读取即可。数据写入的是什么，读到的就是什么。

减少内存再分配次数

SDS 采用了空间预分配策略 与惰性空间释放策略来避免内存再分配问题。

空间预分配策略是指，每次 SDS 进行空间扩展时，程序不但为其分配所需的空间，还会为其分配额外的未使用空间，以减少内存再分配次数。而额外分配的未使用空间大小取决于空间扩展后 SDS 的 len 属性值。

如果 len 属性值小于 1M，那么分配的未使用空间 free 的大小与 len 属性值相同。
如果 len 属性值大于等于 1M ，那么分配的未使用空间 free 的大小固定是 1M。

SDS 对于空间释放采用的是惰性空间释放策略。该策略是指，SDS 字符串长度如果缩短，那么多出的未使用空间将暂时不释放，而是增加到 free 中。以使后期扩展 SDS 时减少内存再分配次数。

兼容 C 函数

Redis 中提供了很多的 SDS 的 API，以方便用户对 Redis 进行二次开发。为了能够兼容 C函数，SDS 的底层数组 buf[]中的字符串仍以空字符'\0'结尾。现在要比较的双方，一个是 SDS，一个是 C 字符串，此时可以通过 C 语言函数strcmp(sds_str->buf，c_str)

新版本的SDS

SDS结构大致上可以分为2大部分：header部分和buff部分，并且header部分和buff部分在内存中是连续的。

header部分保存的是SDS一些源数据信息。

其中:

len表示: 字符串的长度;
alloc表示：字符串的长度 + 额外预留空间的长度。alloc代表可用来存储字符空间的总大小，但是不包括null-term，所以是比实际分配出来的buff长度减1;

除了我们上面提到过的len和alloc，这里还多了一个flag字段。flag字段决定len和alloc的变量类型。具体什么意思呢？因为字符串大小不固定有长有短，比如我们要保存"hello"这个字符串，那么对于len和alloc变量来说，最合适的变量类型应该是uint8，用一个字节来存储就够了，如果用uint16、uint32或uint64都显得有点太浪费。基于此SDS根据需要保存的字符串长度设计了如下5种flag类型，flag本身占用1个字节，如下表所示:

flag	flag_value	字符串长度(len)字节	(len、alloc) type
SDS_TYPE_5	0	特殊	特殊
SDS_TYPE_8	1	len < (1 << 8) 256	uint8
SDS_TYPE_16	2	len < (1 << 16) 65536	uint16
SDS_TYPE_32	3	len < (1 << 32)	uint32
SDS_TYPE_64	4	len >= (1 << 32)	uint64

假设我们要保存的字符串长度为len:

SDS_TYPE_5：这个比较特殊，注释上说未被使用，但是也不完全准确，无论如何这个类型都不是我们讨论的重点。
SDS_TYPE_8: 当len 小于 1 << 8，也就是小于256时，变量len和alloc用uint8类型。
SDS_TYPE_16: 当len 小于 1 << 16，也就是小于65536时，变量len和alloc用uint16类型。
SDS_TYPE_32: 当len 小于 1 << 32，也就是小于4294967296时，变量len和alloc用uint32类型。
SDS_TYPE_64: 当len 大于等于 1 << 32，也就是大于等于4294967296时，变量len和alloc用uint64类型。

我们来举个简单例子，假设我们要用SDS("hello")保存"hello"这个字符串。"hello"长度为5个字节，len为5，是小于 1 << 8。因此flag为SDS_TYPE_8，len、alloc变量类型为uint8各自占用一个字节，flag始终占用1个字节，如下图所示：

len值为5：表示hello字符串长度为5个字节；

alloc值为12: 表示一共分配出来可用空间12字节。buff总长度为13字节，由于null-term要额外占用1字节不能计算在内，因此需要减1；

flag值为1: 表示的是SDS_TYPE_8类型；

buff部分

Buff比较简单主要分为2个部分: 第一个部分是原生的C字符串，以null-term结尾，第二个部分是还未使用的额外空间，如下图所示。

前面说过SDS可以在一定程度上兼容C字符串，只要C-String部分是binary-safe，用户可以拿到SDS的buff起始地址（图中return to user），在只读场景当作原生C字符串使用。

还是以前面的"hello"字符串为例：

buff部分索引0~5存储"hello"的C字符串，索引6到索引12是预留空间还未使用。如果后续需要追加字符串并且在8个字节以内，即可直接修改，无需重新分配内存空间。

SDS扩容规则

当我们要往原SDS追加字符串时会触发SDS的扩容，为了阐述方便，我们定义如下变量：

len = 原SDS长度;

avail = 原SDS剩余预留空间长度;

addlen = 追加字符串的长度;

newlen = len + addlen 追加后字符串的总长度;

SDS的扩容规则如下：

如果原SDS预留空间空间avail大于等于追加字符串的长度addlen，不会触发扩容。
如果追加后的字符串总长度newlen小于1MB(1024*1024)，将newlen扩容为2倍再加1(null-term)，也就是newlen = newlen * 2 + 1。
如果追加后的字符串总长度newlen大于等于1MB(1024*1024)，将newlen额外扩容1MB再加1(null-term)，也就是newlen = newlen + 1MB + 1。

需要注意的是，如果newlen大于flag所指定的范围，flag的类型也需要随之变大。

我们来举几个例子，依次看一下这2个扩容规则：

规则1：假设有如下图的SDS("hello")，我们要追加字符串",world"。

变量初始化如下：

len = 5;

avail = alloc - len = 12 - 5 = 7;

addlen = ",world"的长度 = 6;

newlen = 5 + 6 = 11;

按照扩容规则，avail > addlen，不会触发扩容，因此可以原地追加，追加后的SDS如下图所示：

规则2：上面的SDS("hello,world")基础上，我们继续追加字符串";nihao"。

变量初始化如下：

len = 11;

avail = alloc - len = 12 - 11 = 1;

addlen = ";nihao"的长度 = 6;

newlen = 11 + 6 = 17;

按照扩容规则，avail < addlen，不满足规则1，newlen < 1MB，满足扩容规则2，因此扩容后的newlen为：

newlen = 17 * 2 + 1 = 35;

如下图所示：

总结

SDS巧妙的利用空间换时间的思想，虽然额外牺牲了一些空间，但是换来的是在高频场景下更佳优异的性能表现以及更好的兼容性。

集合的底层实现原理

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

zipList，通常称为压缩列表，是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构由三部分构成：head、entries 与 end。这三部分在内存上是连续存放的。

head

head 又由三部分构成：

zlbytes：占 4 个字节，用于存放 zipList 列表整体数据结构所占的字节数，包括 zlbytes本身的长度。
zltail：占 4 个字节，用于存放 zipList 中最后一个 entry 在整个数据结构中的偏移量（字节）。该数据的存在可以快速定位列表的尾 entry 位置，以方便操作。
zllen：占 2 字节，用于存放列表包含的 entry 个数。由于其只有 16 位，所以 zipList 最多可以含有的 entry 个数为 2^16-1 = 65535 个。

entries

entries 是真正的列表，由很多的列表元素 entry 构成。由于不同的元素类型、数值的不同，从而导致每个 entry 的长度不同。

每个 entry 由三部分构成：

prevlength：该部分用于记录上一个 entry 的长度，以实现逆序遍历。默认长度为 1 字节，只要上一个 entry 的长度<254 字节，prevlength 就占 1 字节，否则其会自动扩展为 3 字节长度。
encoding：该部分用于标志后面的 data 的具体类型。如果 data 为整数类型，encoding固定长度为 1 字节。如果 data 为字符串类型，则 encoding 长度可能会是 1 字节、2 字节或 5 字节。data 字符串不同的长度，对应着不同的 encoding 长度。
data：真正存储的数据。数据类型只能是整数类型或字符串类型。不同的数据占用的字节长度不同。

end

end 只包含一部分，称为 zlend。占 1 个字节，值固定为 255，即二进制位为全 1，表示一个 zipList 列表的结束。

listPack

对于 ziplist，实现复杂，为了逆序遍历，每个 entry 中包含前一个 entry 的长度，这样会导致在 ziplist 中间修改或者插入 entry 时需要进行级联更新。在高并发的写操作场景下会极度降低 Redis 的性能。为了实现更紧凑、更快的解析，更简单的实现，重写实现了 ziplist，并命名为 listPack。

在 Redis 7.0 中，已经将 zipList 全部替换为了 listPack，但为了兼容性，在配置中也保留了 zipList 的相关属性。

什么是 listPack

listPack 也是一个经过特殊编码的用于存储字符串或整数的双向链表。其底层数据结构也由三部分构成：head、entries 与 end，且这三部分在内存上也是连续存放的。

listPack与zipList的重大区别在head与每个entry的结构上，表示列表结束的end与zipList的 zlend 是相同的，占一个字节，且 8 位全为 1。

head

head 由两部分构成：

totalBytes：占 4 个字节，用于存放 listPack 列表整体数据结构所占的字节数，包括totalBytes 本身的长度。
elemNum：占 2 字节，用于存放列表包含的 entry 个数。其意义与 zipList 中 zllen 的相同。

与 zipList 的 head 相比，没有了记录最后一个 entry 偏移量的 zltail。

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 字节。

逆序遍历

在 Redis 中，ziplist 是一种紧凑的、压缩的、连续的内存数据结构，用于存储列表、哈希和有序集合等数据类型。listPack 是 ziplist 的一种变体，用于存储列表数据。

要实现逆序遍历 ziplist 或 listPack，可以使用以下步骤：

首先，通过指针定位到整个 ziplist 或 listPack 的末尾（即最后一个节点）。

然后，从末尾节点开始按照逆序遍历的顺序向前遍历。

每次迭代时，可以使用 prevlength 字段（对于 ziplist）或 element-total-len 字段（对于 listPack）来获取当前节点的长度。

通过减去当前节点的长度，可以得到上一个节点在内存中的位置，然后将指针移动到上一个节点。

重复上述步骤，直到遍历完所有节点。

需要注意的是，ziplist 和 listPack 的数据结构比较复杂，包含了多个字段和指针。在实际操作中，需要仔细处理指针的移动和字段的解析，以确保正确地实现逆序遍历。

skipList

什么是 skipList

skipList，跳跃列表，简称跳表，是一种随机化的数据结构，基于并联的链表，实现简单，查找效率较高。简单来说跳表也是链表的一种，只不过它在链表的基础上增加了跳跃功能。也正是这个跳跃功能，使得在查找元素时，能够提供较高的效率。

skipList 原理

假设有一个带头尾结点的有序链表。

在该链表中，如果要查找某个数据，需要从头开始逐个进行比较，直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点，或者找到最后尾结点，后两种都属于没有找到的情况。同样，当我们要插入新数据的时候，也要经历同样的查找过程，从而确定插入位置。

为了提升查找效率，在偶数结点上增加一个指针，让其指向下一个偶数结点。

这样所有偶数结点就连成了一个新的链表（简称高层链表），当然，高层链表包含的节点个数只是原来链表的一半。此时再想查找某个数据时，先沿着高层链表进行查找。当遇到第一个比待查数据大的节点时，立即从该大节点的前一个节点回到原链表中进行查找。例如，若想插入一个数据 20，则先在（8，19，31，42）的链表中查找，找到第一个比 20 大的节点 31，然后再在高层链表中找到 31 节点的前一个节点 19，然后再在原链表中获取到其下一个节点值为 23。比 20 大，则将 20 插入到 19 节点与 23 节点之间。若插入的是 25，比节点23 大，则插入到 23 节点与 31 节点之间。

该方式明显可以减少比较次数，提高查找效率。如果链表元素较多，为了进一步提升查找效率，可以将原链表构建为三层链表，或再高层级链表。

层级越高，查找效率就会越高。

存在的问题

这种对链表分层级的方式从原理上看确实提升了查找效率，但在实际操作时就出现了问题：由于固定序号的元素拥有固定层级，所以列表元素出现增加或删除的情况下，会导致列表整体元素层级大调整，但这样势必会大大降低系统性能。

例如，对于划分两级的链表，可以规定奇数结点为高层级链表，偶数结点为低层级链表。对于划分三级的链表，可以按照节点序号与 3 取模结果进行划分。但如果插入了新的节点，或删除的原来的某些节点，那么定会按照原来的层级划分规则进行重新层级划分，那么势必会大大降低系统性能

算法优化

为了避免前面的问题，skipList 采用了随机分配层级方式。即在确定了总层级后，每添加一个新的元素时会自动为其随机分配一个层级。这种随机性就解决了节点序号与层级间的固定关系问题。

上图演示了列表在生成过程中为每个元素随机分配层级的过程。从这个 skiplist 的创建和插入过程可以看出，每一个节点的层级数都是随机分配的，而且新插入一个节点不会影响到其它节点的层级数。只需要修改插入节点前后的指针，而不需对很多节点都进行调整。这就降低了插入操作的复杂度。

skipList 指的就是除了最下面第 1 层链表之外，它会产生若干层稀疏的链表，这些链表里面的指针跳过了一些节点，并且越高层级的链表跳过的节点越多。在查找数据的时先在高层级链表中进行查找，然后逐层降低，最终可能会降到第 1 层链表来精确地确定数据位置。在这个过程中由于跳过了一些节点，从而加快了查找速度。

quickList

什么是 quickList

quickList，快速列表，quickList 本身是一个双向无循环链表，它的每一个节点都是一个zipList。从Redis3.2版本开始，对于List的底层实现，使用quickList替代了zipList 和 linkedList。

zipList 与 linkedList 都存在有明显不足，而 quickList 则对它们进行了改进：吸取了 zipList 和 linkedList 的优点，避开了它们的不足。

quickList 本质上是 zipList 和 linkedList 的混合体。其将 linkedList 按段切分，每一段使用 zipList 来紧凑存储若干真正的数据元素，多个 zipList 之间使用双向指针串接起来。当然，对于每个 zipList 中最多可存放多大容量的数据元素，在配置文件中通过 list-max-ziplist-size属性可以指定。

检索操作

为了更深入的理解 quickList 的工作原理，通过对检索、插入、删除等操作的实现分析来加深理解。

对于 List 元素的检索，都是以其索引 index 为依据的。quickList 由一个个的 zipList 构成，每个 zipList 的 zllen 中记录的就是当前 zipList 中包含的 entry 的个数，即包含的真正数据元素的个数。根据要检索元素的 index，从 quickList 的头节点开始，逐个对 zipList 的 zllen 做 sum求和，直到找到第一个求和后 sum 大于 index 的 zipList，那么要检索的这个元素就在这个zipList 中。

插入操作

由于 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 的尾部位置

删除操作

对于删除操作，只需要注意一点，在相应的 zipList 中删除元素后，该 zipList 中是否还有元素。如果没有其它元素了，则将该 zipList 删除，将其前后两个 zipList 相连接。

Redis底层数据结构

动态字符串SDS

SDS 简介

SDS 结构

SDS 的优势

防止"字符串长度获取"性能瓶颈

保障二进制安全

减少内存再分配次数

兼容 C 函数

新版本的SDS

header部分

buff部分

SDS扩容规则

总结

集合的底层实现原理

两种实现的选择

zipList

什么是 zipList

head

entries

end

listPack

什么是 listPack

head

entries

逆序遍历

skipList

什么是 skipList

skipList 原理

存在的问题

算法优化

quickList

什么是 quickList

检索操作

插入操作

删除操作