《redis设计与实现》

目录

• 一、数据结构与对象
  • 1. 引言
    • 1.1 版本说明
    • 1.2 章节编排
  • 2. 简单动态字符串
    • 2.1 SDS 的定义
    • 2.2 SDS 与 C 字符串的区别
  • 3. 链表
    • 3.1 链表和链表节点的实现
  • 4. 字典
    • 4.1 字典的实现
    • 4.2 哈希算法
    • 4.3 解决键冲突
    • 4.4 rehash
    • 4.5 渐进式rehash
  • 5. 跳跃表
    • 5.1 跳跃表的实现
  • 6. 整数集合
    • 6.1 整数集合的实现
    • 6.2 升级
    • 6.3 升级的好处
    • 6.4 降级
  • 7. 压缩列表
    • 7.2 压缩列表的构成
    • 7.2 压缩列表节点的构成
  • 8. 对象
    • 8.1 对象的类型与编码
    • 8.2 字符串对象
    • 8.3 列表对象
    • 8.4 哈希对象
    • 8.5 集合对象
    • 8.6 有序集合对象
• 二、单机数据库的实现
  • 1. 数据库
  • 2. RDB持久化
  • 3. AOF持久化
  • 4. 事件
  • 5. 客户端
  • 6. 服务端
• 三、多机数据库的实现
  • 1. 复制
  • 2. Sentinel
  • 3. 集群
• 四、独立功能的实现
  • 1. 发布与订阅
  • 2. 事务
  • 3. Lua脚本
  • 4. 排序
  • 5. 二进制位数组
  • 6. 慢查询日志
  • 7. 监视器

 

一、数据结构与对象

1. 引言

1.1 版本说明

本书是基于 Redis 2.9 —— 也即是 Redis 3.0 的开发版来编写的， 因为 Redis 3.0 的更新主要与 Redis 的多机功能有关， 而 Redis 3.0 的单机功能则与 Redis 2.6 、Redis 2.8 的单机功能基本相同， 所以本书的内容对于使用 Redis 2.6 至 Redis 3.0 的读者来说应该都是有用的。

另外， 因为 Redis 通常都是渐进地增加新功能， 并且很少会大幅地修改已有的功能， 所以本书的大部分内容对于 Redis 3.0 之后的几个版本来说， 应该也是有用的。

1.2 章节编排

本书由《数据结构与对象》、《单机数据库的实现》、《多机数据库的实现》、《独立功能的实现》四个部分组成。

第一部分

Redis 数据库里面的每个键值对（key-value pair）都是由对象（object）组成的：

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

本书的第一部分 —— 也即是《数据结构与对象》部分， 将对以上提到的五种不同类型的对象进行介绍， 剖析这些对象所使用的底层数据结构， 并说明这些数据结构是如何深刻地影响对象的功能和性能的。

第二部分

本书的第二部分 —— 也即是《单机数据库的实现》部分， 对 Redis 实现单机数据库的方法进行了介绍。

《数据库》一章对 Redis 数据库的实现原理进行了介绍： 说明了服务器保存键值对的方法， 服务器保存键值对过期时间的方法， 以及服务器自动删除过期键值对的方法， 等等。

《RDB 持久化》和《AOF 持久化》两章分别介绍了 Redis 两种不同的持久化方式的实现原理： 说明了服务器根据数据库来生成持久化文件的方法， 服务器根据持久化文件来还原数据库的方法， 以及 BGSAVE 命令和 BGREWRITEAOF 命令的实现原理， 等等。

《事件》一章对 Redis 的文件事件和时间事件进行了介绍：

• 文件事件主要用于应答（accept）客户端的连接请求， 接收客户端发送的命令请求， 以及向客户端返回命令回复；
• 而时间事件则主要用于执行 redis.c/serverCron 函数 —— 这个函数通过执行常规的维护和管理操作来保持 Redis 服务器的正常运作， 一些重要的定时操作也是由这个函数负责触发的。

《客户端》一章对 Redis 服务器维护和管理客户端状态的方法进行了介绍： 列举了客户端状态包含的各个属性， 说明了客户端的输入缓冲区和输出缓冲区的实现方法， 以及 Redis 服务器创建和销毁客户端状态的条件， 等等。

《服务器》一章对单机 Redis 服务器的运作机制进行了介绍： 详细地说明了服务器处理命令请求的步骤， 解释了 serverCron 函数所做的工作， 并讲解了 Redis 服务器的初始化过程。

第三部分

本书的第三部分 —— 也即是《多机数据库的实现》部分， 对 Redis 的 Sentinel 、复制（replication）、集群（cluster）三个多机功能进行了介绍。

《Sentinel》一章对 Redis Sentinel 的实现原理进行了介绍： 说明了 Sentinel 监视服务器的方法， Sentinel 判断服务器是否下线的方法， 以及 Sentinel 对下线服务器进行故障转移的方法， 等等。

《复制》一章对 Redis 的主从复制功能（master-slave replication）的实现原理进行了介绍： 说明了当用户指定一个服务器（从服务器）去复制另一个服务器（主服务器）时， 主从服务器之间执行了什么操作， 进行了什么数据交互， 诸如此类。

