Redis学习笔记

第一章 引言

学技术最快速的方式就是根据官方文档学习：redis技术文档

redis的重点是在如何用好先，在谈设计，就像朱哥说的。

第二章 简单动态字符串

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

2.1 SDS的定义

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

2.2 SDS与C字符串的区别

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

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

2.杜绝缓冲区溢出

除了获取字符串长度的复杂度高之外，C字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出 ( buffer overflow)。

SDS的空间分配策略完全杜绝了发生缓冲区溢出的可能性:当SDS-API需要对SDS进行修改时，API会先检查SDS的空间是否满足修改所需的要求，如果不满足的话，API会自动将SDS的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用SDS既不需要手动修改SDS的空间大小，也不会出现前面所说的缓冲区溢出问题。

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

3.1 预分配空间

空间预分配用于优化SDS字符串增长操作。在扩展SDS空间前，SDS API会先检查未使用空间够不够，如果不够，则进行空间预分配。此时，程序不仅会为SDS分配修改所必须要的空间，还为其分配额外未使用的空间。

• 修改后的SDS<1MB，程序分配和len属性同样大小的未使用空间，此时SDS的len与free大小相等。比如修改后实际存储字符串的空间变为13字节，那么len=13，free=13，buf数组整体的长度=13+13+1（额外1字节保存空字符）。
• 修改后SDS>=1MB。程序会分配1MB的未使用空间。比如修改后实际存储字符串的空间变为2MB，那么len=2M，free=1MB，buf数组整体的长度=2MB+1MB+1byte。

通过空间的预分配，将连续增长N次字符串需要的内存分配次数从一定需要N次变为最多N次。因而可以减少连续执行字符串增长操作所需的内存重分配的次数。

3.2 惰性空间释放

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

4.二进制安全

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

5.兼容部分C字符串函数

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

第三章 链表

链表在Redis中的应用非常广泛，比如列表键的底层实现之一就是链表。当一个列表键包含了数量比较多的元素，又或者列表中包含的元素都是比较长的字符串时，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;

第四章 字典

字典，又称为符号表( symbol table)、关联数组( associative array)或映射( map)，是一种用于保存键值对( key-value pair)的抽象数据结构。
在字典中，一个键( key)可以和一个值( value)进行关联（或者说将键映射为值)，这些关联的键和值就称为键值对。

Redis的字典使用哈希表作为底层实现，一个哈希表里面可以有多个哈希表节点，而每个哈希表节点就保存了字典中的一个键值对。可以想象成类似这种结构 Map<String,Map<String,T> > MP;

4.1 哈希表

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

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

4.2 哈希表节点

哈希表节点使用dictEntry实现，每个dictEntry都存储着一个键值对：

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

键值对的值可以是一个指针，或一个uint64_t整数，或一个int64_整数。next是指向另一个哈希节点的指针，可将多个哈希值相同的键值对连接在一起，以此来解决冲突。

4.3 字典

Redis中的字典由dict.h/dict实现，由这个数据结构将字典组织在一起。

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

type和privdata属性是针对不同类型的键值对，为丰富键值对的使用场景而设置的。

• type属性是一个指向dictType的结构指针，每个dictType结构保存了一簇用于操作特定类型键值对的函数，Redis为用途不同的字典设置不同类型特定函数。

typedef struct dictType{
    // 计算哈希值的函数
    unsigned int (*hashFunction)(const void *key);
    // 复制键的函数
    void *(*keyDup)(void *privdata,const void *key);
}

• privdata属性保存了需要传给那些类型特定函数的可选参数。
• ht属性是包含两个项的数组，每项都是一个哈希表，ht[0]平时使用，而ht[1]仅在rehash时使用。
• rehashidx记录了rehash的进度，初始为-1。

4.4 哈希算法

Redis计算哈希值方法： hash=dict->type->hashFunction(key);

计算索引值的方法：index=hash & dict->ht[x].sizemask;

当字典被用作数据库的底层实现或哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。优点在于即使输入的键是有规律的，算法仍然能给出很好的随机分布性，并且计算速度飞快。

