【Redis】Redis的数据结构

1. 动态字符串SDS

Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。

虽然Redis是用C写的，但是为什么没有直接使用C的字符串？因为C语言字符串存在很多问题：

1. 获取字符串长度需要通过运算(数组实际长度=数组长度-1)
2. 非二进制安全：\0 是数组结束的标识符，这意味着我们数组中不能存储 \0 元素，否则遍历数组会出现问题
3. 不可修改

所以，Redis构建了一种新的字符串结构，称为简单动态字符串 (Simple Dynamic String），简称SDS。

例如，执行命令 set name 张三，那么Redis将在底层创建两个SDS，一个包含“name“的SDS，一个包含”张三“的SDS。

---

Redis是C语言实现的，其中SDS是一个结构体，源码如下：

例如，一个包含字符串”name“的sds结构如下：

SDS之所以叫做简单动态字符串，是因为它具备动态扩容能力，例如一个内容为”hi“的SDS：

我们想要给这个SDS追加一段字符串”,Amy“,这里首先会申请新内存空间：

• 如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1
• 如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1.

这种行为称作内存预分配。

SDS相较于C语言字符串的优点：

1. 获取字符串长度的时间复杂度为O(1)
2. 支持动态扩容
3. 减少内存分配次数
4. 二进制安全

---

2. IntSet

InSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。

结构如下：

其中的encoding包含三种模式，表示存储的整数大小不同：

为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：

现在，数组中每个数字都在 int16_t 的范围内，因此采用的编码方式是 INTSET_ENC_INT16 ，每部分占用的字节大小为：

• encoding：4字节
• length：4字节
• contents：2字节 * 3 =6字节

---

2.1 IntSet升级

假设有一个intset，元素为{5,10,20}，采用的编码是 INTSET_ENC_INT16 ，则每个整数占2个字节：

我们向其中添加一个数字：50000，这个数字超出了 int16_t 的范围，intset会自动升级编码方式到合适的大小。

以当前案例来说明流程：

1. 升级编码为 INTSET_ENC_INT32 ，每个整数占4字节，并按照新的编码方式及元素个数扩容数组
2. 倒序依次将数组中的元素拷贝到扩容后的正确位置
3. 将待添加的元素(50000) 这个数字放入数组末尾
4. 最后，将inset的encoding属性改为 INTSET_ENC_INT32,将length属性改为4

Inset可以看作是特殊的整数数组，具备一些特点：

1. Redis会确保Intset中的元素唯一、有序
2. 具备类型升级机制，可以节省内存空间
3. 底层采用二分查找方式来查询

---

3. Dict

Redis是一个键值型的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。

Dict由三部分组成，分别是：哈希表(DictHashTable) 、哈希节点(DictEntry)、字典(Dict)

当我们向Dict添加键值对时，Redis首先根据key计算出hash值，然后利用 h & sizemask 来计算元素应该存储到数组中的哪个索引位置。

假设哈希表长度为4，我们存储k1=v1，k1的哈希值h=1，那么 1&3=1，因此k1=v1要存储到数组角标1位

再次存储k2=v2，k2的哈希值h=1，那么k2也要存储到数组角标1位。使用头插法，避免遍历。

---

3.1 Dict的扩容

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，那么查询效率会大大降低。

Dict在每次新增键值对时都会检查负载因子(LoadFactor=user/size)，满足以下两种情况时会触发哈希表扩容：

1. 哈希表的 LoadFactor>=1 ,并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程
2. 哈希表的 LoadFactor>5

---

3.2 Dict的收缩

Dict除了扩容以外，每次删除元素时， 也会对负载因子做检查，当 LoadFactor<0.1 时，会做哈希表收缩：

---

3.3 Dict的rehash

不管扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为 rehash。

Dict的rehash并不是一次性完成的，如果Dict包含数百万的entry，要在一次rehash完成，极有可能导致主线程阻塞。因此Dict的rehash是分多次、渐进式的完成，因此称为 渐进式rehash。流程如下：

1. 计算新hash表的size，值取决于当前要做的是扩容还是收缩：
   • 如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
   • 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n（不得小于4）
2. 按照新的size申请内存空间，创建dictht，并赋值给dict.ht[1]
3. 设置dict.rehashindex=0，表示开始rehash
4. 每次执行增删改查操作时，都检查一下dict.rehashindex是否大于-1，如果是，则将dict.ht[0].table[rehashindex]的entry链表hash到dict.ht[1]，并且将rehashindex++，直至dict.ht[0]的所有数据都rehash到dict.ht[1]
5. 将dict.ht[1]赋值给dict.ht[0],给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
6. 将rehashindex赋值为-1，代表rehash结束
7. 在rehash过程中，新增操作，则直接写入ht[1]，查询、修改、删除则会在dict.ht[0]和dict.ht[1]依次查找并执行。这样可以确保ht[0]的数据只减不增，随着rehash进行，ht[0]最终为空。

---

4. ZipList

ZipList是一种特殊的“双端链表”，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作，并且该操作的时间复杂度为O(1)

属性	类型	长度	用途
zlbytes	uint32_t	4 字节	记录整个压缩列表占用的内存字节数
zltail	uint32_t	4 字节	记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。
zllen	uint16_t	2 字节	记录了压缩列表包含的节点数量。 最大值为UINT16_MAX （65534），如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。
entry	列表节点	不定	压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
zlend	uint8_t	1 字节	特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。

---

4.1 ZipList中的Entry

ZipList中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16字节，浪费内存。所以采用下面这种结构：

• previous_entry_length：表示前一节点的长度，占1个或5个字节
  • 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
  • 如果前一节点的长度大于254字节，则采用5个字节保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
• encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1、2或5个字节
• content：负责保存节点的数据，可以是字符串或整数

注意：ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：数值0x1234,采用小端字节序后实际存储值为：0x3412

---

4.1.1 Encoding编码

ZipListEntry中的encoding编码分为字符串和整数两种：

• 字符串：如果encoding是以“00”、“01”、或者“10”开头，则证明content是字符串

编码	编码长度	字符串大小
|00pppppp|	1 bytes	<= 63 bytes
|01pppppp|qqqqqqqq|	2 bytes	<= 16383 bytes
|10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt|	5 bytes	<= 4294967295 bytes

假设保存字符串“ab”，使用16进制表示：

保存字符串：”ab”和“bc”，完整表示如下：

---

• 整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节

编码	编码长度	整数类型
11000000	1	int16_t（2 bytes）
11010000	1	int32_t（4 bytes）
11100000	1	int64_t（8 bytes）
11110000	1	24位有符整数(3 bytes)
11111110	1	8位有符整数(1 bytes)
1111xxxx	1	直接在xxxx位置保存数值，范围从0001~1101，减1后结果为实际值

例如：一个ZipList中包含两个整数值：“2” 和 “5”

---

4.2 ZipList的连锁更新问题

ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：

• 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
• 如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，且第一个字节为0xfe，后四个字节才是真实长度数据

现在，假设我们有N个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用一个字节即可表示，如下图所示：

突然要插入一个长度为254字节的entry，采用头插法插入，那么原来第一个entry的previous_entry_length就变成了5，那么整体的entry长度就由原来的250变成了254字节，那么又导致原来的第二个entry的previous_entry_length变成了5…不断重复这个操作，直到遇到第一个长度<250的entry才结束。

ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁操作(Cascade Update)。新增、删除都可能导致连锁更新的发生。

---

4.3 特性

ZipList的特性：

1. 压缩列表可以看作一种连续内存空间的“双向链表”
2. 列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
3. 如果列表数据过多，导致链表过长，可能影响查询性能
4. 增或删较大数据有可能发生连续更新问题

---

5. QuickList