《集群》一章对 Redis 集群的实现原理进行了介绍： 说明了节点（node）的构建方法， 节点处理命令请求的方法， 转发（redirection）错误的实现方法， 以及各个节点之间进行通讯的方法， 等等。

第四部分

本书的第四部分 —— 也即是《独立功能的实现》部分， 对 Redis 中各个相对独立的功能模块进行了介绍。

《发布与订阅》一章对 PUBLISH 、 SUBSCRIBE 、 PUBSUB 等命令的实现原理进行了介绍， 解释了 Redis 的发布与订阅功能是如何实现的。

《事务》一章对 MULTI 、 EXEC 、 WATCH 等命令的实现原理进行了介绍， 解释了 Redis 的事务是如何实现的， 并说明了 Redis 的事务对 ACID 性质的支持程度。

《Lua 脚本》一章对 EVAL 、 EVALSHA 、 SCRIPT_LOAD 等命令的实现原理进行了介绍， 解释了 Redis 服务器是如何执行和管理用户传入的 Lua 脚本的； 这一章还对 Redis 服务器构建 Lua 环境的过程， 以及主从服务器之间复制 Lua 脚本的方法进行了介绍。

《排序》一章对 SORT 命令、 以及 SORT 命令所有可用选项（比如 DESC 、 ALPHA 、 GET，等等）的实现原理进行了介绍， 并说明了当 SORT 命令带有多个选项时， 不同选项执行的先后顺序。

《二进制位数组》一章对 Redis 保存二进制位数组的方法进行了介绍， 并说明了 GETBIT 、 SETBIT 、 BITCOUNT 、 BITOP 这几个二进制位数组操作命令的实现原理。

《慢查询日志》一章对 Redis 创建和保存慢查询日志（slow log）的方法进行了介绍， 并说明了 SLOWLOG GET 、 SLOWLOG LEN 、 SLOWLOG RESET 等慢查询日志操作命令的实现原理。

《监视器》一章介绍了将客户端变为监视器（monitor）的方法， 以及服务器在处理命令请求时， 向监视器发送命令信息的方法。

2. 简单动态字符串

2.1 SDS 的定义

每个 sds.h/sdshdr 结构表示一个 SDS 值：

struct sdshdr {

    // 记录 buf 数组中已使用字节的数量
    // 等于 SDS 所保存字符串的长度
    int len;

    // 记录 buf 数组中未使用字节的数量
    int free;

    // 字节数组，用于保存字符串
    char buf[];

};

图 2-1 展示了一个 SDS 示例：

• free 属性的值为 0，表示这个 SDS 没有分配任何未使用空间。
• len 属性的值为 5，表示这个 SDS 保存了一个五字节长的字符串。
• buf 属性是一个 char 类型的数组，数组的前五个字节分别保存了 'R'、'e'、'd'、'i'、's' 五个字符，而最后一个字节则保存了空字符 ''。

遵循空字符结尾这一惯例的好处是，SDS 可以直接重用一部分 C 字符串函数库里面的函数。

2.2 SDS 与 C 字符串的区别

C 字符串	SDS
获取字符串长度的复杂度为 O(N)。	获取字符串长度的复杂度为 O(1)。
API 是不安全的，可能会造成缓冲区溢出。	API 是安全的，不会造成缓冲区溢出。
修改字符串长度 N 次必然需要执行 N 次内存重分配。	修改字符串长度 N 次最多需要执行 N 次内存重分配。
只能保存文本数据。	可以保存文本或者二进制数据。
可以使用所有 <string.h> 库中的函数。	可以使用一部分 <string.h> 库中的函数。

3. 链表

3.1 链表和链表节点的实现

链表节点

每个链表节点使用一个 adlist.h/listNode 结构来表示：

typedef struct listNode {

    // 前置节点
    struct listNode *prev;

    // 后置节点
    struct listNode *next;

    // 节点的值
    void *value;

} listNode;

多个 listNode 可以通过 prev 和 next 指针组成双端链表，如图 3-1 所示。

链表

虽然仅仅使用多个 listNode 结构就可以组成链表，但使用 adlist.h/list 来持有链表的话，操作起来会更方便：

typedef struct list {

    // 表头节点
    listNode *head;

    // 表尾节点
    listNode *tail;

    // 链表所包含的节点数量
    unsigned long len;

    // 节点值复制函数
    void *(*dup)(void *ptr);

    // 节点值释放函数
    void (*free)(void *ptr);

    // 节点值对比函数
    int (*match)(void *ptr, void *key);

} list;

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

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

图 3-2 是由一个 list 结构和三个 listNode 结构组成的链表：

链表特性

Redis 的链表实现的特性可以总结如下：

• 双端： 链表节点带有 prev 和 next 指针，获取某个节点的前置节点和后置节点的复杂度都是 O(1)。
• 无环： 表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL，对链表的访问以 NULL 为终点。
• 带表头指针和表尾指针： 通过 list 结构的 head 指针和 tail 指针，程序获取链表的表头节点和表尾节点的复杂度为 O(1)。
• 带链表长度计数器： 程序使用 list 结构的 len 属性来对 list 持有的链表节点进行计数，程序获取链表中节点数量的复杂度为 O(1)。
• 多态： 链表节点使用 void* 指针来保存节点值，并且可以通过 list 结构的 dup 、 free 、 match 三个属性为节点值设置类型特定函数，所以链表可以用于保存各种不同类型的值。