4.5 解决键冲突

当有两个或以上的键被分配到哈希表的同个索引，那么就发生了冲突。Redis使用链地址法来解决冲突，被分配到索引的多个节点使用链表连接。为了提高速度，每次都是将新节点添加到链表的表头位置。

4.6 rehash

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

Dict的扩容

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

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

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

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

Dict的收缩

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

rehash

Dict的rehash

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

• 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
  如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
  如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于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]的内存

rehash前

rehash后

4.7 渐进式rehash

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

• 计算新hash表的size，值取决于当前要做的是扩容还是收缩：
  如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
  如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于4）
• 按照新的size申请内存空间，创建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.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过程中，新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[0]和dict.ht[1]依次查找并执行。这样可以确保ht[0]的数据只减不增，随着rehash最终为空

总结：

Q：为什么哈希表操作变慢了？

A：哈希表的冲突问题和 rehash 可能带来的操作阻塞。因此提出渐进式rehash

渐进式 rehash介绍

简单来说就是在第二步拷贝数据时，Redis 仍然正常处理客户端请求，每处理一个请求时，从哈希表 1 中的第一个索引位置开始，顺带着将这个索引位置上的所有 entries 拷贝到哈希表 2 中；等处理下一个请求时，再顺带拷贝哈希表 1 中的下一个索引位置的 entries。如下图所示：

第五章 跳跃表

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。

跳跃表支持平均 O(logN) 、最坏 O(N) 度的节点查找，还可以通过顺序性操作来批量处理节点。Redis 只在两个地方用到了跳跃表，一个是实现有序集合键，另一个是在集群节点中用作内部数据结构。

之前实现过跳表的原理，欢迎start:基于跳表实现的K-V存储引擎

总结：

跳表

跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位。

第一次：如果我们要在链表中查找 33 这个元素，只能从头开始遍历链表，查找 6 次，直到找到 33 为止。O(N)

第二次：增加一级索引，从第一个元素开始，每两个元素选一个出来作为索引。这些索引再通过指针指向原始的链表。例如，从前两个元素中抽取元素 1 作为一级索引，从第三、四个元素中抽取元素 11 作为一级索引。此时，我们只需要 4 次查找就能定位到元素 33 了。

第三次：增加二级索引：从一级索引中，再抽取部分元素作为二级索引。例如，从一级索引中抽取 1、27、100 作为二级索引，二级索引指向一级索引。这样，我们只需要 3 次查找，就能定位到元素 33 了。

时间复杂度：O（lgN）

第六章 整数集合

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

6.1 整数集合的实现

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

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

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

6.2 升级

当我们要将一个新元素添加至集合时，并且新元素的类型比现有集合类型都长时，整数集合就要升级。

步骤：

1. 根据新元素类型，扩展数组空间，为新元素分配空间。
2. 将底层数组现有所有元素都转为新元素相同类型，并将类型转换后的元素放到正确位置。
3. 将新元素添加到底层数组。

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

6.3 升级的好处

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

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

第七章 压缩列表

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

ZipListEntry

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

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

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）。新增、删除都可能导致连锁更新的发生。

第八章 对象

Redis没有直接使用前文的数据结构来实现键值对数据库，而是基于这些数据结构构建了一个对象系统，通过对象组织数据结构，包括字符串对象，列表对象，哈希对象，集合对象和有序集合对象这5种对象。

使用对象的一个好处是可以针对不同的使用场景，为对象设置多种不同的数据结构实现，从而优化对象在不同场景下的使用效率。

8.1 对象的类型与编码

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

8.1.1 类型

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

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

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

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

7.1.2 编码和底层实现

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

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

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

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

8.2 字符串对象

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

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

raw编码的字符串对象

embstr编码的字符串对象

raw 与 embstr 的区别是：raw编码会调用两次内存分配函数来分别创建 redisObject 结构和 sdshdr 结构，而 embstr编码则通过一次内存分配函数来分配一块连续的空间，空间中依次包含 redisObject和 sdshdr 两个结构 。

编码转换

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

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

8.3 列表对象

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

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

编码转换

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

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

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

