Redis学习笔记

发布日期: 2024-03-23

更新日期: 2024-04-20

文章字数: 13.7k

阅读时长: 48 分

阅读次数:

概述

首先，学习一个项目最好的方法就是看文档，redis文档里面就介绍了怎么直接通过加apt源的方式便捷安装(类似之前的llvm镜像源)，本文章主要介绍redis的基础知识，但同时就像简介上说的，重点在于怎么用好怎么设计而不是死扣细节知识，不过凡事都要讲究一个先后顺序，不积跬步无以至千里。

1. 简单动态字符串

在大多数情况下，Redis 使用 SDS（Simple Dynamic String，简单动态字符串）作为字符串表示

1.1 SDS 的结构体定义

struct sdshdr {
    // 记录 buf 数组中已使用字节的数量
    // 等于 SDS 所保存字符串的长度
    int len;
    // 记录 buf 数组中未使用字节的数量
    int free;
    // 字节数组，用于保存字符串，会自动在数组末尾添加一个字节，用于保存'\0'，不计入 len 值中
    char buf[];
}

1.2 SDS 相对于 C 字符串的优点

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

Redis 将获取字符串长度所需的复杂度从 O(N) 降低到了 O(1)，这确保了获取字符串长度的工作不会成为 Redis 的性能瓶颈

杜绝缓冲区溢出
减少修改字符串时带来的内存重分配次数

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

二进制安全

为了确保 Redis 可以适用于各种不同的适用场景，SDS 的 API 都是二进制安全的，因此使得 Redis 不仅可以保存文本数据，还可以保存任意格式的二进制数据，因为 SDS 使用 len 属性的值而不是空字符来判断字符串是否结束

兼容部分C字符串函数

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

2. 链表

链表被广泛用于实现 Redis 的各种功能，比如列表键、发布与订阅、慢查询、监视器等

Redis 的链表是由一个 list 结构和 n 个 listNode 结构组成，list 里面可以存储该链表的头指针、尾指针、以及长度计数器和用于实现多态链表所需的类型特定函数，Redis 的链表是双端、无环的

// 每个链表节点使用一个 adlist.h/listNode
typedef struct listNode {
    // 前置节点
    struct listNode * prev;
    struct listNode * next;
    // 节点的值
    void * value;
}listNode;
// 虽然仅仅使用多个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;

3. 字典

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

3.1 哈希表

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

typedef struct dicht {
    // 哈希表数组
    dictEntry **table;
    // 哈希表大小
    unsigned long size;
    // 哈希表大小掩码，用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;
    // 该哈希表已有节点的数量
    unsigned long used;
}dictht;

3.2 哈希表节点

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

typedef struct dictEntry {
    // 键
    void *key;
    // 值
    union {
        void *val;
        uint64_tu64;
        int64_ts64;
    } v;
    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;
}dictEntry;

3.3 字典

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

typedef struct dict {
    // 类型特定函数
    dictType *type;
    // 私有数据
    void *privdata;
    // 哈希表
    dictht ht[2];
    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int trehashidx;
} dict;

3.4 普通状态下的字典

3.5 哈希算法

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

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

// 使用字典设置的哈希函数，计算键key的哈希值
hash = dict -> type -> hashFunction(key);
// 使用哈希表的sizemask属性和哈希值，计算出索引值
// 根据情况不同，ht[x]可以是ht[0]或者ht[1]
index = hash & dict -> ht[x].sizemask;

Redis 使用 MurmurHash2 算法来计算键的哈希值

3.6 解决键冲突

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

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

3.7 rehash

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

Redis 对字典的哈希表执行 rehash 的步骤如下：

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

3.8 执行扩展或收缩操作的条件

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

服务目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 1 。
服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 5 。

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

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

但是，为了避免 rehash 对服务器性能造成影响，服务器不是一次性将 ht[0] 里面的所有键值对全部 rehash 到 ht[1] ，而是分多次、渐进式地将 ht[0] 里面的键值对慢慢地 rehash 到 ht[1]。