4. 字典

4.1 字典的实现

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

哈希表

Redis 字典所使用的哈希表由 dict.h/dictht 结构定义：

typedef struct dictht {

    // 哈希表数组
    dictEntry **table;

    // 哈希表大小
    unsigned long size;

    // 哈希表大小掩码，用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;

    // 该哈希表已有节点的数量
    unsigned long used;

} dictht;

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

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

哈希表节点

哈希表节点使用 dictEntry 结构表示，每个 dictEntry 结构都保存着一个键值对：

typedef struct dictEntry {

    // 键
    void *key;

    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;

    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;

} dictEntry;

• key 属性保存着键值对中的键，而 v 属性则保存着键值对中的值，其中键值对的值可以是一个指针，或者是一个 uint64_t 整数，又或者是一个 int64_t 整数。
• next 属性是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一次，以此来解决键冲突（collision）的问题。

图 4-2 就展示了如何通过 next 指针，将两个索引值相同的键 k1 和 k0 连接在一起。

字典

Redis 中的字典由 dict.h/dict 结构表示：

typedef struct dict {

    // 类型特定函数
    dictType *type;

    // 私有数据
    void *privdata;

    // 哈希表
    dictht ht[2];

    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */

} dict;

type 属性和 privdata 属性是针对不同类型的键值对，为创建多态字典而设置的：

• type 属性是一个指向 dictType 结构的指针，每个 dictType 结构保存了一簇用于操作特定类型键值对的函数，Redis 会为用途不同的字典设置不同的类型特定函数。
• privdata 属性则保存了需要传给那些类型特定函数的可选参数。
• ht 属性是一个包含两个项的数组，数组中的每个项都是一个 dictht 哈希表，一般情况下，字典只使用 ht[0] 哈希表，ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。
• rehashidx 属性记录了 rehash 目前的进度，如果目前没有在进行 rehash，那么它的值为 -1。

图 4-3 展示了一个普通状态下（没有进行 rehash）的字典：

4.2 哈希算法

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

Redis 计算哈希值和索引值的方法如下：

# 使用字典设置的哈希函数，计算键 key 的哈希值
hash = dict->type->hashFunction(key);

# 使用哈希表的 sizemask 属性和哈希值，计算出索引值
# 根据情况不同，ht[x] 可以是 ht[0] 或者 ht[1]
index = hash & dict->ht[x].sizemask;

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

MurmurHash 算法最初由 Austin Appleby 于 2008 年发明，这种算法的优点在于，即使输入的键是有规律的，算法仍能给出一个很好的随机分布性，并且算法的计算速度也非常快。

MurmurHash 算法目前的最新版本为 MurmurHash3，而 Redis 使用的是 MurmurHash2，关于 MurmurHash 算法的更多信息可以参考该算法的主页： http://code.google.com/p/smhasher/。

4.3 解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时，我们称这些键发生了冲突（collision）。

Redis 的哈希表使用链地址法（separate chaining）来解决键冲突： 每个哈希表节点都有一个 next 指针，多个哈希表节点可以用 next 指针构成一个单向链表，被分配到同一个索引上的多个节点可以用这个单向链表连接起来，这就解决了键冲突的问题。

因为 dictEntry 节点组成的链表没有指向链表表尾的指针，所以为了速度考虑，程序总是将新节点添加到链表的表头位置（复杂度为 O(1)），排在其他已有节点的前面。

4.4 rehash

随着操作的不断执行，哈希表保存的键值对会逐渐地增多或者减少，为了让哈希表的负载因子（load factor）维持在一个合理的范围之内，当哈希表保存的键值对数量太多或者太少时，程序需要对哈希表的大小进行相应的扩展或者收缩。

扩展和收缩哈希表的工作可以通过执行 rehash （重新散列）操作来完成，Redis 对字典的哈希表执行 rehash 的步骤如下：

1. 为字典的 ht[1] 哈希表分配空间，这个哈希表的空间大小取决于要执行的操作，以及 ht[0] 当前包含的键值对数量 （也即是 ht[0].used 属性的值）：
   • 如果执行的是扩展操作，那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的 2^n （2 的 n 次方幂）；
   • 如果执行的是收缩操作，那么 ht[1] 的大小为第一个大于等于 ht[0].used 的 2^n。
2. 将保存在 ht[0] 中的所有键值对 rehash 到 ht[1] 上面： rehash 指的是重新计算键的哈希值和索引值，然后将键值对放置到 ht[1] 哈希表的指定位置上。
3. 当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后 （ht[0] 变为空表），释放 ht[0]，将 ht[1] 设置为 ht[0]，并在 ht[1] 新创建一个空白哈希表，为下一次 rehash 做准备。

哈希表的扩展与收缩

当以下条件中的任意一个被满足时，程序会自动开始对哈希表执行扩展操作：