8.4 哈希对象

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

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

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

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

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

编码转换

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

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

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

8.5 集合对象

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

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

编码转换

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

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

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

8.6 有序集合对象

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

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

因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。

• SkipList：可以排序，并且可以同时存储score和ele值（member）
• HT（Dict）：可以键值存储，并且可以根据key找value

编码转换

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

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

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

8.7 类型检查的实现

8.8 内存回收

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

8.9 对象共享

除了用于实现引用计数内存回收机制之外，对象的引用计数属性还带有对象共享的作用。

8.10 对象的空转时长

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

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

总结：

对象：String,List,Hash,Set,Sorted Set

特点：一个键对应了一个集合的数据

第九章 数据库

9.1 服务器中的数据库

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

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

dbnum：来决定应该创建多少个数据库，默认是 16

9.2 切换数据库

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

9.3 数据库键空间

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

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

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

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

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

保存过期时间

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

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

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

9.5 过期键的删除策略

有三种不同的删除策略：

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

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

9.6 Redis的过期键删除策略

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

生成RDB文件

在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB文件中。

载入 RDB 文件

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

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

AOF 文件写入

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

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

AOF 重写

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

复制

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

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

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

下面用2张图简单了解下这个过程

数据库通知

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

这一类关注“某个键执行了什么命令”的通知称为键空间通知（ key-space notification ),除此之外，还有另一类称为键事件通知( key-event notification )的通知，它们关注的是“某个命令被什么键执行了”"。

第十章 RDB持久化

因为 Redis是内存数据库,它将自己的数据库状态储存在内存里面,所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。

RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态,如图所示。

10.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 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

10.2 自动间隔性保存

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

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

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

10.3 RDB文件结构

第十一章 AOF持久化

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

补充：

Q：AOF日志写入时机？

A：AOF日志是写后日志。

解释：我们常常写日志都是WAL技术，就是先记录，再写日志。但是AOF写日志是反的。

原因：

1. 不会阻塞当前命令执行
2. 如果当前命令成功执行，也就说明这个命令没有问题，那么写入日志很ok。

11.1 AOF持久化的实现

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

命令追加

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

AOF文件的写入与同步

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

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

AOF 配置项 appendfsync 的三个可选值。

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

• Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

三种策略的写回时机:

简单一句话：要高性能，选择 No 策略；要高可靠性，选择 Always 策略；如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择 Everysec 策略。

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

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

步骤如下：

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

11.3 AOF重写

为什么要重写？

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

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

AOF文件重写实现

虽然 Redis将生成新AOF文件替换旧AOF 文件的功能命名为“AOF文件重写”，但实际上，AOF 文件重写并不需要对现有的AOF 文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

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

AOF后台重写

上面介绍的AOF重写程序aof_rewrite函数可以很好地完成创建一个新AOF文件的任务，但是，因为这个函数会进行大量的写人操作，所以调用这个函数的线程将被长时间阻塞,所以 Redis 决定将AOF重写程序放到子进程里执行。

• 子进程进行AOF重写期间，服务器进程（父进程）可以继续处理命令请求。
• 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

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

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

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

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

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

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

总结：

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

这里，对AOF和做个总结

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

极客时间中重写总结

重写的过程总结为一个拷贝，两处日志。

重写过程是由后台线程 bgrewriteaof 来完成的。

1. “一个拷贝”是指什么？

• 每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

2. “两处日志”又是什么呢？

• 因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。

• 而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。

第十二章 事件

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

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

12.1 文件事件

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

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

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

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

12.2 时间事件

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

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

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

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

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

第十三章 客户端

第十四章 服务器

Q：为什么单线程Redis能那么快？

A：

首先，先理清下概念：Redis 是单线程，主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

快呢，有4点原因：

1. 内存DB

2. 单线程，没有线程切换开销

3. IO多路复用

4. 底层数据结构

第十五章 复制

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

Redis中可以通过 SLAVEOF 命令来设置一个服务器为从服务器，从而复制指定的主服务器的数据。

15.1 旧版复制功能的实现

旧版复制功能包括 同步(sync) 和 命令传播 两个操作。