其方法是通过在字典中维护一个索引计数器变量 rehashidx，当 rehashidx 为 0 时，表示 rehash 工作正式开始，在 rehash 工作期间，每次对字典执行增删改查操作，都会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1]，rehash 完成之后，rehashidx 自增一，最终在某个时间点 ht[0] 上所有键值对都会被 rehash 至 ht[1] ，这时程序将 rehashidx 属性值设为 1，表示 rehash 操作已完成。

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

4. 跳跃表

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。跳跃表支持平均 O(logN) 、最坏 O(N) 度的节点查找，还可以通过顺序性操作来批量处理节点。Redis 只在两个地方用到了跳跃表，一个是实现有序集合键，另一个是在集群节点中用作内部数据结构。

4.1 跳跃表的实现

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

4.2 跳跃表节点

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

typedef struct zskiplistNode {
    // 层
    struct zskiplistLevel {
        // 前进指针
        struct zskiplistNode *forward;
        // 跨度
        unsigned int span;
    } level[];
    // 后退指针
    struct zskiplistNode *backward;
    // 分值
    double score;
    // 成员变量
    robj *obj;
} zskiplistNode;

5. 整数集合

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

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

typedef struct intset {
    // 编码方式
    uint32_t encoding;
    // 集合中包含的元素数量
    uint32_t length;
    // 保存元素的数组
    int8_t contents[];
} intset;

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

5.1 升级

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

5.2 升级的好处

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

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

6. 压缩列表

压缩列表（ziplist）是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么 Redis 就会使用压缩列表来做列表键的底层实现。
压缩列表是 Redis 为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的 顺序型（sequential）数据结构。一个压缩列表可以包含任意 多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。
添加新节点到压缩列表，或者从压缩列表中删除节点，可能会引发连锁更新操作，但这种操作出现的几率并不高。

7. 对象

前面已经介绍了 Redis 用到的所有主要数据结构，比如简单动态字符串（SDS）、双端链表、字典、压缩列表、整数集合等等。
Redis 并没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，这个系统包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象这五种类型的对象，每种对象都用到了至少一种我们前面所介绍的数据结构。
通过这五种不同类型的对象，Redis 可以在执行命令之前，根据对象的类型来判断一个对象是否可以执行给定的命令。使用对象的另一个好处是，我们可以针对不同的使用场景，为对象设置多种不同的数据结构实现，从而优化对象在不同场景下的使用效率。
除此之外，Redis 的对象系统还实现了基于引用计数技术的内存回收机制以及对象共享机制，Redis 对象还带有访问时间记录信息，可以用于计算数据库键的空转时长等等。

7.1 对象的类型与编码

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

Redis 中每个对象都由一个 redisObject 结构表示

typedef struct redisObject {
    // 类型
    unsigned type:4;
    // 编码
    unsigned encoding:4;
    // 指向底层实现数据结构的指针
    void *ptr;
    // 引用计数
    int refcount;
    // 对象最后一次被命令程序访问的时间
    unsigned lru:22;
} robj;

7.1.1 类型

对象的 type 属性记录了对象的类型，其值可以是字符串对象、列表对象、哈希对象、集合对象、有序集合对象。

对于 Redis 数据库保存的键值对来说，键总是一个字符串对象，而值则可以是其他类型对象中的一种，因此：

当我们称呼一个数据库键为 “字符串键” 时，我们指的是 “这个数据库键所对应的值为字符串对象”；
当我们称呼一个键为 “列表键” 时，我们指的是 “这个数据库键所对应的值为列表对象” 。

TYPE 命令的实现方式也与此类似，当我们对一个数据库键执行 TYPE 命令时，命令返回的结果为数据库键对应的值对象的类型，而不是键对象的类型。

7.1.2 编码和底层实现

对象的 ptr 指针指向对象的底层实现数据结构，而这些数据结构由对象的 encoding 属性决定。

encoding 属性记录了对象所使用的编码，也即是说这个对象使用了什么数据结构作为对象的底层实现。

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

7.2 字符串对象

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

如果一个字符串对象保存的是整数值，并且这个整数值可以用 long 类型来表示，那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long），并将字符串对象的编码设置为 int 。
如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于 32 字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为 raw 。
如果字符串对象保存的是一个字符串值，并且这个字符串值的长度小于等于 32 字节，那么字符串对象将使用 embstr 编码的方式来保存这个字符串值。

