【Redis】Redis的数据结构

1. 动态字符串SDS

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

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

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

所以，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语言字符串的优点：

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

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会自动升级编码方式到合适的大小。

以当前案例来说明流程：

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

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

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

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)，满足以下两种情况时会触发哈希表扩容：

哈希表的 LoadFactor>=1 ,并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程
哈希表的 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。流程如下：

计算新hash表的size，值取决于当前要做的是扩容还是收缩：
- 如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
- 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n（不得小于4）
按照新的size申请内存空间，创建dictht，并赋值给dict.ht[1]
设置dict.rehashindex=0，表示开始rehash
每次执行增删改查操作时，都检查一下dict.rehashindex是否大于-1，如果是，则将dict.ht[0].table[rehashindex]的entry链表hash到dict.ht[1]，并且将rehashindex++，直至dict.ht[0]的所有数据都rehash到dict.ht[1]
将dict.ht[1]赋值给dict.ht[0],给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
将rehashindex赋值为-1，代表rehash结束
在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的特性：

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

5. QuickList

问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？

为了缓解这个问题，我们必须限制ZipList的长度和entry的大小

问题2：但是我们要存储大量数据，超出了ZipList最佳的上限怎么办？

我们可以创建多个ZipList来分片存储数据

问题3：数据拆分之后比较分散，不方便管理和查找，这多个ZipList如何建立联系?

Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

为了避免QuickList中的每个ZipList中的entry过多，Redis提供了一个配置项：list-max-ziplist-size 来限制entry个数。

如果这个值为正，则代表ZipList允许的entry个数的最大值
如果这个值为负，则代表ZipList的最大内存大小，分以下5中情况：
- -1：每个ZipList的内存占用不能超过4kb
- -2：每个ZipList的内存占用不能超过8kb
- -3：每个ZipList的内存占用不能超过16kb
- -4：每个ZipList的内存占用不能超过32kb
- -5：每个ZipList的内存占用不能超过64kb

而 list-max-ziplist-size 的默认值为：-2

除了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩。通过配置项 list-compress-depth 来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数是控制首尾不压缩的节点个数：

0：特殊值，表示不压缩
1：表示QuickList的首尾各有1个节点不压缩，中间节点压缩
2：表示QuickList的首尾各有2个节点不压缩，中间节点压缩
以此类推

list-compress-depth 默认值为：0

QuickList和QuickListNode的结构源码如下所示：

示意图如下：

5.1特点

QuickList的特点：

是一个节点为ZipList的双端链表
节点采用ZipList，解决了传统链表的内存占用问题
控制了ZipList大小，解决了连续内存空间申请效率问题
中间节点可以压缩，进一步节省了内存

6. SkipList

SkipList(跳表) 首先是链表，但与传统链表相比有几点差异：

元素按照升序排列存储
节点可能包含多个指针，指针跨度不同

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：

元素按照升序排列存储
节点可能包含多个指针，指针跨度不同

结构图如下：

6.1 特点

SkipList的特点：

跳表是一个双向链表，每个节点都包含score和ele(元素)值
节点按照score值排序，score值一样则按照ele字典排序
每个节点都可以包含多层指针，层数是1到32之间的随机数
不同层指针到下一个节点的跨度不同，层级越高，跨度越大
增删改查效率与红黑树一致，实现却更简单。

7. RedisObject

RedisObject中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

Redis会根据存储的数据类型不同，选择不同的编码方式，共包含11种不同类型：

编号	编码方式	说明
0	OBJ_ENCODING_RAW	raw编码动态字符串
1	OBJ_ENCODING_INT	long类型的整数的字符串
2	OBJ_ENCODING_HT	hash表（字典dict）
3	OBJ_ENCODING_ZIPMAP	已废弃
4	OBJ_ENCODING_LINKEDLIST	双端链表
5	OBJ_ENCODING_ZIPLIST	压缩列表
6	OBJ_ENCODING_INTSET	整数集合
7	OBJ_ENCODING_SKIPLIST	跳表
8	OBJ_ENCODING_EMBSTR	embstr的动态字符串
9	OBJ_ENCODING_QUICKLIST	快速列表
10	OBJ_ENCODING_STREAM	Stream流

