众所周知，Redis 是一个高性能的开源内存数据库，支持多种数据结构（如字符串、哈希、列表和集合），提供持久化选项以确保数据安全，并具备高可用性和分布式功能。

下面我们就来了解一下其底层所使用到的数据结构

一、SDS 

Redis 中保存的 key 是字符串，value 往往是字符串或者字符串的集合。

可见字符串是 Redis 中最常用的一种数据结构。

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

• 获取字符串长度的需要通过运算

• 非二进制安全

• 不可修改

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

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

// flags 的取值
#define SDS_TYPE_5 0
#define SDS_TYPE_8 1
#define SDS_TYPE_16 2
#define SDS_TYPE_32 3
#define SDS_TYPE_64 4

struct _srrtibute_((_packed_))sdshdr8{
    // Header
	unit8_t len;			// buf 已保存的字符串字节数，不包括结束标志
    unit8_t alloc;			// buf 申请的总字节数，不包含结束标志
    unsigned char flags;	// 不同 SDS 的头类型，用来控制 SDS 的头大小
    
    // 数据
    char buf[];
}

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

SDS 之所以叫做动态字符串，是因为它具备动态扩容的能力

例如，一个内容为“hi”的 SDS

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

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

如果新字符串大于1M，则新空间为扩展后字符串长度 + 1M，称为内存预分配

如果扩容后长度超过原有的 sdshdr 类型的长度，则会进行 s_realloc 扩容（使用更大的 sdshdr 类型）  

优点：

• 获取字符串长度的时间复杂度为 O（1）

• 支持动态扩容

• 减少内存分配次数

• 二进制安全

 

二、IntSet 

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

typedef struct intset{
	unit32_t encoding; 		// 编码方式，支持放 16 位、32 位、64 位整数
    unit32_t length;		// 元素个数
    int8_t contents[];		// 整数数组，保存集合数据
} intset;

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

/**
 * Note that these encodings are ordered, so:
 * INTSET ENC INT16 < INTSET ENC INT32 < INTSET ENC INT64.
 */
#define INTSET_ENC_INT16 (sizeof(int16 t);	// 2字节整数，范围类似 java 的 short
#define INTSET_ENC_INT32 (sizeof(int32 t));	// 4字节整数，范围类似 java 的 int
#define INTSET_ENC_INT64 (sizeof(int64 t));	// 8字节整数，范围类似 java 的 long

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

此时要计算一个数据的地址即可使用以下公式：

 

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

encoding：4字节

length：4字节

contents：2字节 * 3 = 6字节

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

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

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

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

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

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

 

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

• Redis 会确保 Intset 中的元素唯一、有序

• 具备类型升级机制，可以节省内存空间

• 底层采用二分查找方式来查询

三、Dict

 

Redis 是一个键值型（Key-Value Pair）的数据库，可以根据键实现快速的增删改查

而键与值的映射关系正是通过 Dict 来实现的

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

typedef struct dictht {
	// entry 数组，数组中保存的是指向 entry 的指针
	dictEntry **table;
	// 哈希表大小
	unsigned long size;
	// 哈希表大小的掩码，总等于 size-1
	unsigned long sizemask;
	// entry 的个数
	unsigned long used;
} dictht;

typedef struct dictEntry {
	// 键
    void *key;
    // 值
    union {
        void *val;
        unit64_t u64;
        int64_t s64;
        double d;
    } v;
    // 下一个 Entry 的指针
    struct dictEntry *next;
} dictEntry;

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

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

typedef struct dict {
	dictType *type;			// dict 类型，1内置不同的 hash 函数
    void *privdata;			// 私有数据，在做特殊 hash 运算时用
    dictht ht[2];			// 一个 dict 包含两个哈希表，一个保存数据，另一个一般是空的，只在 rehash 时使用
    long rehashidx;			// rehash 的进度，-1 表示未进行
    int16_t pauserehash;	// rehash 是否暂停，1 则暂停，0 则继续
} dict;

 

Dict 的扩容：

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

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

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

• 哈希表的 LoadFactor > 5 ；

 

【Dict 的 rehash】

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的 size 和 sizemask 变化，而 key 的查询与 sizemask 有关

因此必须对哈希表中的每一个 key 重新计算索引，插入新的哈希表，这个过程称为 rehash

过程是这样的：

• 计算新 hash 表的 realeSize，值取决于当前要做的是扩容还是收缩

  • 如果是扩容，则新 size 为第一个大于等于 dict.ht[0].used + 1 的 2n

  • 如果是收缩，则新 size 为第一个大于等于 dict.ht[0].used 的 2n （不得小于4）

• 按照新的 realeSize 申请内存空间，创建 dictht，并赋值给 dict.ht[1]

• 设置 dict.rehashidx = 0，标示开始 rehash

• 将 dict.ht[0] 中的每一个 dictEntry 都 rehash 到 dict.ht[1]

• 每次执行增删改查操作时，都检查一下 dict.rehashidx 是否大于 -1，若是则将 dict.ht[0].table[rehashidx] 的 entry 链表 rehash 到 dict.he[1]，并且将 rehashidx++，直到 dixt.ht[0] 的所有数据都 rehash 到 dict.ht[1]

• 将 dict.ht[1] 赋值给 dict.ht[0]，给 dict.ht[1] 初始化为空哈希表，释放原来的 dict.ht[0] 的内存

• 将 rehashidx 赋值为 -1，代表 rehash 结束