raw 与 embstr 的区别是：raw 编码会调用两次内存分配函数来分别创建 redisObject 结构和 sdshdr 结构，而 embstr 编码则通过一次内存分配函数来分配一块连续的空间，空间中依次包含 redisObject 和 sdshdr 两个结构。
最后，long double 类型表示的浮点数在 Redis 中也是作为字符串值来保存的，保存时会先将浮点数转换成字符串值，然后再保存所得字符串值。

7.2.1 编码的转换

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

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

7.3 列表对象

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

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

7.3.1 编码转换

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

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

不能满足这两个条件的列表对象需要使用 linkedlist 编码。注意这两个条件的上限值是可以修改的。

7.4 哈希对象

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

使用 ziplist 编码的哈希对象有以下特点：

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

使用 hashtable 编码的哈希对象有以下特点：

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

7.4.1 编码转换

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

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

这两个条件的上限值也是可以修改的，不满足条件的哈希对象需要使用 hashtable 编码。

7.5 集合对象

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

intset 编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合里面。
hashtable 编码的集合对象使用字典作为底层实现，字典的每个键都是一个字符串对象，每个字符串对象包含了一个集合元素，而字典的值则全部被设置为 null 。

7.5.1 编码转换

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

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

第二个条件的上限值是可以修改的，不满足这两个条件的集合对象需要使用 hashtable 编码。

7.6 有序集合对象

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

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

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

7.6.1 编码转换

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

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

以上两个上限值都是可以修改的，不能满足这两个条件的有序集合对象将使用 skiplist 编码。

7.7 内存回收 & 对象共享

因为 C 语言并不具备自动内存回收功能，所以 Redis 在自己的对象系统中构建了一个引用计数（reference counting）技术实现的内存回收机制，通过这一机制，程序可以通过跟踪对象的引用计数信息，在适当的时候自动释放对象并进行内存回收。每个对象的引用计数信息由 redisObject 结构的 refcount 属性记录。

除了用于实现引用计数内存回收机制之外，对象的引用计数属性还带有对象共享的作用。尽管共享更复杂的对象可以节约更多的内存，但受 CPU 时间的限制，Redis 只对包含整数值的字符串对象进行共享。

7.8 对象的空转时长

除了之前介绍了 type 、encoding 、ptr 和 refcount 四个属性之外，redisObject 结构包含的最后一个属性为 lru 属性，该属性记录了对象最后一次被命令程序访问的时间。

使用命令 OBJECT IDLETIME 给定键 可以打印出给定键的空转时长，这一空转时长就是通过将当前时间减去键的值对象的 lru 时间计算得出的。

除了可以被 OBJECT IDLETIME 给定键 命令打印出来之外，键的空转时长还有另外一项作用：如果服务器打开了 maxmemory 选项，并且服务器用于回收内存的算法为 volatile-lru 或者 allkeys-lru ，那么当服务器占用的内存数超过了 maxmemory 选项所设置的上限值时，空转时长较高的那部分键会优先被服务器释放，从而回收内存。

8. 数据库

8.1 服务器中的数据库

Redis 服务器将所有数据库都保存在服务器状态 redis.h/redisServer 结构的 db 数组中，db 数组的每个项都是一个 redis.h/redisDb 结构，每个 redisDb 结构代表一个数据库。

struct redisServer {
    // ...
    // 一个数组，保存着服务器中的所有数据库
    redisDb *db;
    // ...
    // 初始化服务器时，程序会根据服务器状态的 dbnum 属性
    // 来决定应该创建多少个数据库，默认是 16
    int dbnum;
    // ...
};

可以通过命令 SELECT n 来切换到 n 号数据库。

8.2 数据库键空间

redisDb 结构的 dict 字典保存了数据库中所有键值对，我们将这个字典称为键空间（key space）。

键空间和用户所见的数据库是直接对应的

键空间的键也就是数据库的键，每个键都是一个字符串对象。
键空间的值也就是数据库的值，每个值可以是字符串对象、列表对象、哈希表对象、集合对象和有序集合对象中的任意一种 Redis 对象。

typedef struct redisDb {
    // ...
    // 数据库键空间，保存着数据库中的所有键值对
    dict *dict;
    // 过期字典，保存着键的过期时间
    dict *expires;
} redisDb;

