Redis原理篇 之数据结构

Redis原理篇 之数据结构

1 动态字符串SDS

1.1 SDS介绍

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

不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题：

• 获取字符串长度的需要通过运算
• 非二进制安全 以’\0’作为结束标志符，中间要是存储的字符串中也有’\0’ 则会误认为是结束标志
• 不可修改

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

例如，执行命令：

那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“虎哥”的SDS

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

• len：buf中实际保存的字符串字节数，比如hello 则len=5 不包含最后的’\0’
• alloc：初始化申请的字节数，比如 char buf[] = new char[5];初始化时alloc一般等于len，但是后面就不是了
• flag：数据类型，比如uint8_t的就是只能保存254个字符（第255个是’\0’），也可以选择uint5、16、32、64，储存不同当度的字符串。

所以前三个就是对字符数组信息的描述。

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

读的时候只需要从头直接读len个数据就行，不管中间有没有"\0"

1.2 SDS扩容

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

假如要给SDS追加一段字符串 “,Amy” 这里会申请新内存空间。

• 如果新字符串（“hi”+“,Amy”）小于1M，则新空间为扩展后字符串长度的两倍+1；

• 如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。

  以上进行了 内存预分配 。预分配可以减少内存分配次数，万一下次新追加的字符串没有超过范围，直接加进去，就不用再分配内存扩展了。

可以发现再新增了字符串后，alloc就和len不同了，alloc>len

1.3 SDS优点

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

2 IntSet

2.1 IntSet介绍

上节提到的SDS是用来保存单个字符串的， 但是很多情况下，需要保存的是多个数据形成的集合。所以在Redis中还提供了很多种不同的集合，比如IntSet。

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

结构如下：

• contents：存储整数数组的起始地址，本身并不存储数据
• encoding：表示每个存储整数数组中每个数的大小，分别有2、4、6个字节三种情况
• length：整数存储的个数

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

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

2.2 IntSet升级

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

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

以当前案例来说流程如下：

• 升级编码为INTSET ENC INT32，每个整数占4字节，并按照新的编码方式及元素个数扩容数组

• 倒序 依次将数组中的元素拷贝到扩容后的正确位置

• 将待添加的元素放入数组尾

• 最后，将inset的encoding属性改为INTSET_ENC_INT32，将length属性改为4

2.3 总结

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

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

Intset只适合保存少量数据，大量数据在查询 性能会下降。而且由于Intset申请的是连续的空间，当数据大时申请连续的大空间不方便

3 Dict

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

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

3.1 Dict的原理

哈希表(DictHashTable)、哈希节点(QictEntry)

• size：哈希表的大小，为2的n次方
• sizemase：size-1
• used：保存的entry数，由于哈希表的同一个位置可能有多个entry，所以used可能大于size

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

h&sizemask就等于h对size求余。

我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。

新来一个相同hash的entry

字典

Dict由哈希表来实现，哈希表其实就是数组加单向链表

3.2 Dict的扩容

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

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

• 哈希表的 LoadFactor >=1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程。

  之所以加后面的条件，是因为执行 BGSAVE 或者 BGREWRITEAOF时，会大量占用CPU的使用权，如果这时候再扩容，可能会让线程阻塞。

• 哈希表的 LoadFactor>5;

3.3 Dict的收缩

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

3.4 Dict的rehash

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

• 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
  • 如果是扩容，则新size为第一个大于等于dict.ht[0].used+1的2ⁿ
  • 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2”(不得小于4)
• 按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]
• 设置dict.rehashidx=0，标示开始rehash
• 将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
• 将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
  

现在又来一个新元素，LoadFactor > 1 进行rehash

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

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

3.5 总结

4 ZipList

Dict的最大缺点就是内存不是连续的，不得不通过指针去指向下一个地址，导致内存会存在一定的浪费，存在内存碎片。而且指针也要浪费大量的内存，一般一个指针8个字节，uint8。

4.1 ZipList原理

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

• 中间的entry就是全部的数据，整个存储空间都是连续的
• Zltail就可以快速定位到最后一个entry节点，又知道第一个entry节点，所以可以从任意一端进行压入/弹出
  

4.2 ZipListEntry

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

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

所以每个entry的长度可以用enry_length = previous_entry_length + encoding + encoding中保存的content长度 计算出来。要想计算前一节点起始地址，只需要用自己的起始地址减去previous_entry_length就可以得到了。

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

4.3 Encoding编码

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

字符串编码

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

例如，我们要保存字符串：“ab” 和 “bc”

• 第一个字符串“ab”

• 再加一个字符串"bc"

最后就是

整数编码

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

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

• 由于都在0001~1101内 所以直接省略了content，在encoding中直接储存整数值

• 最后就是

4.4 ZipList的连锁更新问题

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

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

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

现在来了一个大小为254字节的数据

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

4.5 总结

ZipList虽然相比Dict节省内存，但是其查询结构和单链表类似，只能从前往后或者从后往前，万一数量过多以及要查询的节点在中间，则性能不好。因此一般对ZipList只会存储少量数据。

5 QuickList

5.1 QuickList原理

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

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

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

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

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

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

