🔥博客主页： 【小扳_-CSDN博客】**
❤感谢大家点赞👍收藏⭐评论✍**
文章目录
[1.0 Redis 底层数据结构](#1.0 Redis 底层数据结构)
[1.1 Redis 数据结构 - 动态字符串 SDS](#1.1 Redis 数据结构 - 动态字符串 SDS)
[1.2 Redis 数据结构 - Intset](#1.2 Redis 数据结构 - Intset)
[1.3 Redis 数据结构 - Dict](#1.3 Redis 数据结构 - Dict)
[1.3.1 Dict 的渐进式 rehash](#1.3.1 Dict 的渐进式 rehash)
[1.4 Redis 数据结构 - ZipList](#1.4 Redis 数据结构 - ZipList)
[1.5 Redis 数据结构 - QuickList](#1.5 Redis 数据结构 - QuickList)
[1.6 Redis 数据结构 - SkipList](#1.6 Redis 数据结构 - SkipList)
[1.7 Redis 数据结构 - RedisObject](#1.7 Redis 数据结构 - RedisObject)
[2.0 数据类型](#2.0 数据类型)
[2.1 数据类型 - String](#2.1 数据类型 - String)
[2.2 数据类型 - List](#2.2 数据类型 - List)
[2.3 数据类型 - Set](#2.3 数据类型 - Set)
[2.4 数据类型 - ZSet](#2.4 数据类型 - ZSet)
[2.5 数据类型 - Hash](#2.5 数据类型 - Hash)
1.0 Redis 底层数据结构
在 Redis 的底层实现中，除了高层的抽象数据结构（如字符串、哈希、列表、集合等）之外，还有一些更底层的原始数据结构。
1.1 Redis 数据结构 - 动态字符串 SDS
简单动态字符串，简称 SDS 。
Redis 是 c 语言实现的，其中 SDS 是一个结构体，结构如下：
字段解析：
1）uint8_t len：表示 buf 字符数组中已经保存的字符个数，因为一个字符占一个字节，也可以表示已保存的字节数，且不包含结束标识： "\0" 。uint8_t 代表 len 占用了 8 个比特位，也就是一个字节，因此表示 buf 字符数组的最大容量为 2^8 。
2）uint8_t alloc：表示 buf 字符数组申请的总的字节数，同理，且不包含结束标识："\0" 。
3）unsigned char flags：表示不同 SDS 的类型，用来控制 SDS 的头大小，一共有五种类型。不同的 SDS 类型，可以表示 buf 的容量大小不同。
4）char buf[]：字符数组，存放真实数据的容器。
举个例子：
一个包含字符串 "name" 的 SDS 结构体如下：
SDS 之所以叫做动态字符串，是因为它具备动态扩容的能力：
1）如果新字符串小于 1 M，则新空间为扩展后字符串长度的两倍 + 1 。
2）如果新字符串大于 1 M，则新空间为扩展后字符串长度 + 1M + 1，称为内存预分配。
举个例子：
一个原本的字符串数组为 "hi" 的 SDS 结构为：
接着，假如追加一段字符串 ",Amy"，这里首先会申请新的内存空间：
由于 "hi,Amy" 加起来的大小为 6 个字节，小于 1M，因此需要扩展至 13 个字节大小即可。
新的字符数组的 SDS 结构如下：
关于 alloc 为什么不是 13 个字节呢？
这是因为 alloc 表示申请大小不包含结束标识 "\0"，实际上，是扩展至 13 个字节大小。
动态字符串 SDS 的优点：
1）获取字符串长度的时间复杂度为 O(1) 。
2）支持动态扩容。
3）由于支持内存预分配机制，因此减少内存分配次数。
4）由于表示了字符数组的总长度，因此明确结束标识的具体位置，所以二进制安全。
1.2 Redis 数据结构 - Intset
IntSet 是 Redis 中 set 集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。
IntSet 结构如下：
字段解析：
1）uint32_t encoding：编码方式，支持存放 16、32、64 位整数。该字段的目的是规定在整数数组中的每一个数据的范围大小。
2）uint32_t length：元素个数，表示的范围由 encoding 编码方式决定。
3）int8_t cotents[]：具体存放的数据，每一个数据的范围大小都是由 encoding 编码方式来决定的。
为了方便查找，Redis 会将 intset 中所有的整数按照升序依次保存在 contents 数组中，结构如下：
现在数组中每个数字都是在两个字节的范围内，因此采用的编码方式是 INTSET_ENC_INT16，每部分占用的字节大小为：
encoding：固定占用 4 个字节。
length：固定占用 4 个字节。
contents：2 字节 * 3 = 6 个字节。
IntSet 升级：
当要插入的数字大小当前整数所表示的范围时，intset 会自动升级编码方式到合适大小。
现在，假设有一个 intset，元素为：{5，10，20}，采用的编码是 INTSET_ENC_INT16，则每个整数占 2 个字节，接着向其中添加一个数字 50000，这个数字超出了 int16_t 的表示范围，intset 会自动升级编码方式到合适的大小，流程如下：
1）升级编码为 INTSET_ENC_INT32，每个整数占 4 个字节，并按照新的的编码方式及元素个数扩容数组。
2）倒叙依次将数组中的元素拷贝到扩容后的正确位置。
3）将待添加的元素放入数组末尾。
4）最后，将 intset 的 encoding 属性改为 INTSET_ENC_INT32，将 length 属性改为 4 。
IntSet 可以看做是特殊的整数数组，具备的特点：
1）Redis 会确保 Intset 中的元素唯一、有序。
2）具备类型升级机制，可以节省内存空间。
3）底层采用二分查找方式来查询。
1.3 Redis 数据结构 - Dict
Redis 是一个键值型的数据库，可以根据键实现快速的增删改查。而键与值的映射关系正是通过 Dict 来实现的。
Dict 由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）。
哈希表和哈希节点的结构体：
哈希表由数组和链表组成，而链表节点则为哈希点。
字段解析：
1）dictEntry **table：表示指针指向哈希表的地址。
2）unsigned long size：哈希表大小，哈希表的大小总是设置为： 2^n 次方，最小的哈希表为 4 。
3）unsigned long sizemask：哈希表大小的掩码，总等于 size - 1，用来计算哈希点具体存放在数组的哪一个索引下的链表中。
当向 Dict 添加键值对时，Redis 首先根据 key 计算出 hash 值，然后利用 hash 值 & sizemask 来计算元素应该存储数组中的哪个索引位置，最后再进行头插链表的方式存储起来。
4）unsigned long used：哈希节点的个数。
5）void *key：指向 key 的地址。
6）union{} value：联合体，表示 value 的类型。
7）struct dictEntry *next：指向下一个节点。
字典的结构体：
字段解析：
1）dictType *type：dict 类型，内置不同的 hash 函数。不用太在意该字段，了解即可。
2）void *privdata：私有数据，在做特殊 hash 运算时用。不用太在意该字段，了解即可。
3）dictht ht[2]：一个 Dict 包含两个哈希表，其中一个是当前数据，另一个一般是空，rehash 时使用。在扩容或者收缩数组大小会使用该字段。
4）long rehashidx：rehash 的进度，-1 表示未进行。
5）int16_t pauserehash：rehash 是否暂停，1 则暂停，0 则继续。
最终的结构：
1.3.1 Dict 的渐进式 rehash
Dict 中的 HashTable 就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。
负载因子：LoadFactor = used / size ；
Dict 在每次新增键值对时都会检查负载因子，满足以下两种情况时会触发哈希表扩容：
1）哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程。
2）哈希表的 LoadFactor > 5 。
Dict 除了扩容以外，每次删除元素时，也会对负载因子做检查，当 LoadFactor < 0.1 时，会做哈希表收缩。
不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的 size 和 sizemask 变化，而 key 的查询与 sizemask 有关。因此必须对哈希表中的每一个 key 进行重新计算索引，插入新的哈希表，这个过程为 rehash，过程如下：
1）计算新 hash 表的 realeSize，值取决于当前要做的是扩容还是收缩：
如果是扩容，则新 size 为第一个大于等于 dict.ht[0].used + 1 的 2^n。
如果是收缩，则新 size 为第一个大于等于 dict.ht[1].used 的 2^n（不得小于 4）
2）按照新的 realeSize 申请内存空间，创建 dictht，并赋值给 dict.ht[1]。
3）设置 dict.rehashidx = 0，标示开始 rehash 。
4）每次执行新增、查询、修改、删除操作时，都检查一下 dict.rehashidx 是否大于 -1，如果是则将 dict.ht[0].table[rehashidx] 的 entry 链表 rehash 到 dict.ht[1]，并且将 rehashidx++ 。直至 dict.ht[0] 的所有数据都 rehash 到 dict.ht[1] 中。
5）将 dict.ht[1] 赋值给 dict.ht[0]，给 dict.ht[1] 初始化为空哈希表，释放原来的 dict.ht[0] 的内存。
6）将 rehashidx 赋值为 -1，代表 rehash 结束。
7）在 rehash 过程中，新增操作，则直接写入 ht[1]，查询、修改和删除会在 dict.ht[0] 和 dict.ht[1] 依次查找并执行。这样可以确保 ht[0] 的数据只减不增，随着 rehash 最终为空。
最终的结构：
1.4 Redis 数据结构 - ZipList
ZipList 是一种特殊的 "双端链表"，由一系列特殊的编码连续内存块组成。可以在任意一端进行压入/弹出操作，并且该操作的时间操作复杂度为：O(1) 。
字段解析：
1）zlbytes：4 个字节，记录整个压缩列表占用的内存字节数。
2）zltail：4 个字节，记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。
3）zllen：2 个字节，记录了压缩列表包含的节点数量。最大值为 UINT16_MAX(65534)，如果超过这个值，此处会记录为 65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。
4）entry：长度不定，压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
5）zlend：1 个字节，特殊值 0xFF（十进制 255），用于标记压缩列表的末端。
ZipList 中的 entry 并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用 16 个字节，浪费内存。而是采用如下结构：
字段解析：
1）previous_entry_length：前一节点的长度，占 1 个或者 5 个字节：
如果前一节点的长度小于 254 字节，则采用 1 个字节来保存这个长度值。
如果前一节点的长度大于 254 字节，则采用 5 个字节来保存这个长度值，第一个字节为 0xfe，后四个字节才是真实长度数据。
2）encoding：编码属性，记录 content 的数据类型（字符串还是整数）以及长度，占用 1 个、2 个或者 5 个字节。
编码分为字符串和整数两种：
字符串：如果 encoding 是以 "00"、"01" 或者 "10" 开头，则证明 content 是字符串；
举个例子：
整数：如果 encoding 是以 "11" 开始，则证明 content 是整数，且 encoding 固定只占用 1 个字节。
举个例子：
3）contents：负责保存节点的数据，可以是字符串或者整数。
ZipList 特征：
1）压缩列表的可以看做一种连续内存空间的"双向链表"。
2）列表的节点之间不是通过指针连接，而是记录上一个节点和本节点长度来寻址，内存占用较低。
3）如果列表数据过多，导致链表过长，可能影响查询性能。
4）增或删较大数据时有可能发生连续更行问题。
1.5 Redis 数据结构 - QuickList
ZipList 虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低，该怎么办呢？
这就不得不引入新的数据结构 QuickList，它是一个双端链表，只不过链表中的每个节点都是一个 ZipList，结构如下：
1）为了避免 QuickList 中的每个 ZipList 中 entry 过多，Redis 提供了一个配置项：list-max-ziplist-size 来限制。
如果值为正，则代表 ZipList 的允许的 entry 个数的最大值。
如果值为负，则代表 ZipList 的最大内存大小，分五种情况：
-1：每个 ZipList 的内存占用不能超过 4 kb；
-2：每个 ZipList 的内存占用不能超过 8 kb；
-3：每个 ZipList 的内存占用不能超过 16 kb；
-4：每个 ZipList 的内存占用不能超过 32 kb；
-5：每个 ZipList 的内存占用不能超过 64 kb；
其默认值为：-2
2）除了控制 ZipList 的大小，QuickList 还可以对节点的 ZipList 做压缩。通过配置项 list-compress-depth 来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。
0：特殊值，代表不压缩。
1：标示 QuickList 的首尾各有 1 个节点不压缩，中间节点压缩。
2：标示 QuickList 的首尾各有 2 个节点不压缩，中间节点压缩。
以此类推......
默认值是 0 ，不压缩节点。
QuickList 与 QuickListNode 的结构源码：
结构如下：
QuickList 的特点：
1）是一个节点为 ZipList 的双端链表
2）节点采用 ZipList，解决了传统链表的内存占用问题。
3）控制了 ZipList 大小，解决连续内存空间申请效率问题。
4）中间节点可以压缩，进一步节省内存。
1.6 Redis 数据结构 - SkipList
首先是链表，但与传统链表相比有以下差异：
1）元素按照升序排序存储。
2）节点可能包含多个指针，指针跨度不同。
在跳表中查找目标数据的步骤：
1）初始化指针：从跳表的最高层的头节点开始，初始化一个指针（通常称为 current）。
2）向右移动：在当前层中，检查 current 节点的下一个节点的值。如果这个值小于目标值，则将 current 指针移动到下一个节点。
3）找到合适的位置：如果下一个节点的值大于或等于目标值，或者已经到达当前层的末尾，则停止此层的移动。
4）向下移动：如果当前层已经达到目标值或找到了更大的值，改变层级，将 current 指针向下移动到下一层。如果目标值小于当前层的下一个节点的值， 则在这一层的当前节点停止查找，进入下一层按步骤 2 进行查找。
5）重复步骤：重复步骤 2 到步骤 4，直到找到目标值或到达底层。如果找到了目标值，则查找成功；
如果到达底层且没有找到目标值：
在底层，检查当前节点的值。
如果当前节点的值等于目标值，则查找成功。
如果当前节点的值小于目标值，继续移动到下一个节点。
如果当前节点的值大于目标值，停止查找。
SkipList 结构源码：
SkipList 结构：
SkipList 的特点：
1）跳跃表是一个双向链表，每一个节点都包含 score 和 ele 值。
2）节点按照 score 值排序，score 值一样则按照 ele 字典排序。
3）每一个节点都快包含多层指针，层数是 1 到 32 之间的随机数。
4）不同层指针到下一个节点的跨度不同，层级越高，跨度越大。
5）增删改查效率与红黑树基本一致，实现却更简单。
1.7 Redis 数据结构 - RedisObject
Redis 中的任意数据类型的键和值都会被封装为一个 RedisObject，也叫做 Redis 对象，源码如下：
字段解析：
1）unsigned type：对象类型，可以是 string、hash、list、set、zset，占用 4 个 bit 位。
2）unsigned encoding：底层编码方式，共有 11 种，占 4 个 bit 位。
3）int refcount：对象引用计数器，计数器为 0 则说明对象无人引用，可以被回收。
4）void *ptr：指针，指向存放实际数据的空间。
5）unsigned lru：lru 表示该对象最后一次被访问的时间，其占用 24 个 bit 位。便于判断空闲时间太久的 key 。
Redis 中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：
2.0 数据类型
常见的五种数据类型：String、List、set、zset、hash，以下介绍这五种的数据类型，底层用到的数据结构：
2.1 数据类型 - String
String 是 Redis 中最常见的数据存储类型：
1）其基本编码方式是 RAW，基于简单动态字符串（SDS）实现，存储上限为 512 mb 。
结构如下：
2）如果存储的 SDS 长度小于 44 字节，则会采用 EMBSTR 编码，此时 object head 与 SDS 是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。
结构如下：
3）如果存储的字符串是整数值，并且大小在 LONG_MAX 范围内，则会采用 INT 编码：直接将数据保存在 RedisObject 的 ptr 指针位置(刚刚好 8 字节)，不再需要 SDS 了。
结构如下：
2.2 数据类型 - List
Redis 的 List 结构类似一个双端链表，可以从首尾操作列表中的元素：
在 3.2 版本之前，Redis 采用 ZipList 和 LinkedList 来实现 List，当元素数量小于 512 并且元素大小小于 64 字节时采用 ZipList 编码，超过则采用 LinkedList 编码。
在 3.2 版本之后，Redis 统一采用 QuickList 来实现 List：
整体结构：
2.3 数据类型 - Set
Set 是 Redis 中的单列集合，满足下列特点：
1）不保证有序性
2）保证元素唯一（可以判断元素是否存在）
3）求交集、并集、差集
因此：
如果为了查询效率和唯一性，set 采用 HT 编码（Dict）。Dict 中的 key 用来存储元素，value 统一为 null 。
结构如下：
如果存储的所有数据都是整数，并且元素数量不超过 set-max-intset-entries 时，Set 会采用 IntSet 编码，以节省内存。
结构如下：
相关的源码：
2.4 数据类型 - ZSet
ZSet 也就是 SortedSet，其中每一个元素都需要指定一个 score 值和 member 值。
其特点：可以根据 score 值排序、member 必须唯一、可以根据 member 查询分数。
因此：
zset 底层数据结构必须满足键值存储、键必须唯一，可排序：
1）SkipList：可以排序，并且同时存储 score 和 ele 值（member）
2）HT（Dict）：可以键值存储，并且可以根据 key 找 value
源码如下：
整体结构：
当元素数量不多时，HT 和 SkipList 的优势不明显，而且更耗内存。因此 zset 还会采用 ZipList 结构来节省内存，不过需要同时满足两个条件：
1）元素数量小于 zset_max_ziplist_entries，默认值 128
2）每个元素都小于 zset_max_ziplist_value 字节，默认值 64
源码如下：
思考：ziplist 本身没有排序功能，而且没有键值对的概念，因此需要有 zset 通过编码实现：
1）ZipList 是连续内存，因此 score 和 element 是紧挨在一起的两个 entry，element 在前，score 在后。
2）score 越小越接近队首，score 越大越接近队尾，按照 score 值升序排序。
整体结构如下：
2.5 数据类型 - Hash
Hash 结构与 Redis 中的 Zset 非常类似：都是键值存储、都要求根据键获取值、键必须唯一。
因此：
Hash 结构默认采用 ZipList 编码，用以节省内存。ZipList 中相邻的两个 entry 分别保存 field 和 value 。
结构如下：
当数据量较大，Hash 结构会转为 HT 编码，也就是 Dict，触发条件有两个：
1）ZipList 中的元素数量超过了 hash-max-ziplist-entries（默认 512）
2）ZipList 的任意 entry 大小超过了 hash-max-ziplist-value（默认 64 字节）
结构如下：