8.3 键的生存时间或过期时间

redisDb 结构的 expires 字典保存了数据库中所有键的过期时间，我们称这个字典为过期字典：

过期字典的键是一个指针，这个指针指向键空间中某个键对象（也即是某个数据库键）。
过期字典的值是一个 long long 类型的整数，这个整数保存了键所指向的数据库键的过期时间–一个毫秒精度的 UNIX 时间戳。

8.4 过期键的删除策略

有三种不同的删除策略：

定时删除：在设置键的过期时间的同时，创建一个定时器（timer），让定时器在键的过期时间来临时，立即执行对键的删除操作。
惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话就删除该键；如果没有，就返回该键。
定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

为了更好更合理的在 CPU 时间以及避免浪费内存空间之间取得平衡，Redis 服务器使用 惰性删除 和 定期删除 两种策略。

8.5 AOF、RDB 和复制功能对过期键的处理

8.5.1 载入 RDB 文件

在启动服务器时，如果服务器开启了 RDB 功能，那么服务器将对 RDB 文件进行载入：

如果服务器以主服务器模式运行，那么在载入 RDB 文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入 RDB 文件的主服务器不会造成影响。
如果服务器以从服务器模式运行，那么在载入 RDB 文件时，文件中保存的所有键，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入 RDB 文件的从服务器也不会造成影响。

8.5.1 AOF 文件写入

当服务器以 AOF 持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么 AOF 文件不会因为这个过期键而产生任何影响。

当过期键被惰性删除或者定期删除之后，程序回向 AOF 文件追加（append）一条 DEL 命令，来显式地记录该键已经被删除。

8.5.2 AOF 重写

和生成 RDB 文件时类似，在执行 AOF 重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的 AOF 文件中。

8.5.3 复制

当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制：

主服务器在删除一个过期键之后，会显式的向所有从服务器发送一个 DEL 命令，告知从服务器删除这个过期键。
从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像处理未过期的键一样来处理过期键。
从服务器只有在接到主服务器发来的 DEL 命令之后，才会删除过期键。

通过由主服务器来控制从服务器统一地删除过期键，可以保证主从服务器数据的一致性，也正是因为这个原因，当一个过期键仍然存在于主服务器的数据库时，这个过期键在从服务器里的复制品也会继续存在。

8.5.4 数据库通知

数据库通知功能可以让客户端通过订阅给定的频道或者模式，来获知数据库中键的变化，以及数据库中命令的执行情况。

“某个键执行了什么命令” 的通知称为键空间通知（key-space notification）
“某个命令被什么键执行了” 的通知称为键事件通知（key-event notification）

当 Redis 命令对数据库进行修改之后，服务器会根据配置向客户端发送数据库通知。

9. RDB 持久化

9.1 RDB 文件的创建与载入

有两个 Redis 命令可以用于生成 RDB 文件，一个是 SAVE ，另一个是 BGSAVE。

SAVE 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
与 SAVE 命令直接阻塞服务器进程的做法不同，BGSAVE 命令会派生出一个子进程，然后由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理命令请求。

RDB 文件的载入工作是在服务器启动时自动执行的，所以 Redis 并没有专门用于载入 RDB 文件的命令，只要 Redis 服务器在启动时检测到 RDB 文件存在，它就会自动载入 RDB 文件。

另外，因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，所以：

如果服务器开启了 AOF 持久化功能，那么服务器会优先使用 AOF 文件来还原数据库状态。
只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。

服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

9.2 自动间隔性保存

因为 BGSAVE 命令可以在不阻塞服务器进程的情况下执行，所以 Redis 允许用户通过设置服务器配置的 save 选项，让服务器每个一段时间自动执行一次 BGSAVE 命令。

用户可以通过 save 选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

Redis 的服务器周期性操作函数 serverCron 默认每个 100 毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查 save 选项所设置的保存条件是否已经满足，如果满足的话，就执行 BGSAVE 命令。

10. AOF 持久化

与 RDB 持久化通过保存数据库中的键值对来记录数据库状态不同，AOF（Append Only File）持久化时通过保存 Redis 服务器所执行的写命令来记录数据库状态的。