• 在 rehash 过程中，新增操作，则直接写入 ht[1]，查询、修改和删除则会在 dict.ht[0] 和 dict.ht[1] 依次查找并执行

  • 这样可以确保 ht[0] 的数据只减不增，随着 rehash 最终为空

 

Dict 的结构：

• 类似 Java 的 HashTable，底层是数组加链表来解决哈希冲突

• Dict 包含两个哈希表，ht[0] 平常用，ht[1] 用来 rehash

Dict 的伸缩：

• 当 LoadFactor 大于 5 或者 LoadFactor 大于 1 并且没有子进程任务时，Dict 扩容

• 当 LoadFactor 小于 0.1 时，Dict 收缩

• 扩容大小为第一个大于等于 used + 1 的 2n

• 收缩大小为第一个大于等于 used 的 2n

• Dict 采用渐进式 rehash，每次访问 Dict 时执行一次 rehash

• rehash 时 ht[0] 只减不增，新增操作只在 ht[1] 执行，其它操作在两个哈希表

 

四、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 ），用于标记压缩列表的末端。

 

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

• previous_entry_length：前一节点的长度，占1个或5个字节。

  • 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值

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

• encoding：编码属性，记录 content 的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节

• contents：负责保存节点的数据，可以是字符串或整数

ZipList 中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。

例如：数值 0x1234，采用小端字节序后实际存储值为：0x3412

 

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

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

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

 

【ZipList 的连锁更新问题】

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

如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值

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

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

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

 

ZipList特性：

• 压缩列表的可以看做一种连续内存空间的"双向链表"

• 列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低

• 如果列表数据过多，导致链表过长，可能影响查询性能

• 增或删较大数据时有可能发生连续更新问题

 

五、QuickList  

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

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

 

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

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

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

A：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：

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

typedef struct quicklist{
	// 头节点指针
    quicklistNode *head;
    // 尾节点指针
    quicklistNode *tail;
    // 所有 ziplist 的 entry 的数量
    unsigned long count;
    // ziplist 的数量
    unsigned long len;
    // ziplist 的 entry 的上限，默认值 -2
    int fill: QL_FILL_BITS;
    // 首尾不压缩的节点数量
    insigned int compress: QL_COMP_BITS;
    quicklistBookmark bookmarks[];
} quciklist;

typedef struct quicklistNode {
    // 前一个节点指针
    struct quicklistNode *prev;
    // 下一个节点指针
    struct quicklistNode *next;
    // 当前节点的 Ziplist 指针
    unsigned char *zl;
    // 当前节点的 Ziplist 的字节大小
    unsigned int sz;
    // 当前节点的 ZipList 的 entry 个数
    unsigned int count: 16;
    // 编码方式： 1，ZipList；2，lzf 压缩模式
    unsigned int encoding: 2;
    // 数据容器类型（预留）：1，其他；2：ZipList
    unsigned int container: 2;
    // 是否被解压缩：1，被解压了
    unsigned int recompress: 1;
    // 测试用
    unsigned int sttempted_compress: 1;
    // 预留字段
    unsigned int extra: 10;
} quicklistNode;

QuickList 的特点：

• 是一个节点为 ZipList 的双端链表

• 节点采用 ZipList，解决了传统链表的内存占用问题

• 控制了 ZipList 大小，解决连续内存空间申请效率问题

• 中间节点可以压缩，进一步节省了内存

 

六、SkipList  

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

• 元素按照升序排列存储

• 节点可能包含多个指针，指针跨度不同

typedef struct zskiplist{
    // 头尾节点指针
    struct szkiplistNode *header, *tail;
    // 节点数量
    unsigned long length;
    // 最大的索引层级，默认是 1
    int level;
} zskiplist;

typedef struct zskiplstNode {
    // 节点存储的值
    sds ele;
    // 节点分数，排序、查询用
    double score;
    // 前一个节点指针
    struct zskiplistNode *backword;
    struct zskiplistLevel {
        // 下一个节点指针
        struct zskiplistNode *forward;
        // 索引跨度
        unsigned long span;
    } level[];
} zskiplistNode;

SkipList 的特点：

• 跳跃表是一个双向链表，每个节点都包含 score 和 ele 值

• 节点按照 score 值排序，score 值一样则按照 ele 字典排序

• 每个节点都可以包含多层指针，层数是 1 到 32 之间的随机数

• 不同层指针到下一个节点的跨度不同，层级越高，跨度越大

• 增删改查效率与红黑树基本一致，实现却更简单

 

七、RedisObject

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

什么是 RedisObject？

---

从 Redis 的使用者的角度来看，⼀个 Redis 节点包含多个 database（非 cluster 模式下默认是 16 个，cluste r模式下只能是 1 个），而一个 database 维护了从 key space 到 object space 的映射关系  

这个映射关系的 key是 string 类型，⽽ value 可以是多种数据类型，比如：string, list, hash、set、sorted set 等

可以看到，key 的类型固定是 string，而 value 可能的类型是多个

⽽从 Redis 内部实现的⾓度来看，database 内的这个映射关系是用⼀个 dict 来维护的

dict 的 key 固定用⼀种数据结构来表达就够了，这就是动态字符串 sds

而 value 则比较复杂，为了在同⼀个 dict 内能够存储不同类型的 value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是 robj，全名是redisObject

 

一  叶  知  秋，奥  妙  玄  心