Redis会根据存储的数据类型不同，选择不同的编码方式。每种数据类型使用的编码方式如下：

数据类型	编码方式
OBJ_STRING	int、embstr、raw
OBJ_LIST	LinkedList和ZipList(3.2以前)、QuickList（3.2以后）
OBJ_SET	intset、HT
OBJ_ZSET	ZipList、HT、SkipList
OBJ_HASH	ZipList、HT

8.五种基本数据类型

8.1 String

String是Redis中最常见的数据存储类型，它包含三种编码方式：

RAW
EMBSTR
INT

RAW编码：基于简单动态字符串(SDS)实现，存储上限为512mb。(需要调用两次内存分配函数)

EMBSTR编码：如果存储的SDS长度小于44，则会采用 EMBSTR 编码，此时object head与SDS是一对连续空间。申请内存时只需要调用一次内存分配函数，效率更高。

为什么以44字节为界限？

当sds长度为44时，整个redis对象加起来一共是64字节。redis底层会以2的n次方去做内存分配，而64刚好是一个分片大小，所以不会产生内存碎片

所以，采用String类型时，sds长度最好不要超过44字节。

INT编码：如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用 INT 编码，直接将数据保存在RedisObject的ptr指针位置(指针刚好是8字节)，不需要SDS了。

8.2 List

Redis的List结构类似于一个双端链表，可以从首、尾操作列表中的元素：

在3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。
在3.2版本之后，Redis统一采用QuickList来实现List。

8.3 Set

Set是Redis中的单列集合，满足以下特点：

不保证有序性
保证元素唯一(可以判断元素是否存在)
求交集，并集，差集

可以看出，Set对查询元素的效率要求非常高，在Redis中 Dict 数据结构可以满足，不过Dict是双列集合(可以存键又可以存值)。

Set是redis中的集合，不一定确保元素有序，可以满足元素唯一，查询效率要求极高。Set有以下两种编码方式：

HT编码:为了查询效率和唯一性，Set采用 HT编码(Dict)，Dict中的key用来存储元素，value统一为null。
IntSet编码：当存储的所有数据都是整数，并且元素数量不超过 set-max-intset-entries 时，Set会采用IntSet编码以节省内存。(set-max-intset-entries的默认值是512)

每次往Set集合中添加元素，就会判断元素的编码，如果原来一直都是IntSet编码，但是这个添加的元素不是整数，就要将全部的元素都转成HT编码。

流程如下：

①：当前Set集合的编码是Intset。

②：此时往Set集合中添加元素m1,sadd s1 m1 ,由于m1不是整数，所以Set集合的编码方式就改变了。

8.4 ZSet

ZSet也就是SortedSet，其中么一个元素都需要制定一个score值和member值：

可以根据score值排序
member必须唯一
可以根据member查询socre

因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。哪些编码结构可以满足？

SkipList：可以排序，并且可以同时存储score和ele值(member)
HT(Dict)：可以键值存储，并且可以根据key找value

当元素数量不多时，HT和SkipList的优势不明显，而且更耗内存。因此zset还会采用ZipList结构来节省内存，不过需要同时满足两个条件：

元素数量小于 zset_max_ziplist_entries ，默认值128个
每个元素都小于 zset_max_ziplist_value ，默认值64字节

由于ZipList本身没有排序功能，而且没有键值对的概念，所以需要有zset通过编码实现：

ZipList是连续内存，因此score和element是紧挨在一起的两个entry，element在前，score灾后
score越小越接近队首，score越大越接近队尾，按照score值升序排列

8.5 Hash

Hash结构与Redis中的Zset非常类似：

都是键值存储
都需要根据键获取值
键必须唯一

区别如下：

zset的键是member，值是score，hash的键和值都是任意值
zset要根据score排序，hash则无需排序

因此，Hash底层采用的编码与Zset基本一致，只需要把排序有关的SkipList去掉即可:

Hash结构默认采用ZipList编码，用以节省内存。ZipList中相邻的两个entry分别保存field和value
当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发的条件有两个：
1. ZipList中的元素数量超过了 hash-max-ziplist-entries （默认512个）
2. ZipList中的任意entry大小超过了 hash-max-ziplist-value （默认64字节）

当不满足上述两个条件时，Hash结构转为HT编码：