10.1 AOF 持久化的实现

AOF 持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

10.1.1 命令追加

当 AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

10.1.2 文件的写入与同步

为了提高文件的写入效率，在现代操作系统中，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正的将缓冲区中的数据写入到磁盘里面。
这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。

因此，Redis 服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。

下面是配置可选值：

10.2 AOF 文件的载入与数据还原

因为 AOF 文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍 AOF 文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

步骤如下：

创建一个不带网络连接的伪客户端（fake client）
从 AOF 文件中分析并读取一条写命令
使用伪客户端执行被读出的写命令
重复执行步骤 2 与步骤 3 ，直到 AOF 中的所有写命令都被处理完毕为止。

10.3 AOF 重写

因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF 文件中的内容越来越多，文件体积也会越来越大，如果不加以控制，体积过大的 AOF 文件很可能对 Redis 服务器、甚至整个宿主计算机造成影响，并且 AOF 文件体积越大，使用 AOF 文件来进行数据还原所需的时间就越多。

为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写（rewrite）功能。通过该功能，Redis 服务器可以创建一个新的 AOF 文件来替代现有的 AOF 文件，新旧两个 AOF 文件所保存的数据库状态相同，但新 AOF 文件不会包含任何浪费空间的冗余命令，所以新 AOF 文件的体积通常会比旧 AOF 文件的体积要小得多。

AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是 AOF 重写功能的实现原理。

Redis 将 AOF 重写程序放到子进程里执行，这样子进程在进行 AOF 重写期间，服务器进程（父进程）可以继续处理命令请求，并且可以避免在使用锁的情况下，保证数据的安全性。

但是，使用子进程也有一个问题需要解决，因为子进程在进行 AOF 重写期间，服务器还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的 AOF 文件所保存的数据库状态不一致。

为了解决这种数据不一致的问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当 Redis 服务器执行完一个写命令之后，它会同时将这个命令发送给 AOF 缓冲区和 AOF 重写缓冲区。

当子进程完成 AOF 重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作：

将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中，这时新 AOF 文件所保存的数据库状态将和服务器当前的数据库状态一致。
对新的 AOF 文件进行改名，原子地（atomic）覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换。

这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求了。

在整个 AOF 后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其它时候，AOF 后台重写都不会阻塞父进程，这将 AOF 重写对服务器性能造成的影响降到了最低。

总结 AOF 重写就是，在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新的 AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。

11. 事件

Redis 服务器是一个事件驱动器，服务器需要处理以下两类事件：

文件事件（file event）：Redis 服务器通过套接字与客户端（或者其它 Redis 服务器）进行连接，而文件事件就是服务器对套接字操作的抽象。服务器与客户端（或者其它服务器）的通信会产生相应的文件事件，而服务器则通过监听并处理这些事件来完成一系列网络通信操作。
时间事件（time event）：Redis 服务器中的一些操作（比如 serverCron 函数）需要在给定的时间点执行，而时间事件就是服务器对这类定时操作的抽象。

11.1 文件事件

Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）：

文件事件处理器使用 I / O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其它同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

文件事件分为 AE_READABLE 事件（读事件）和 AE_WRITEABLE 事件（写事件）两类。

11.2 时间事件

Redis 的时间事件分为以下两类：

定时事件：让一段程序在指定的时间之后执行一次。比如说，让程序 X 在当前时间的 30 毫秒之后执行一次。
周期性事件：让一段程序每隔指定时间就执行一次。比如说，让程序 X 每隔 30 毫秒就执行一次。

服务器在一般情况下只执行 serverCron 函数一个时间事件，并且这个事件是周期性事件。

时间事件的实际处理时间通常会比设定的到达时间晚一些。

文件事件和时间事件之间是合作关系，服务器会轮流处理这两种事件，并且处理事件的过程中也不会进行抢占。

12. 复制

在 Redis 中，用户可以通过执行 SLAVEOF 命令或者设置 slaveof 选项，让一个服务器去复制（replicate）另一个服务器，我们称呼被复制的服务器为主服务器（master），而对主服务器进行复制的服务器被称为从服务器（slave）。

12.1 复制功能的实现

Redis 的复制功能分为同步（sync）和命令传播（command propagate）两个操作：

