0%

Redis 设计与实现-数据结构

发表于 更新于 分类于 ， 阅读次数： Valine：
本文字数： 5.7k 阅读时长 ≈ 5 分钟

1. 前言

Redis 数据库里面的每个键值对 (key-value pair) 都是由对象 (object) 组成的, 其中:

  • 数据库键总是一个字符串对象 (string object);
  • 而数据库键的值则可以是字符串对象、列表对象 (list object)、哈希对象 (hash object)、集合对象 (set object)、有序集合对象 (sorted set object) 这五种对象中的其中一种。

比如说, 执行以下命令将在数据库中创建一个键为字符串对象, 值也为字符串对象的键值对:

1
2
redis> SET msg "helloworld"
OK

Redis 的五种不同类型的对象底层至少采用两种以上不同的数据结构实现。本文将削析这些对象所使用的底层数据结构。

2. 简单动态字符串

Redis 没有直接使用 C 语言传统的字符串表示 (以空字符结尾的字符数组, 以下简称 C 字符串), 而是自己构建了一种名为简单动态字符串 (simple dynamic string, SDS) 的抽象类型, 并将SDS 用作 Redis 的默认字符串表示。

2.1 SDS 的定义

2.2 SDS 与 C 字符串的区别

2.2.1 常数复杂度获取字符串长度

因为 C 字符串并不记录自身的长度信息, 所以为了获取一个 C 字符串的长度, 程序必须遍历整个字符串, 对遇到的每个字符进行计数, 直到遇到代表字符串结尾的空字符为止, 这个操作的复杂度为O(N)。

对于的 SDS 来说, 程序只要访问 SDS 的 len 属性就可以立即知道 SDS 的长度。

2.2.2 杜绝缓冲区溢出

除了获取字符串长度的复杂度高之外, C 字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出 (bufferoverflow)；与 C 字符串不同, SDS 的空间分配策略完全杜绝了发生缓冲区滥出的可能性: 当 SDS API 需要对 SDS 进行修改时, API 会先检查 SDS 的空间是否满足修改所需的要求, 如果不满足的话, API 会自动将 SDS 的空间扩展至执行修改所需的大小, 然后才执行实际的修改操作, 所以使用 SDS 既不需要手动修改 SDS 的空间大小, 也不会出现前面所说的缓冲区溢出问题。

2.2.3 减少修改字符串时带来的内存重分配次数

正如前面所说, 因为 C 字符串并不记录自身的长度, 所以对于一个包含了 N 个字符的 C 字符串来说, 这个 C 字符串的底层实现总是一个 N+1 个字符长的数组 (额外的一个字符空间用于保存空字符)。因为 C 字符串的长度和底层数组的长度之间存在着这种关联性, 所以每次增长或者缩短一个 C 字符串, 程序都总要对保存这个 C 字符串的数组进行一次内存重分配操作。

为了避免 C 字符串的这种缺陷, SDS 通过未使用空间解除了字符串长度和底层数组长度之间的关联: 在 SDS 中, buf 数组的长度不一定就是字符数量加一, 数组里面可以包含未使用的字节,而这些字节的数量就由 SDS 的 free 属性记录。

通过未使用空间, SDS 实现了空间预分配和惰性空间释放两种优化策略。

2.2.3.1 空间预分配

空间预分配用于优化 SDS 的字符串增长操作: 当 SDS 的 API 对一个 SDS 进行修改, 并且需要对 SDS 进行空间扩展的时候, 程序不仅会为 SDS 分配修改所必须要的空间, 还会
为 SDS 分配额外的未使用空间。

2.2.3.2 惰性空间释放

惰性空间释放用于优化 SDS 的字符串缩短操作: 当 SDS 的 API 需要缩短 SDS 保存的字符串时, 程序并不立即使用内存重分配来回收缩短后多出来的字节, 而是使用 free 属性将这些字节的数量记录起来, 并等待将来使用。

注意执行 sdstrim 之后的 SDS 并设有释放多出来的 8 字节空间, 而是将这 8 字节作为未使用空间保留在了 SDS 里面。

2.2.4 二进制安全

C 字符串中的字符必须符合某种编码 (比如 ASCII), 并且除了字符串的末尾之外, 字符串里面不能包含空字符, 否则最先被程序读人的空字符将被误认为是字符串结尾, 这些限制使得 C 字符串只能保存文本数据, 而不能保存像图片、音频、视频、压缩文件这样的二进制数据。