服务器目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 1 ；
服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 5 ；
其中哈希表的负载因子可以通过公式：

# 负载因子 = 哈希表已保存节点数量 / 哈希表大小
load_factor = ht[0].used / ht[0].size

根据 BGSAVE 命令或 BGREWRITEAOF 命令是否正在执行，服务器执行扩展操作所需的负载因子并不相同，这是因为在执行 BGSAVE 命令或 BGREWRITEAOF 命令的过程中，Redis 需要创建当前服务器进程的子进程，而大多数操作系统都采用写时复制（copy-on-write）技术来优化子进程的使用效率，所以在子进程存在期间，服务器会提高执行扩展操作所需的负载因子，从而尽可能地避免在子进程存在期间进行哈希表扩展操作，这可以避免不必要的内存写入操作，最大限度地节约内存。

另一方面，当哈希表的负载因子小于 0.1 时，程序自动开始对哈希表执行收缩操作。

4.5 渐进式rehash

上一节说过，扩展或收缩哈希表需要将 ht[0] 里面的所有键值对 rehash 到 ht[1] 里面，但是，这个 rehash 动作并不是一次性、集中式地完成的，而是分多次、渐进式地完成的。

这样做的原因在于，如果 ht[0] 里只保存着四个键值对，那么服务器可以在瞬间就将这些键值对全部 rehash 到 ht[1] ； 但是，如果哈希表里保存的键值对数量不是四个，而是四百万、四千万甚至四亿个键值对，那么要一次性将这些键值对全部 rehash 到 ht[1] 的话，庞大的计算量可能会导致服务器在一段时间内停止服务。

以下是哈希表渐进式 rehash 的详细步骤：

1. 为 ht[1] 分配空间，让字典同时持有 ht[0] 和 ht[1] 两个哈希表。
2. 在字典中维持一个索引计数器变量 rehashidx，并将它的值设置为 0，表示 rehash 工作正式开始。
3. 在 rehash 进行期间，每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1]，当 rehash 工作完成之后，程序将 rehashidx 属性的值增一。
4. 随着字典操作的不断执行，最终在某个时间点上，ht[0] 的所有键值对都会被 rehash 至 ht[1]，这时程序将 rehashidx 属性的值设为 -1，表示 rehash 操作已完成。

渐进式 rehash 的好处在于它采取分而治之的方式，将 rehash 键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上，从而避免了集中式 rehash 而带来的庞大计算量。

渐进式 rehash 执行期间的哈希表操作

因为在进行渐进式 rehash 的过程中，字典会同时使用 ht[0] 和 ht[1] 两个哈希表，所以在渐进式 rehash 进行期间，字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行： 比如说，要在字典里面查找一个键的话，程序会先在 ht[0] 里面进行查找，如果没找到的话，就会继续到 ht[1] 里面进行查找，诸如此类。

另外，在渐进式 rehash 执行期间，新添加到字典的键值对一律会被保存到 ht[1] 里面，而 ht[0] 则不再进行任何添加操作： 这一措施保证了 ht[0] 包含的键值对数量会只减不增，并随着 rehash 操作的执行而最终变成空表。

5. 跳跃表

5.1 跳跃表的实现

图 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 是节点所保存的成员对象。

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

跳跃表节点

跳跃表节点的实现由 redis.h/zskiplistNode 结构定义：

typedef struct zskiplistNode {

    // 后退指针
    struct zskiplistNode *backward;

    // 分值
    double score;

    // 成员对象
    robj *obj;

    // 层
    struct zskiplistLevel {

        // 前进指针
        struct zskiplistNode *forward;

        // 跨度
        unsigned int span;

    } level[];

} zskiplistNode;

1.层
跳跃表节点的 level 数组可以包含多个元素，每个元素都包含一个指向其他节点的指针，程序可以通过这些层来加快访问其他节点的速度，一般来说，层的数量越多，访问其他节点的速度就越快。

每次创建一个新跳跃表节点的时候，程序都根据幂次定律 （power law，越大的数出现的概率越小） 随机生成一个介于 1 和 32 之间的值作为 level 数组的大小，这个大小就是层的“高度”。

2.前进指针
每个层都有一个指向表尾方向的前进指针（level[i].forward 属性），用于从表头向表尾方向访问节点。

3.跨度
层的跨度（level[i].span 属性）用于记录两个节点之间的距离：

• 两个节点之间的跨度越大，它们相距得就越远。
• 指向 NULL 的所有前进指针的跨度都为 0，因为它们没有连向任何节点。
  初看上去，很容易以为跨度和遍历操作有关，但实际上并不是这样 —— 遍历操作只使用前进指针就可以完成了，跨度实际上是用来计算排位（rank）的： 在查找某个节点的过程中，将沿途访问过的所有层的跨度累计起来，得到的结果就是目标节点在跳跃表中的排位。

4.后退指针
节点的后退指针（backward 属性）用于从表尾向表头方向访问节点： 跟可以一次跳过多个节点的前进指针不同，因为每个节点只有一个后退指针，所以每次只能后退至前一个节点。

5.分值和成员
节点的分值（score 属性）是一个 double 类型的浮点数，跳跃表中的所有节点都按分值从小到大来排序。