同步

从服务器对主服务器的同步操作需要发送 SYNC命令来实现，该命令的执行步骤包括：

1. 从服务器向主服务器发送SYNC命令；
2. 主服务器接收到命令后，执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区来记录从当前开始的写命令；
3. 当主服务器的 BGSAVE命令执行完成后就将 RDB 文件发送给从服务器，从服务器开始接受并且载入这个RDB 文件；
4. 主服务器将记录在缓冲区里面的所有写命令发送给从服务器执行，从服务器来将自己的数据库状态更新为主服务器的状态。

命令传播

在同步操作完成后，主服务器一旦有一些新命令的执行导致数据库发生改变就需要将改变立刻同步到从服务器，因此对于会导致数据库更改的命令，主服务器会同样发送到从服务器。

15.2 旧版复制功能的缺陷

在Redis中的复制可以分为初次复制和断线后的重复制。旧版复制对于初次复制没有问题，但是断线后的重复制效率比较低。
因为当复制过程中出现断线后，当从服务器再次连接上时由于没有记录上次的复制位置，所以需要重新从头开始复制，执行SYNC 命令(初次复制)。
但是主从服务器断开的时间比较短，导致主服务器在断线期间执行的写命令较少，而每次断线时为了这点命令选择执行 SYNC命令，效率非常低效。

SYNC 命令是一种非常耗时的操作

• 主服务器要执行 BGSAVE 指令来生成 RDB 文件，这个操作会消耗主服务器大量的 CPU、内存和磁盘 I/O 资源。
• 主服务器将 RDB 文件发送到从服务器会消耗网络资源。
• 从服务器接受 RDB 文件后会载入，这个期间从服务器会阻塞没有办法处理命令请求。

15.3 新版复制功能的实现

新版复制采用 PSYNC 命令代替旧版的 SYNC 命令。

这不就是增量复制麻Qwq

该命令包含两个部分：

• 完整重同步：和旧版复制的初次复制操作一样。
• 部分重同步：用于断线后的处理，采用 复制偏移量、复制积压缓冲区、服务器运行ID来实现搞笑的重连接复制操作。

部分重同步

主服务器和从服务器各保存一份复制偏移量，每次主服务器发送数据和从服务器成功接受数据就增加相应的偏移量。通过复制偏移量能够确保主从服务器的数据状态是否一致。

复制积压缓冲区

复制积压缓冲区的特点：

• 复制积压缓冲区是由主服务器维护的一个固定长度的先进先出队列，默认大小为 1MB。
• 每当主服务器进行命令传播时，它不仅会将数据发送给从服务器，还要将数据写入到复制积压缓冲区中，复制积压缓冲区同时还会为队列中的每个字节记录相应的复制偏移量。
• 那么当从服务器断线重连后，它会将自己的复制偏移量发送给主服务器，主服务器就会检查该偏移量之后的数据是否全部存在于复制积压缓冲区中，如果全部存在就执行部分重同步操作；否则必须执行完整重同步操作。

复制积压缓冲区大小可以动态调整：

• 默认大小是 1MB，但是如果断线时间过长，断线时写入的数据较多，就会由于缓冲区大小太小而不得不进行完整重同步操作。
• 缓冲区大小的计算公式：second * write_size_per_second来估算，second表示从服务器断线后重新连接上主服务器所需的时间；write_size_per_second 表示主服务器每秒钟写入的命令数据量。
• 可以通过修改配置文件中的 repl-backlog-size 选项调整缓冲区大小；通过repl-backlog-ttl调整缓冲区的存活时间，超过会被销毁。

服务器ID

每个服务器启动时都会分配一个服务器ID，当从服务器对主服务器进行初次同步操作时，主服务器会将自己的服务器ID发送给从服务器，从服务器会保存起来。
如果从服务器断开后重连到一个主服务器，它会发送之前保存的主服务器ID，如果ID和当前主服务器ID相同就执行部分重同步操作，否则执行完整重同步操作。

从服务器发送指令：