同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态。

在 Redis 的旧版复制功能中存在着缺陷，也就是当从服务器断线后重复制的效率非常低。在旧版复制功能中，从服务器断线之后重连，需要请求主服务器重新执行 BGSAVE 命令生成包含全部数据库状态的 RDB 文件，然后再传输给从服务器，从服务器接受载入 RDB 文件，其效率非常低下。

为了解决旧版复制功能在处理断线重复制情况时的低效问题，Redis 从 2.8 版本开始，使用 PSYNC 命令代替 SYNC 命令来执行复制时的同步操作。

PSYNC 命令具有两种模式：

完整重同步（full resynchronization）：用于处理初次复制情况，执行步骤与 SYNC 命令的执行步骤基本一样，它们都是通过让主服务器创建并发送 RDB 文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步。
部分重同步（partial resynchronization）：用于处理断线后的重复制情况，当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。

12.2 心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令 REPLCONF ACK <replication_offset> ，其中 replication_offset 是从服务器当前的复制偏移量。

发送 REPLCONF ACK 命令对于从服务器有三个作用：

检测主从服务器的网络连接状态。
辅助实现 min-slaves 选项。
检测命令是否丢失。

13. Sentinel

Sentinel（哨岗、哨兵）是 Redis 的高可用性解决方案：由一个或多个 Sentinel 实例（instance）组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

Sentinel 本质上只是一个运行在特殊模式下的 Redis 服务器。

Sentinel 的启动命令

redis-sentinel /path/to/your/sentinel.conf
# 或者是
redis-server /path/to/your/sentinel.conf --sentinel

13.1 主观下线

在默认情况下，Sentinel 会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其它 Sentinel 在内）发送 PING 命令，并通过实例返回的 PING 命令回复来判断实例是否在线。

如果在默认配置的间隔时间内，有一服务器并没有进行有效回复，那此 Sentinel 就会将此服务器标记为主观下线。

13.2 客观下线

当 Sentinel 将一个服务器判断为主观下线之后，为了确定此服务器是否是真的下线了，它会去询问其它 Sentinel 此服务器是否已下线，当得到足够数量的确定回复之后，Sentinel 就会将此服务器标记为客观下线状态，如果此服务器是主服务器，就执行故障转移操作。

13.3 选举领头 Sentinel

当一个主服务器被判定为客观下线之后，监视这个下线主服务器的各个 Sentinel 会进行协商，选举出一个领头 Sentinel，并由领头 Sentinel 对下线主服务器执行故障转移操作。

13.4 故障转移

在选举产生领头 Sentinel 之后，领头 Sentinel 将对已下线的主服务器执行故障转移操作，包含以下三个步骤：

在已下线主服务器的所有从服务器中，选择一个从服务器将其转换为新的主服务器。
让已下线主服务器的所有从服务器改为复制新的从服务器。
将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，他就会成为新的主服务器的从服务器。

14. 集群

Redis 集群是 Redis 提供的分布式数据库方案，集群通过分片（sharding）来进行数据共享，并提供复制和故障转移功能。

一个 Redis 集群通常由多个节点组成，在刚开始的时候，每个节点都是相互独立的，它们都处于一个只包含自己的集群当中，要组建一个真正可工作的集群，我们必须将各个独立的节点连接起来，构成一个包含多个节点的集群。

# 连接各个节点的工作可以使用这个命令来完成
CLUSTER MEET

14.1 槽指派

Redis 集群通过分片的方式来保存数据库中的键值对：集群的整个数据库被分为 16384 个槽（slot），数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点可以处理 0 个或最多 16384 个槽。每个节点都会记录哪些槽指派给了自己，而哪些槽又被指派给了其它节点。

当数据库中的 16384 个槽都有节点在处理时，集群处于上线状态（ok）；相反地，如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态（fail）。

节点在接到一个命令请求时，会先检查这个命令请求要处理的键所在的槽是否由自己负责，如果不是的话，节点将向客户端返回一个 MOVED 错误，MOVED 错误携带的信息可以指引客户端转向至正在负责相关槽的节点。

对 Redis 集群的重新分片工作是由 redis-trib 负责执行的，重新分片的关键是将属于某个槽的所有键值对从一个节点转移至另一个节点。