节点的成员对象（obj 属性）是一个指针，它指向一个字符串对象，而字符串对象则保存着一个 SDS 值。

在同一个跳跃表中，各个节点保存的成员对象必须是唯一的，但是多个节点保存的分值却可以是相同的： 分值相同的节点将按照成员对象在字典序中的大小来进行排序，成员对象较小的节点会排在前面（靠近表头的方向），而成员对象较大的节点则会排在后面（靠近表尾的方向）。

跳跃表

通过使用一个 zskiplist 结构来持有这些节点，程序可以更方便地对整个跳跃表进行处理，比如快速访问跳跃表的表头节点和表尾节点，又或者快速地获取跳跃表节点的数量（也即是跳跃表的长度）等信息。

zskiplist 结构的定义如下：

typedef struct zskiplist {

    // 表头节点和表尾节点
    struct zskiplistNode *header, *tail;

    // 表中节点的数量
    unsigned long length;

    // 表中层数最大的节点的层数
    int level;

} zskiplist;

header 和 tail 指针分别指向跳跃表的表头和表尾节点，通过这两个指针，程序定位表头节点和表尾节点的复杂度为 O(1)。

通过使用 length 属性来记录节点的数量，程序可以在 O(1) 复杂度内返回跳跃表的长度。

level 属性则用于在 O(1) 复杂度内获取跳跃表中层高最大的那个节点的层数量，注意表头节点的层高并不计算在内。

6. 整数集合

6.1 整数集合的实现

整数集合（intset）是 Redis 用于保存整数值的集合抽象数据结构，它可以保存类型为 int16_t 、 int32_t 或者 int64_t 的整数值，并且保证集合中不会出现重复元素。

每个 intset.h/intset 结构表示一个整数集合：

typedef struct intset {

    // 编码方式
    uint32_t encoding;

    // 集合包含的元素数量
    uint32_t length;

    // 保存元素的数组
    int8_t contents[];

} intset;

contents 数组是整数集合的底层实现： 整数集合的每个元素都是 contents 数组的一个数组项（item），各个项在数组中按值的大小从小到大有序地排列，并且数组中不包含任何重复项。

length 属性记录了整数集合包含的元素数量，也即是 contents 数组的长度。

虽然 intset 结构将 contents 属性声明为 int8_t 类型的数组，但实际上 contents 数组并不保存任何 int8_t 类型的值 —— contents 数组的真正类型取决于 encoding 属性的值：

• 如果 encoding 属性的值为 INTSET_ENC_INT16，那么 contents 就是一个 int16_t 类型的数组，数组里的每个项都是一个 int16_t 类型的整数值 （最小值为 -32,768，最大值为 32,767 ）。
• 如果 encoding 属性的值为 INTSET_ENC_INT32，那么 contents 就是一个 int32_t 类型的数组，数组里的每个项都是一个 int32_t 类型的整数值 （最小值为 -2,147,483,648，最大值为 2,147,483,647 ）。
• 如果 encoding 属性的值为 INTSET_ENC_INT64，那么 contents 就是一个 int64_t 类型的数组，数组里的每个项都是一个 int64_t 类型的整数值 （最小值为 -9,223,372,036,854,775,808，最大值为 9,223,372,036,854,775,807 ）。

6.2 升级

每当我们要将一个新元素添加到整数集合里面，并且新元素的类型比整数集合现有所有元素的类型都要长时，整数集合需要先进行升级（upgrade），然后才能将新元素添加到整数集合里面。

升级整数集合并添加新元素共分为三步进行：

1. 根据新元素的类型，扩展整数集合底层数组的空间大小，并为新元素分配空间。
2. 将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素放置到正确的位上，而且在放置元素的过程中，需要继续维持底层数组的有序性质不变。
3. 将新元素添加到底层数组里面。

举个例子，假设现在有一个 INTSET_ENC_INT16 编码的整数集合，集合中包含三个 int16_t 类型的元素，如图 6-3 所示。

因为每次向整数集合添加新元素都可能会引起升级，而每次升级都需要对底层数组中已有的所有元素进行类型转换，所以向整数集合添加新元素的时间复杂度为 O(N)。

6.3 升级的好处

整数集合的升级策略有两个好处，一个是提升整数集合的灵活性，另一个是尽可能地节约内存。

提升灵活性

因为 C 语言是静态类型语言，为了避免类型错误，我们通常不会将两种不同类型的值放在同一个数据结构里面。

比如说，我们一般只使用 int16_t 类型的数组来保存 int16_t 类型的值，只使用 int32_t 类型的数组来保存 int32_t 类型的值，诸如此类。

但是，因为整数集合可以通过自动升级底层数组来适应新元素，所以我们可以随意地将 int16_t 、 int32_t 或者 int64_t 类型的整数添加到集合中，而不必担心出现类型错误，这种做法非常灵活。

节约内存

当然，要让一个数组可以同时保存 int16_t 、 int32_t 、 int64_t 三种类型的值，最简单的做法就是直接使用 int64_t 类型的数组作为整数集合的底层实现。 不过这样一来，即使添加到整数集合里面的都是 int16_t 类型或者 int32_t 类型的值，数组都需要使用 int64_t 类型的空间去保存它们，从而出现浪费内存的情况。