为了确保 Redis 可以适用于各种不同的使用场景, SDS 的 API 都是二进制安全的 (binary-safe), 所有 SDS API 都会以处理二进制的方式来处理 SDS 存放在 buf 数组里的数据,程序不会对其中的数据做任何限制、过滤、或者假设, 数据在写人时是什么样的, 它被读取时就是什么样。

2.2.5 兼容部分 C 字符串函数

SDS 遵循 C 字符串以空字符结尾的惯例, SDS 可以在有需要时重用 <string.h> 函数库, 从而避免了不必要的代码重复。

3. 链表

链表提供了高效的节点重排能力, 以及顺序性的节点访问方式,并且可以通过增删节点来灵活地调整链表的长度。作为一种常用数据结构,链表内置在很多高级的编程语言里面, 因为 Redis 使用的 C 语言并没有内置这种数据结构,所以 Redis 构建了自己的链表实现。

链表在 Redis 中的应用非常广泛, 比如列表键的底层实现之一就是链表。当一个列表键包含了数量比较多的元素, 又或者列表中包含的元素都是比较长的字符串时, Redis 就会使用链表作为列表键的底层实现。

3.1 链表和链表节点的实现

List 结构为链表提供了表头指针 head、表尾指针 tail, 以及链表长度计数器 len, 而dup、free和match成员则是用于实现多态链表所需的类型特定函数:

  • dup函数用于复制链表节点所保存的值;

  • free函数用于释放链表节点所保存的值;

  • match函数则用于对比链表节点所保存的值和另一个输入值是否相等。

4. 字典

字典,又称为符号表(symbol table)、关联数组(associative array)或映射(map),是一种用于保存键值对(key-value pair)的抽象数据结构。

在字典中,一个键(key)可以和一个值(value)进行关联(或者说将键映射为值), 这些关联的键和值就称为键值对。

字典中的每个键都是独一无二的,程序可以在字典中根据键查找与之关联的值,或者通过键来更新值,又或者根据键来删除整个键值对,等等。

4.1 字典的实现

Redis的字典使用哈希表作为底层实现,一个哈希表里面可以有多个哈希表节点,而每个哈希表节点就保存了字典中的一个键值对。

4.1.1 哈希表

table属性是一个数组,数组中的每个元素都是一个指向dict.h/dictEntry结构的指针,每个dictEntry结构保存着一个键值对。size属性记录了哈希表的大小,也即是table数组的大小,而used属性则记录了哈希表目前已有节点(键值对)的数量。sizemark属性的值总是等于size - 1,这个属性和哈希值一起决定一个键应该被放到table数组的哪个索引上面。

图4-1展示了一个大小为4的空哈希表(没有包含任何键值对)。

4.1.2 哈希表节点

4.1.3 字典

ht 属性是一个包含两个项的数组,数组中的每个项都是一个dictht哈希表,一般情况下,字典只使用ht[0]哈希表,ht[1]哈希表只会在对ht[0]哈希表进行rehash（重哈希，渐进式分多次执行）时使用。

除了ht[1]之外,另一个和rehash有关的属性就是rehashidx,它记录了rehash目前的进度,如果目前没有在进行rehash,那么它的值为-1。

4.2 哈希算法

当要将一个新的键值对添加到字典里面时,程序需要先根据键值对的键计算出哈希值和索引值,然后再根据索引值,将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

当字典被用作数据库的底层实现,或者哈希键的底层实现时,Redis使用MurmurHash2算法来计算键的哈希值。

5. 跳跃表

跳跃表(skiplist)是一种有序数据结构,它通过在每个节点中维持多个指向其他节点的指针,从而达到快速访问节点的目的。Redis使用跳跃表作为有序集合键的底层实现之一,如果一个有序集合包含的元素数量比较多,又或者有序集合中元素的成员(member)是比较长的字符串时,Redis就会使用跳跃表来作为有序集合键的底层实现。

5.1 跳跃表的实现

Redis的跳跃表由redis.h/zskiplistNode和redis.h/zskiplist两个结构定义,其中zskiplistNode结构用于表示跳既表节点,而zskiplist 结构用于保存跳跃表节点的相关信息,比如节点的数量,以及指向表头节点和表尾节点的指针等等。

image-20220313135509765

图5-1展示了一个跳跃表示例,位于图片最左边的是zskiplist结构,该结构包含以下属性:

  • header: 指向跳跃表的表头节点。

  • tail: 指向跳跃表的表尾节点。

  • level: 记录目前跳跃表内,层数最大的那个节点的层数(表头节点的层数不计算在内)。

  • length:记录跳跃表的长度,也即,跳跃表目前包含节点的数量(表头节点不计算在内)。