• 为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来限制。
  • 如果值为正，则代表zipList的允许的entry个数的最大值
  • 如果值为负，则代表ZipList的最大内存大小，分5种情况:
    ① -1：每个ZipList的内存占用不能超过4kb
    ② -2：每个ZipList的内存占用不能超过8kb
    ③ -3：每个ZipList的内存占用不能超过16kb
    ④ -4：每个ZipList的内存占用不能超过32kb
    ⑤ -5：每个ZipList的内存占用不能超过64kb
    其默认值为 -2:

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

• 0：特殊值，代表不压缩

• 1：标示QuickList的首尾各有1个节点不压缩，中间节点压缩

• 2：标示QuickList的首尾各有2个节点不压缩，中间节点压缩

• 以此类推

  默认值：

以下是QuickList的和QuickListNode的结构源码：

5.2 QuickList总结

6 SkipList

前面已经学习了ZipList和QuickList两种列表，他们有个共同的特点就是非常节省内存，不过他们遍历的时候要么从头到尾遍历，要么从尾到头遍历，因此他们查找首尾的时候，性能还不错。但是如果要从中间随机去查询，性能就不行了。此时就需要SkipList了。

6.1 SkipList原理

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

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

6.2 总结

7 RedisObject

7.1 RedisObject原理

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

每个头信息就占了 4bit + 4bit + 24bit + 4字节 + 8字节 = 16字节，所以一个Redis对象的头信息就占16字节，还不包括指针指向的实际存放数据的空间。

• 假如现在有十个字符串
  • 每个字符串都是一个SDS对象的话，那么就会有十个redisObject，就多了16*10字节的头信息
  • 但是如果这十个字符串存成一个LIst放进去，一个list就是一个Redis对象，那么就只有16*1字节的头信息，其它都是真实的数据存储

所以String数据结构虽然是最简单的，但是每个str都是一个redis对象，需要花费16字节的头信息，就浪费了大量内存

因此一般有太多数据时，不推荐使用String，最好用集合的形式，就只要少数的头信息

7.2 Redis的编码方式

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

7.3 五种数据结构

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

HT就是哈希表。可以看到HT几乎和ZipList同时出现，因为这两个几乎相同，都是存储entry，只是存储方式不同，一个数组+单链表，一个列表形式。

• 但由于HT不能双端操作，所以List数据类型可以采用Ziplist，而没有采用HT。
• 但由于SET数据类型需要查询效率高，所以可以用HT，而没有使用ZipList

8 五种数据结构

8.1 String

string是Redis中最常见的数据存储类型：

• 其基本编码方式是 RAW ，基于简单动态字符串（SDS）实现，存储上限为512mb

上图编码方式是RAW，SDS与Object head是两个独立的空间。

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

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

总结：

8.2 List

Redis的List类型可以从首、尾操作列表中的元素：

哪一个数据结构能满足上述特征?

• LinkedList：普通链表，可以从双端访问，内存占用较高，内存碎片较多
• ZipList：压缩列表，可以从双端访问，内存占用低，存储上限低
• QuickList：LinkidList+ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高

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

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

8.3 Set

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

• 不保存有序性
• 保证元素唯一（可以判断元素是否存在）
• 求交集、并集、差集

可以看出，Set对查询元素的效率要求非常高，思考一下，什么样的数据结构可以满足?

hash和skipList都可以快速查询元素。但是skiplist不适合，移位skiplist是有序的，内部会进行排序，但是set集合是无须的，不需要做排序，排序反而影响了性能，而且set中存的元素不一定满足调表中的排序特性，无法进行排序。因此就选择

• HashTable，也就是Redis中的Dict，不过Dict是双列集合(可以存键、值对)

Set是Redis中的集合，不一定确保元素有序，可以满足元素唯一、查询效率要求极高。

• 为了查询效率和唯一性，set采用HT编码(Dict)。Dict中的 key用来存储元素，value统一为null

• 当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries时，Set会采用Intset编码，以节省内存。因为dict比较消耗内存

  数据是升序排的，可以二分查找，查询效率高。且当查找到相同元素存在时，就不会再添加进去了，满足了唯一性、查询效率高、且是数组储存，内存是连续的

突然插入一个字符串

新建一个dict，然后把所有元素作为key值 存入到entry中，value统一是null

最后把指针指向dict

8.4 Zset

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

• 可以根据score值排序后
• member必须唯一
• 可以根据member查询分数

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

• SkipList： 可以排序，并且可以同时存储score和ele值（member）。但是不方便根据member值差score，只能一个一个查，这样效率就低了，优势都没了
• HT （Dict）： 可以键值存储，并且可以根据key找value。把key当做member score当做value。但是排序不好说

第一种实现方式：

Zset底层是结合了两种编码方式，但是写只写的是SkipList编码方式

• 其中dict用于根据member找score
• skiplist用于排序，范围查找

第二种实现方式：

当元素数量不多时，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，触发条件有两个:

  • ZipList中的元素数量超过了hash-max-ziplist-entries(默认512)
  • ZipList中的任意entry大小超过了hash-max-ziplist-value(默认64字节)