而整数集合现在的做法既可以让集合能同时保存三种不同类型的值，又可以确保升级操作只会在有需要的时候进行，这可以尽量节省内存。

比如说，如果我们一直只向整数集合添加 int16_t 类型的值，那么整数集合的底层实现就会一直是 int16_t 类型的数组，只有在我们要将 int32_t 类型或者 int64_t 类型的值添加到集合时，程序才会对数组进行升级。

6.4 降级

整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态。

7. 压缩列表

7.2 压缩列表的构成

压缩列表是 Redis 为了节约内存而开发的，由一系列特殊编码的连续内存块组成的顺序型（sequential）数据结构。

一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。

图 7-1 展示了压缩列表的各个组成部分，表 7-1 则记录了各个组成部分的类型、长度、以及用途。

属性	类型	长度	用途
zlbytes	uint32_t	4 字节	记录整个压缩列表占用的内存字节数：在对压缩列表进行内存重分配，或者计算 zlend 的位置时使用。
zltail	uint32_t	4 字节	记录压缩列表表尾节点距离压缩列表的起始地址有多少字节： 通过这个偏移量，程序无须遍历整个压缩列表就可以确定表尾节点的地址。
zllen	uint16_t	2 字节	记录了压缩列表包含的节点数量： 当这个属性的值小于 UINT16_MAX （65535）时，这个属性的值就是压缩列表包含节点的数量； 当这个值等于 UINT16_MAX 时，节点的真实数量需要遍历整个压缩列表才能计算得出。
entryX	列表节点	不定	压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
zlend	uint8_t	1 字节	特殊值 0xFF（十进制 255 ），用于标记压缩列表的末端。

7.2 压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值，其中，字节数组可以是以下三种长度的其中一种：

1. 长度小于等于 63 （2^{6}-1）字节的字节数组；
2. 长度小于等于 16383 （2^{14}-1） 字节的字节数组；
3. 长度小于等于 4294967295 （2^{32}-1）字节的字节数组；

而整数值则可以是以下六种长度的其中一种：

1. 4 位长，介于 0 至 12 之间的无符号整数；
2. 1 字节长的有符号整数；
3. 3 字节长的有符号整数；
4. int16_t 类型整数；
5. int32_t 类型整数；
6. int64_t 类型整数。

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

previous_entry_length

节点的 previous_entry_length 属性以字节为单位，记录了压缩列表中前一个节点的长度。
previous_entry_length 属性的长度可以是 1 字节或者 5 字节：

• 如果前一节点的长度小于 254 字节，那么 previous_entry_length 属性的长度为 1 字节： 前一节点的长度就保存在这一个字节里面。
• 如果前一节点的长度大于等于 254 字节，那么 previous_entry_length 属性的长度为 5 字节： 其中属性的第一字节会被设置为 0xFE （十进制值 254），而之后的四个字节则用于保存前一节点的长度。

encoding

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

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

表 7-2 字节数组编码

编码	编码长度	content属性保存的值
00xxxxxx	1 字节	长度小于等于 63 字节的字节数组。
01xxxxxx	2 字节	长度小于等于 16383 字节的字节数组。
10xxxxxx	5 字节	长度小于等于 4294967295 的字节数组。

表 7-3 整数编码

编码	编码长度	content属性保存的值
11000000	1 字节	int16_t 类型的整数。
11010000	1 字节	int32_t 类型的整数。
11100000	1 字节	int64_t 类型的整数。
11110000	1 字节	24 位有符号整数。
11111110	1 字节	8 位有符号整数。
1111xxxx	1 字节	没有相应的 content 属性，因为编码本身的 xxxx 四个位已经保存了一个介于 0 和 12 之间的值。

content

节点的 content 属性负责保存节点的值，节点值可以是一个字节数组或者整数，值的类型和长度由节点的 encoding 属性决定。

8. 对象

Redis 并没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，这个系统包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象这五种类型的对象，每种对象都用到了至少一种我们前面所介绍的数据结构。

通过这五种不同类型的对象，Redis 可以在执行命令之前，根据对象的类型来判断一个对象是否可以执行给定的命令。 使用对象的另一个好处是，我们可以针对不同的使用场景，为对象设置多种不同的数据结构实现，从而优化对象在不同场景下的使用效率。

除此之外，Redis 的对象系统还实现了基于引用计数技术的内存回收机制： 当程序不再使用某个对象的时候，这个对象所占用的内存就会被自动释放； 另外，Redis 还通过引用计数技术实现了对象共享机制，这一机制可以在适当的条件下，通过让多个数据库键共享同一个对象来节约内存。

最后，Redis 的对象带有访问时间记录信息，该信息可以用于计算数据库键的空转时长，在服务器启用了 maxmemory 功能的情况下，空转时长较大的那些键可能会优先被服务器删除。

8.1 对象的类型与编码

Redis 使用对象来表示数据库中的键和值， 每次当我们在 Redis 的数据库中新创建一个键值对时， 我们至少会创建两个对象， 一个对象用作键值对的键（键对象）， 另一个对象用作键值对的值（值对象）。