位于zskiplist结构右方的是四个zskiplistNode结构,该结构包含以下属性:

  • 层(level): 节点中用L1、L2、L3等字样标记节点的各个层,L1代表第一层,L2代表第二层,以此类推。每个层都带有两个属性:前进指针和跨度。前进指针用于访问位于表尾方向的其他节点,而跨度则记录了前进指针所指向节点和当前节点的距离。在上面的图片中,连线上带有数字的箭头就代表前进指针,而那个数字就是跨度。当程序从表头向表尾进行遍历时,访问会沿着层的前进指针进行。

  • 后退(backward)指针: 节点中用BW字样标记节点的后退指针, 它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。

  • 分值(score):各个节点中的1.0、2.0和3.0是节点所保存的分值。在跳跃表中,节点按各自所保存的分值从小到大排列。

  • 成员对象(obj):各个节点中的o1、o2和o3是节点所保存的成员对象。

注意表头节点和其他节点的构造是一样的: 表头节点也有后退指针、分值和成员对象,不过表头节点的这些属性都不会被用到,所以图中省略了这些部分,只显示了表头节点的各个层。

5.1.1 跳跃表节点

5.1.2 跳跃表

仅靠多个跳跃表节点就可以组成一个跳跃表,如图5-8所示。但通过使用一个zskiplist结构来持有这些节点,程序可以更方便地对整个跳跃表进行处理,比如快速访问跳跃表的表头节点和表尾节点,或者快速地获取跳跃表节点的数量 (也即是跳跃表的长度)等信息,如图5-9所示。

6. 整数集合

整数集合(intset)是集合键的底层实现之一,当一个集合只包含整数值元素,并且这个集合的元素数量不多时,Redis就会使用整数集合作为集合键的底层实现。

举个例子,如果我们创建一个只包含五个元素的集合键,并且集合中的所有元素都是整数值,那么这个集合键的底层实现就会是整数集合:

1
2
3
4
redis> SADD numbers 1 2 3 5 7 9
(integer) 5
redis> OBJECT ENCODING numbers
"intset"

6. 1 整数集合的实现

7. 压缩列表

压缩列表(ziplist)是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做列表键的底层实现。

7.1 压缩列表的构成

压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构。一个压缩列表可以包含任意多个节点(entry),每个节点可以
保存一个字节数组或者一个整数值。图7-1展示了压缩列表的各个组成部分,表7-1则记录了各个组成部分的类型、长度以及用途。

图7-2展示了一个压缩列表示例:

  • 列表zlbytes属性的值为0x50(十进制80),表示压缩列表的总长为80字节。

  • 列表zltail属性的值为0x3c(十进制60),这表示如果我们有一个指向压缩列表起始地址的指针p,那么只要用指针p加上偏移量60,就可以计算出表尾节点entry3的地址。

  • 列表zllen属性的值为0x3(十进制3),表示压缩列表包含三个节点。

7.1 压缩列表节点的构成

每个压缩列表节点都由previous_entry_length、encoding、content三个部分组成,如图7-4所示。

接下来的内容将分别介绍这三个组成部分。

  • previous_entry_length: 节点的previous_entry_length属性以字节为单位,记录了压缩列表中前一个节
    点的长度。因为节点的previous_entry_length属性记录了前一个节点的长度,所以程序可以通过指针运算,根据当前节点的起始地址来计算出前一个节点的起始地址。

  • encoding：节点的encoding属性记录了节点的content属性所保存数据的类型以及长度。

    • 一字节、两字节或者五字节长,值的最高位为00、01或者10的是字节数组编码：这种编码表示节点的content属性保存着字节数组,数组的长度由编码除去最高两
      位之后的其他位记录;
    • 一字节长,值的最高位以11开头的是整数编码：这种编码表示节点的content属性保存着整数值,整数值的类型和长度由编码除去最高两位之后的其他位记录;

  • content：节点的content属性负责保存节点的值,节点值可以是一个字节数组或者整数,值的类型和长度由节点的encoding属性决定。
    图7-9展示了一个保存字节数组的节点示例:

    • 编码的最高位 00 表示节点保存的是一个字节数组；

    • 编码的后六位 001011 记录了自己数组的长度 11；

  • content 属性保存着节点的值 “hello world”。

------ 本文结束------