• 如果从服务器初次同步主服务器，它会发送 PSYNC ? -1命令，请求完整重同步操作；
• 如果从服务器已经复制过某个主服务器后，当它开始一次新复制时会发送 PSYNC < runid > < offset > 命令，runid 是上次主服务器的ID， offset 是自己当前的复制偏移量。

主服务器回复指令：

• +FULLRESYNC < runid > < offset >：主服务器与从服务器执行完整的重同步操作；
• +CONTINUE：执行部分重同步操作，等待主服务器发送数据；
• -ERR：识别不了命令，出现问题。

明了概念

简述全量同步和增量同步区别？

• 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
• 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

• slave节点第一次连接master节点时
• slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

• slave节点断开又恢复，并且在repl_baklog中能找到offset时

15.7 心跳检测

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

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

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

第十六章 Sentinel

这个大致思路和raft协议很像。

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

哨兵的作用

• 监控：Sentinel 会不断检查您的master和slave是否按预期工作
• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

主观下线

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

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

客观下线

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

选举领头 Sentinel

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

故障转移

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

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

总结

Sentinel的三个作用是什么？

• 监控
• 故障转移
• 通知

Sentinel如何判断一个redis实例是否健康？

• 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
• 如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

• 首先选定一个slave作为新的master，执行slaveof no one
• 然后让所有节点都执行slaveof 新master
• 修改故障节点，执行slaveof 新master

第十七章 集群

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

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

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

槽指派

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

• key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分

• key中不包含“{}”，整个key都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

Redis如何判断某个key应该在哪个实例？

• 将16384个插槽分配到不同的实例
• 根据key的有效部分计算哈希值，对16384取余
• 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

• 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

第十八章 发布与订阅

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

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

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

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

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

第十九章 事务

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

19.1 事务的实现

一个事务从开始到结束通常会经历以下三个阶段:

1）事务开始

2）命令入队

3）事务执行

本节接下来的内容将对这三个阶段进行介绍，说明一个事务从开始到结束的整个过程。

事务开始

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

19.2 WATCH命令的实现

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

接下来，我将详细介绍下watch命令的实现原理。

每个Redis数据库都保存着一个watched_keys字典，这个字典的键是某个被WATCH命令监视的数据库键，而字典的值则是一个链表，链表中记录了所有监视相应数据库键的客户端:

下图展示的watched_keys字典将被更新的状态。

监视机制的触发

所有对数据库进行修改的命令，比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等，在执行之后都会调用multi.c/touchWatchKey函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，那么touchwatchKey函数会将监视被修改键的客户端的REDIS_DIRTY_CAs标识打开，表示该客户端的事务安全性已经被破坏。

19.3 事务的ACID性质

在 Redis 中，事务总是具有原子性(Atomicity )、一致性( Consistency)和隔离性( Isolation )，并且当Redis运行在某种特定的持久化模式下时，事务也具有耐久性( Durability )。

第二十章 Lua脚本

第二十一章 二进制位数组

Redis 提供了 SETBIT、GETBIT、BITCOUNT、BITOP 四个命令用于处理二进制位数组，又称 “位数组”

• SETBIT命令用于为位数组指定偏移量上的二进制位设置值，可以是 0 或者 1
• GETBIT 用于获取指定偏移量上的二进制位的值
• BITCOUNT 用于统计位数组里面，值为 1 的二进制位的数量
• BITOP可以对多个位数组进行按位与（and）、按位或（or）、按位异或（xor）、取反（not）运算

Redis 使用 SDS 来保存位数组。

第二十二章 慢查询日志

• Redis 的慢查询日志功能用于记录执行时间超过给定时长的命令请求，用户可以通过这个功能产生的日志来监视和优化查询速度。

第二十三章 监视器

• 客户端可以通过执行 MONITOR 命令，将客户端转换成监视器，接收并打印服务器处理的每个命令请求的相关信息
• 当一个客户端从普通客户端变为监视器时，该客户端的 REDIS_MONITOR标识会被打开
• 服务器将所有监视器都记录在 monitors 链表中
• 每次处理命令时，服务器都会遍历 monitors 链表，将相关信息发送给监视器