类型

对象	type 属性值	TYPE 命令的输出
字符串对象	REDIS_STRING	"string"
列表读写	REDIS_LIST	"list"
哈希对象	REDIS_HASH	"hash"
集合对象	REDIS_SET	"set"
有序集合对象	REDIS_ZSET	"zset"

当我们对一个数据库键执行 TYPE 命令时， 命令返回的结果为数据库键对应的值对象的类型， 而不是键对象的类型：

# 键为字符串对象，值为字符串对象
redis> SET msg "hello world"
OK
redis> TYPE msg
string

# 键为字符串对象，值为列表对象
redis> RPUSH numbers 1 3 5
(integer) 6
redis> TYPE numbers
list

# 键为字符串对象，值为哈希对象
redis> HMSET profile name Tome age 25 career Programmer
OK
redis> TYPE profile
hash

# 键为字符串对象，值为集合对象
redis> SADD fruits apple banana cherry
(integer) 3
redis> TYPE fruits
set

# 键为字符串对象，值为有序集合对象
redis> ZADD price 8.5 apple 5.0 banana 6.0 cherry
(integer) 3
redis> TYPE price
zset

编码

数据结构	编码常量	OBJECT ENCODING 命令输出
整数	REDIS_ENCODING_INT	"int"
embstr SDS	REDIS_ENCODING_EMBSTR	"embstr"
raw SDS	REDIS_ENCODING_RAW	"raw"
字典	REDIS_ENCODING_HT	"hashtable"
双端链表	REDIS_ENCODING_LINKEDLIST	"linkedlist"
压缩列表	REDIS_ENCODING_ZIPLIST	"ziplist"
整数集合	REDIS_ENCODING_INTSET	"intset"
跳跃表和字典	REDIS_ENCODING_SKIPLIST	"skiplist"

使用 OBJECT ENCODING 命令可以查看一个数据库键的值对象的编码。

redis> SET msg "hello wrold"
OK
redis> OBJECT ENCODING msg
"embstr"

redis> SET story "long long long long long long ago ..."
OK
redis> OBJECT ENCODING story
"raw"

redis> SADD numbers 1 3 5
(integer) 3
redis> OBJECT ENCODING numbers
"intset"

redis> SADD numbers "seven"
(integer) 1
redis> OBJECT ENCODING numbers
"hashtable"

通过 encoding 属性来设定对象所使用的编码，而不是为特定类型的对象关联一种固定的编码，极大地提升了 Redis 的灵活性和效率，因为 Redis 可以根据不同的使用场景来为一个对象设置不同的编码，从而优化对象在某一场景下的效率。

8.2 字符串对象

字符串对象的编码可以是 int 、 raw 或者 embstr。

如果一个字符串对象保存的是整数值，并且这个整数值可以用 long 类型来表示，那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long ），并将字符串对象的编码设置为 int。

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于 32 字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为 raw。

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度小于等于 32字节，那么字符串对象将使用 embstr 编码的方式来保存这个字符串值。

编码转换

int 编码的字符串对象和 embstr 编码的字符串对象在条件满足的情况下。会被转换为 raw 编码的字符串对象。

（1）对于 int 编码的字符串对象来说，如果我们向对象执行了一些命令，使得这个对象保存的不再是整数值，而是一个字符串值，那么字符串对象的编码将从 int 变为 raw。

（2）另外，因为 Redis 没有为 embstr 编码的字符串对象编写任何相应的修改程序 （只有 int 编码的字符串对象和 raw 编码的字符串对象有这些程序），所以 embstr 编码的字符串对象实际上是只读的： 当我们对 embstr 编码的字符串对象执行任何修改命令时，程序会先将对象的编码从 embstr 转换成 raw，然后再执行修改命令； 因为这个原因，embstr 编码的字符串对象在执行修改命令之后，总会变成一个 raw 编码的字符串对象。

8.3 列表对象

列表对象的编码可以是 ziplist 或者 linkedlist。

ziplist 编码的列表对象使用压缩列表作为底层实现， 每个压缩列表节点（entry）保存了一个列表元素。

linkedlist 编码的列表对象使用双端链表作为底层实现， 每个双端链表节点（node）都保存了一个字符串对象， 而每个字符串对象都保存了一个列表元素。

redis> RPUSH numbers 1 "three" 5
(integer) 3

编码转换

当列表对象可以同时满足以下两个条件时， 列表对象使用 ziplist 编码：

1. 列表对象保存的所有字符串元素的长度都小于 64 字节；
2. 列表对象保存的元素数量小于 512 个；

不能满足这两个条件的列表对象需要使用 linkedlist 编码。

8.4 哈希对象

哈希对象的编码可以是 ziplist 或者 hashtable。

ziplist 编码的哈希对象使用压缩列表作为底层实现， 每当有新的键值对要加入到哈希对象时， 程序会先将保存了键的压缩列表节点推入到压缩列表表尾， 然后再将保存了值的压缩列表节点推入到压缩列表表尾， 因此：

1. 保存了同一键值对的两个节点总是紧挨在一起， 保存键的节点在前， 保存值的节点在后；
2. 先添加到哈希对象中的键值对会被放在压缩列表的表头方向， 而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。