如果节点 A 正在迁移槽 i 至节点 B ，那么当节点 A 没能在自己的数据库中找到命令指定的数据库键时，节点 A 会向客户端返回一个 ASK 错误，指引客户端到节点 B 继续查找指定的数据库键。

MOVED 错误表示槽的负责权已经从一个节点转移到了另一个节点，而 ASK 错误只是两个节点在迁移槽的过程中使用的一种临时措施。

集群中的从节点用于复制主节点，并在主节点下线时，代替主节点继续处理命令请求。

集群中的节点通过发送和接收消息来进行通信，常见的消息包括 MEET、PING、PONG、PUBLISH、FAIL 五种。

15. 发布与订阅

Redis 的发布与订阅功能由 PUBLISH、SUBSCRIBE、PSUBSCRIBE 等命令组成

SUBSCRIBE 是频道订阅，客户端可以订阅一个或多个频道，成为这些频道的订阅者（subscriber），每当有其它客户端向被订阅的频道发送消息时，频道的所有订阅者都会收到这条消息
PSUBSCRIBE 是基于模式的订阅，除了订阅频道之外，客户端还可以通过执行 PSUBSCRIBE 命令订阅一个或多个模式，从而成为这些模式的订阅者，每当有其它客户端向某个频道发送消息时，消息不仅会被发送给这个频道的所有订阅者，它还会发送给所有与这个频道相匹配的模式的订阅者。

客户端可以通过 PUBSUB 命令来查看频道或者模式的相关信息，比如某个频道目前有多少订阅者，又或者某个模式目前有多少订阅者等等。

当一个 Redis 客户端执行 PUBLISH <channel> <message> 命令将消息 message 发送给频道 channel 的时候，服务器需要执行以下两个动作：

将消息 message 发送给 channel 频道的所有订阅者。
如果有一个或多个模式的 pattern 与频道 channel 相匹配，那么将消息 message 发送给 pattern 模式的订阅者。

16. 事务

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其它客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其它客户端的命令请求。事务以 MULTI 开始，以 EXEC 命令结束。

16.1 事务的实现

MULTI 命令的执行代表事务的开始，MULTI 通过将客户端状态的 flags 属性中的 REDIS_MULTI 标识打开来将执行该命令的客户端切换至事务状态。
每个客户端都有自己的事务状态，它保存在客户端状态的 mstate 属性里面，mstate 里面包含一个事务队列，以及一个已入队命令的计数器，事务队列是一个 multiCmd 类型的数组，每个 multiCmd 结构都保存着一个已入队命令的相关信息，事务队列以先进先出（FIFO）的方式保存入队命令。
当一个处于事务状态的客户端向服务器发送 EXEC 命令时，这个 EXEC 命令会立即被执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端。

16.2 WATCH 命令的实现

WATCH 命令是一个乐观锁，它可以在 EXEC 命令执行之前，监视任意数量的数据库键，并在 EXEC 命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的回复。

每个Redis 数据库都保存着一个 watched_keys 字典，这个字典的键是某个被 WATCH 命令监视的数据库键，而字典的值则是一个链表，链表中记录了所有监视相应数据库键的客户端。通过 watched_keys 字典，服务器可以清楚地知道哪些数据库键正在被监视，以及哪些客户端正在监视这些数据库键。

通过执行 WATCH 命令，客户端可以在 watched_keys 字典中与被监视的键进行关联。

当前客户端为 c10086 ，在执行 WATCH "name" "age" 命令之后，如下图所示：

所有对数据库进行修改的命令，在执行之后都会调用 touchWatchKey 函数对 watched_key 字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，那么 touchWatchKey 函数会将监视被修改键的客户端的 REDIS_DIRTY_CAS 标识打开，表示该客户端的事务安全性已经被破坏。

当服务器接收到一个客户端发来的 EXEC 命令时，服务器会根据这个客户端是否打开了 REDIS_DIRTY_CAS 标识来决定是否执行事务，如果标识被打开，说明客户端所监视的键当中，至少有一个键已经被修改过了，服务器会拒绝执行客户端所提交的事务；如果标识没有被打开，说明事务仍然是安全的，服务器会执行客户端提交的事务。