redis> HSET profile name "Tom"
(integer) 1

redis> HSET profile age 25
(integer) 1

redis> HSET profile career "Programmer"
(integer) 1

另一方面， hashtable 编码的哈希对象使用字典作为底层实现， 哈希对象中的每个键值对都使用一个字典键值对来保存：

1. 字典的每个键都是一个字符串对象， 对象中保存了键值对的键；
2. 字典的每个值都是一个字符串对象， 对象中保存了键值对的值。

编码转换

当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码：

1. 哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节；
2. 哈希对象保存的键值对数量小于 512 个；

不能满足这两个条件的哈希对象需要使用 hashtable 编码。

8.5 集合对象

集合对象的编码可以是 intset 或者 hashtable。

intset 编码的集合对象使用整数集合作为底层实现， 集合对象包含的所有元素都被保存在整数集合里面。

举个例子， 以下代码将创建一个如图 8-12 所示的 intset 编码集合对象：

redis> SADD numbers 1 3 5
(integer) 3

hashtable 编码的集合对象使用字典作为底层实现， 字典的每个键都是一个字符串对象， 每个字符串对象包含了一个集合元素， 而字典的值则全部被设置为 NULL。

举个例子， 以下代码将创建一个如图 8-13 所示的 hashtable 编码集合对象：

redis> SADD fruits "apple" "banana" "cherry"
(integer) 3

编码转换

当集合对象可以同时满足以下两个条件时， 对象使用 intset 编码：

1. 集合对象保存的所有元素都是整数值；
2. 集合对象保存的元素数量不超过 512 个；

不能满足这两个条件的集合对象需要使用 hashtable 编码。

8.6 有序集合对象

有序集合的编码可以是 ziplist 或者 skiplist。

ziplist 编码的有序集合对象使用压缩列表作为底层实现， 每个集合元素使用两个紧挨在一起的压缩列表节点来保存， 第一个节点保存元素的成员（member）， 而第二个元素则保存元素的分值（score）。

压缩列表内的集合元素按分值从小到大进行排序， 分值较小的元素被放置在靠近表头的方向， 而分值较大的元素则被放置在靠近表尾的方向。

举个例子， 如果我们执行以下 ZADD 命令， 那么服务器将创建一个有序集合对象作为 price 键的值：

redis> ZADD price 8.5 apple 5.0 banana 6.0 cherry
(integer) 3

如果 price 键的值对象使用的是 ziplist 编码， 那么这个值对象将会是图 8-14 所示的样子， 而对象所使用的压缩列表则会是 8-15 所示的样子。

skiplist 编码的有序集合对象使用 zset 结构作为底层实现， 一个 zset 结构同时包含一个字典和一个跳跃表：

typedef struct zset {
    zskiplist *zsl;
    dict *dict;
} zset;

zset 结构中的 zsl 跳跃表按分值从小到大保存了所有集合元素， 每个跳跃表节点都保存了一个集合元素： 跳跃表节点的 object 属性保存了元素的成员， 而跳跃表节点的 score 属性则保存了元素的分值。 通过这个跳跃表， 程序可以对有序集合进行范围型操作， 比如 ZRANK 、 ZRANGE 等命令就是基于跳跃表 API 来实现的。

除此之外， zset 结构中的 dict 字典为有序集合创建了一个从成员到分值的映射， 字典中的每个键值对都保存了一个集合元素： 字典的键保存了元素的成员， 而字典的值则保存了元素的分值。 通过这个字典， 程序可以用 O(1) 复杂度查找给定成员的分值， ZSCORE 命令就是根据这一特性实现的， 而很多其他有序集合命令都在实现的内部用到了这一特性。

有序集合每个元素的成员都是一个字符串对象， 而每个元素的分值都是一个 double 类型的浮点数。 值得一提的是， 虽然 zset 结构同时使用跳跃表和字典来保存有序集合元素， 但这两种数据结构都会通过指针来共享相同元素的成员和分值， 所以同时使用跳跃表和字典来保存集合元素不会产生任何重复成员或者分值， 也不会因此而浪费额外的内存。

举个例子， 如果前面 price 键创建的不是 ziplist 编码的有序集合对象， 而是 skiplist 编码的有序集合对象， 那么这个有序集合对象将会是图 8-16 所示的样子， 而对象所使用的 zset 结构将会是图 8-17 所示的样子。

编码转换

当有序集合对象可以同时满足以下两个条件时， 对象使用 ziplist 编码：

• 有序集合保存的元素数量小于 128 个；
• 有序集合保存的所有元素成员的长度都小于 64 字节；

不能满足以上两个条件的有序集合对象将使用 skiplist 编码。

 

二、单机数据库的实现

1. 数据库

2. RDB持久化

3. AOF持久化

4. 事件

5. 客户端

6. 服务端

 

三、多机数据库的实现

1. 复制

2. Sentinel

3. 集群

 

四、独立功能的实现

1. 发布与订阅

2. 事务

3. Lua脚本

4. 排序

5. 二进制位数组

6. 慢查询日志

7. 监视器