Redis设计与实现详解三：多机功能实现

最新推荐文章于 2024-03-05 07:15:00 发布

熬粑马

最新推荐文章于 2024-03-05 07:15:00 发布

阅读量338

点赞数

分类专栏： Redis设计与实现文章标签： redis 数据库

本文链接：https://blog.csdn.net/weixin_43914789/article/details/108248456

版权

Redis设计与实现专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Redis设计与实现详解一：数据结构与对象

Redis设计与实现详解二：Redis数据库实现

Redis设计与实现详解四：其他单机功能

复制

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

进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作“数据库状态一致”

旧版复制功能的实现

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

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

同步

当客户端向从服务器发送 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作

从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成，以下是命令的执行步骤：

从服务器向主服务器发送SYNC命令
收到命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令
当主服务器的命令执行完毕时，主服务器会将命令生成的RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态
主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态

命令传播

当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能会被修改，并导致主从服务器状态不再一致

为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令，也即是造成主从服务器不一致的那条写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态

旧版复制功能的缺陷

在Redis中，从服务器对主服务器的复制可以分为以下两种情况：

初次复制：从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同
断线后重复制：处于命令传播阶段的主从服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连上了主服务器，并继续复制主服务器

短线后重连会发送sync重新完全同步，造成大量的资源浪费

SYNC命令是一个非常耗费资源的操作

主服务器需要执行命令来生成RDB文件，这个生成操作会耗费主服务器大量的CPU、内存和磁盘I/O资源
主服务器需要将自己生成的RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络资源（带宽和流量），并对主服务器响应命令请求的时间产生影响
接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入期间，从服务器会因为阻塞而没办法处理命令请求

新版复制功能的实现

Redis从2.8版本开始，使用PSYNC命令代替SYNC命令来执行复制时的同步操作

PSYNC命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization）两种模式：

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

部分重同步的实现

复制偏移量

执行复制的双方一主服务器和从服务器会分别维护一个复制偏移量

主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N
从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态

复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB

当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面

主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量

当从服务器重新连上主服务器时，从服务器会通过命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

如果offset偏移量之后的数据（也即是偏移量offset+1开始的数据）仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作
如果offset偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作

服务器运行ID

每个Redis服务器，不论主服务器还是从服务，都会有自己的运行ID。运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成，例如53b9b28df8042fdc9ab5e3fcbbbabffld5dce2b3o

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来

当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID：

如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作
相反地，如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作

PSYNC命令的实现

PSYNC命令的调用方法有两种：

如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步
相反地，如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC <runid> <offset> 命令：其中runid是上一次复制的主服务器的运行ID，而offset则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作

接收到命令的主服务器会向从服务器返回以下三种回复的其中一种：

如果主服务器返回+FULLRESYNC <runid> <offset>回复，那么表示主服务器将与从服务器执行完整重同步操作：其中runid是这个主服务器的运行ID，从服务器会将这个ID保存起来，在下一次发送命令时使用；而offset则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量
如果主服务器返回+CONTINUE回复，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了
如果主服务器返回-ERR回复，那么表示主服务器的版本低于Redis 2.8,它识别不了 PSVNC命令，从服务器将向主服务器发送SYNC命令，并与主服务器执行完整同步操作

复制的实现

步骤1：设置主服务器的地址和端口

从服务器首先要做的就是将客户端给定的主服务器IP地址127.0.0.1以及端口 6379保存到从服务器状态的masterhost属性和masterport属性里面

struct redisServer {
    // ...
    //主服务器的地址
    char *masterhost;
    //主服务器的端口
    int masterport;
    // ...
};

SLAVE OF命令是一个异步命令，在完成masterhost属性和masterport属性的设置工作之后，从服务器将向发送命令的客户端返回OK，表示复制指令已经被接收，而实际的复制工作将在OK返回之后才真正开始执行

步骤2：建立套接字连接

在命令执行之后，从服务器将根据命令所设置的ip地址和端口，创建连向主服务器的套接字连接

如果从服务器创建的套接字能成功连接到主服务器，那么从服务器将为这个套接字关联一个专门用于处理复制工作的文件事件处理器(callback)，这个处理器将负责执行后续的复制工作，比如接收RDB文件，以及接收主服务器传播来的写命令等

主服务器在接受从服务器的套接字连接之后，将为该套接字创建相应的客户端状态，并将从服务器看作是一个连接到主服务器的客户端来对待，这时从服务器将同时具有服务器（server）和客户端（client）两个身份

步骤3：发送PING命令

从服务器成为主服务器的客户端之后，做的第一件事就是向主服务器发送一个PING命令

PING命令有两个作用：

检査套接字的读写状态是否正常
检查主服务器能否正常处理命令请求

从服务器在发送PING命令之后将遇到以下三种情况的其中一种：

如果主服务器向从服务器返回了一个命令回复，但从服务器却不能在规定的时限(timeout)内读取出命令回复的内容，那么表示主从服务器之间的网络连接状态不佳，不能继续执行复制工作的后续步骤。当岀现这种情况时，从服务器断开并重新创建连向主服务器的套接字
如果主服务器向从服务器返回一个错误，那么表示主服务器暂时没办法处理从服务器的命令请求，不能继续执行复制工作的后续步骤。当出现这种情况时，从服务器断开并重新创建连向主服务器的套接字
如果从服务器读取到"PONG"回复，那么表示主从服务器之间的网络连接状态正常，并且主服务器可以正常处理从服务器（客户端）发送的命令请求，在这种情况下，从服务器可以继续执行复制工作的下个步骤

步骤4：身份验证

如果从服务器设置了masterauth选项，那么进行身份验证

如果从服务器没有设置masterauth选项，那么不进行身份验证

双方必须同时满足才能通过验证！

步骤5：发送端口信息

在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port <port-number>，向主服务器发送从服务的监听端口号

主服务器在接收到这个命令之后，会将端口号记录在从服务器所对应的客户端状态的slave_listening_port属性中

typedef struct redisClient {
    // ...
    //从服务器的监听端口号
    int slave_listening_port;
    // ...
} redisClient;

步骤6：同步

从服务器将向主服务器发送命令，执行同步操作，并将自己的数据库更新至主服务器数据库当前所处的状态

在同步操作执行之前，只有从服务器是主服务器的客户端，但是在执行同步操作之后，主服务器也会成为从服务器的客户端

步骤7：命令传播

当完成了同步之后，主从服务器就会进入命令传播阶段，这时主服务器只要一直将自己执行的写命令发送给从服务器，而从服务器只要一直接收并执行主服务器发来的写命令

心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：

REPLCONF ACK <replication_offset>
其中replication_offset是从服务器当前的复制偏移量

检测主从服务器的网络连接状态

主从服务器可以通过发送和接收命令来检查两者之间的网络连接是否正常：如果主服务器超过一秒钟没有收到从服务器发来的命令，那么主服务器就知道主从服务器之间的连接岀现问题了

辅助实现min-slaves配置选项

Redis 的min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令

举个例子，如果我们向主服务器提供以下设置：

min-slaves-to-write 3
min-slaves-max-lag 10

那么在从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时，主服务器将拒绝执行写命令

检测命令丟失

如果主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器

重点

Redis 2.8以前的复制功能不能高效地处理断线后重复制情况，但Redis 2.8新添加的部分重同步功能可以解决这个问题
部分重同步通过复制偏移量、复制积压缓冲区、服务器运行ID三个部分来实现
在复制操作刚幵始的时候，从服务器会成为主服务器的客户端，并通过向主服务器发送命令请求来执行复制步骤，而在复制操作的后期，主从服务器会互相成为对方的客户端
主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致，而从服务器则通过向主服务器发送命令来进行心跳检测，以及命令丢失检测

Sentinel

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

启动并初始化Sentinel

启动一个Sentinel可以使用命令：

$ redis-sentinel /path/to/your/sentinel.conf
$ redis-server /path/to/your/sentinel.conf --sentinel

当一个Sentinel启动时，它需要执行以下步骤：

初始化服务器
将普通Redis服务器使用的代码替换成Sentinel专用代码
初始化Sentinel状态
根据给定的配置文件，初始化Sentinel的监视主服务器列表
创建连向主服务器的网络连接

初始化服务器

Sentinel本质上是一个运行在特殊模式下的Redis服务器，所以启动Sentinel的第一步，就是初始化一个普通的Redis服务器

但是由于Sentinel执行的工作和普通Redis服务器执行的工作不同，所以Sentinel的初始化过程和普通Redis服务器的初始化过程并不完全相同

例如：普通服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态，但是因为Sentinel并不使用数据库，所以初始化Sentinel时就不会载入RDB文件或者AOF文件

使用Sentinel专用代码

启动Sentinel的第二个步骤就是将一部分普通Redis服务器使用的代码替换成Sentinel专用代码

比如说，

普通Redis服务器使用redis. h/REDIS_SERVER PORT常量的值作为服务器端口

而Sentinel则使用sentinel. c/REDIS_SENTINEL PORT常量的值作为服务器端口

普通Redis服务器使用redis. c/redisCommandTable作为服务器的命令表

Sentinel则使用sentinel.c/sentinelcmds作为服务器的命令表，并且其中的INFO命令会使用 Sentinel 模式下的专用实现 sentinel.c/sentinelInfoCommand 函数，而不是普通Redis服务器使用的实现redis.c/infoCommand函数

初始化Sentinel状态

在应用了Sentinel的专用代码之后，服务器会初始化一个sentinel.c/sentinelState结构（后面简称“Sentinel状态”），这个结构保存了服务器中所有和Sentinel功能有关的状态（服务器的一般状态仍然由redis.h/redisServer结构保存）

struct sentinelState {
	//当前纪元，用于实现故障转移
    uint64_t current_epoch;
    
    //保存了所有被这个sentinel监视的主艰务器
    //字典的键是主艰务器的名字
    //字典的值则是一个指向sentinelRedisInstance结构的指针
    dict *masters;
    
    //是否进入了TILT模式？
    int tilt;
    
    //目前正在执行的脚本的数量
    int running一scripts;
    
    //逬入tilt模式的时间
    mstime_t tilt一start一time;
    
    //最后一次执行时间处理器的时间
    mstime_t previous_time;
    
    // 一个FIFO队列，包含了所有需要执行的用户脚本 
    list *scripts_queue;
    
} sentinel;

初始化Sentinel状态的masters属性

Sentinel状态中的masters字典记录了所有被Sentinel监视的主服务器的相关信息

字典的键是被监视主服务器的名字
而字典的值则是被监视主服务器对应的sentinel. c/sentinelRedisInstance结构

每个sentinelRedisInstance结构（后面简称“实例结构”）代表一个被Sentinel监视的Redis服务器实例，这个实例可以是主服务器、从服务器，或者另外一个Sentinel

typedef struct sentinelRedisInstance {
    
    // 标识值，记录了实例的类型，以及该实例的当前状态
    int flags;
    
    // 实例的名字
    // 主服务器的名字由用户在配置文件中设置 
    // 从服务器以及sentinel的名字由sentinel自动设置
    // 格式为ip:port,例如"127.0.0.1:26379"
    char *name;
    
    // 实例的运行ID?
    char *runid;
    
    // 配置纪元，用于实现故障转移
    uint64_t config_epoch;
    
    // 实例的地址
    sentinelAddr *addr;
    
    // SENTINEL down-after-milliseconds选项设定的值
    // 实例无响应多少毫秒之后才会被判断为主观下线(subjectively down )
    mstime_t down_after_period;
    
    // SENTINEL moni tor <master-name> <IP> <port>〈guoru/n〉选项中的 guoru/n 参数
    // 判断这个实例为客观下线{objectively down )所需的支持投票数量
    int quorum;
    
    // SENTINEL parallel-syncs <Master-name> <number>选项的值
    // 在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
    int parallel—syncs;
    
    // SENTINEL failover-timeout <master-name> 选项的值
    // 刷新故障迁移状态的最大时限
    mstime t failover timeout;
    //...
} sentinelRedisInstance;

创建连向主服务器的网络连接

初始化Sentinel的最后一步是创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，它可以向主服务器发送命令，并从命令回复中获取相关的信息

对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接

一个是命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复
一个是订阅连接，这个连接专门用于订阅主服务器的__ sentinel __:hello频道

为什么有两个连接？

在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丟失这条信息。因此，为了不丢失__ sentinel __:hello频道的任何信息，Sentinel必须专门用一个订阅连接来接收该频道的信息

另一方面，除了订阅频道之外，Sentinel还必须向主服务器发送命令，以此来与主服务器进行通信，所以Sentinel还必须向主服务器创建命令连接

因为Sentinel需要与多个实例创建多个网络连接，所以Sentinel使用的是异步连接

获取主服务器信息

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息

通过分析主服务器返回的命令回复，Sentinel可以获取以下两方面的信息：

一方面是关于主服务器本身的信息，包括run_id域记录的服务器运行ID，以及role域记录的服务器角色
一方面是关于主服务器属下所有从服务器的信息，每个从服务器都由一个"slave"字符串开头的行记录，每行的 ip= 域记录了从服务器的IP地址，而 port= 域则记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器

主服务器实例结构的flags属性的值为SRI_MASTER，而从服务器实例结构的flags属性的值为SRI_SLAVE

主服务器实例结构的name属性的值是用户使用Sentinel配置文件设置的，而从服务器实例结构的name属性的值则是Sentinel根据从服务器的IP地址和端口号自动设置的

获取从服务器信息

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接

在创建命令连接之后，Sentinel在默认情况下，会以每十秒一次的频率通过INFO命令连接向从服务器发送命令

根据INFO命令的回复，Sentinel会提取岀信息：

根据这些信息，Sentinel会对从服务器的实例结构进行更新

向主服务器和从服务器发送信息

在默认情况下，Seminel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令：

PUBLISH __sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"

这条命令向服务器的 __ Sentinel __:hello频道发送了一条信息，信息的内容由多个参数组成：

其中以s_ 开头的参数记录的是Sentinel本身的信息
而m_ 开头的参数记录的则是主服务器的信息。如果Sentinel正在监视的是主服务器，那么这些参数记录的就是主服务器的信息；如果Sentinel正在监视的是从服务器，那么这些参数记录的就是从服务器正在复制的主服务器的信息

接收来自主服务器和从服务器的频道信息

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅
连接，向服务器发送以下命令：

SUBSCRIBE __ sentinel __ :hello

Sentinel对__ sentinel __:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知，也会被用于更新其他Sentinel对被监视服务器的认知

更新 sentinels 字典

Sentinel为主服务器创建的实例结构中的sentinels字典保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料（与slaves类似，但是slaves是向master主动发送info命令解析得到的，而sentinel是被动接受的）

当一个Sentinel接收到其他Sentinel发来的信息时（我们称呼发送信息的Sentinel为源 Sentinel,接收信息的Sentinel为目标Sentinel )，目标Sentinel会从信息中分析并提取出以下两方面参数

与Seminel有关的参数：源Sentinel的IP地址、端口号、运行ID和配置纪元
与主服务器有关的参数：源Sentinel正在监视的主服务器的名字、IP地址、端口号和配置纪元

根据信息中提取出的主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中査找相应的主服务器实例结构，然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels字典

因为一个Sentinel可以通过分析接收到的频道信息来获知其他Sentinel的存在，并通过发送频道信息来让其他Sentinel知道自己的存在，所以用户在使用Sentinel的时候并不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentiriel可以自动发现对方

创建连向其他Sentinel的命令连接

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接，而新Sentinel也同样会创建连向这个Sentinel的命令连接，最终监视同一主服务器的多个Sentinel将形成相互连接的网络

Sentinel之间不会创建订阅连接？

Sentinel在连接主服务器或者从服务器时，会同时创建命令连接和订阅连接，但是在连接其他Sentinel时，却只会创建命令连接，而不创建订阅连接。这是因为Sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新Sentinel，所以才需要建立订阅连接，而相互已知的Sentinel只要使用命令连接来进行通信就足够了

检测主观下线状态

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

Sentinel 配置文件中的 down-after-milliseconds 选项指定了 Sentinel 判断实例进入主观下线所需的时间长度：如果一个实例在down-after-milliseconds毫秒内，连续向Sentinel返回无效回复，那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进人主观下线状态

检查客观下线状态

当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线）。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作

发送 SENTINEL is-master-down-by-addr 命令

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

询问其他Sentinel是否同意主服务器已下线

接收 SENTINEL is-master-down-by-addr 命令

当一个 Sentinel（目标 Sentinel）接收到另一个 Sentinel（源 Sentinel）发来的 SENTINEL is-master-down-by命时，目标Sentinel会分析并取出命令请求中包含的各个参数，并根据其中的主服务器IP和端口号，检査主服务器是否已下线，然后向源Sentinel返回一条包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复：

<down_state>
<leader_runid>
<leader_epoch>

接收 SENTINEL is-master-down-by-addr 命令的回复

根据其他 Sentinel 发回的 SENTINEL is-master-down-by-addr 命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量超过Sentinel配置中设置的quorum参数的值，Sentinel会将主服务器实例结构flags属性的SRI_O _DOWN标识打开，表示主服务器已经进入客观下线状态

选举领头Sentinel

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

选举规则：

所有在线的Sentinel都有被选为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel中的任意一个都有可能成为领头Sentinel
每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元( configuration epoch )的值都会自增一次。配置纪元实际上就是一个计数器
在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改
每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel 将自己设置为局部领头Sentinel
当一个 Sentinel (源 Sentinel )向另一个 Sentinel (目标 Sentinel)发送 SENTINELis-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头Sentinel
Sentinel设置局部领头Sentinel的规则是先到先得：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel,而之后接收到的所有设置要求都会被目标Sentinel拒绝
目标 Sentinel 在接收到 SENTINEL is-master-down_by-addr 命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元
源Sentinel在接收到目标Sentinel返回的命令回复之后，会检査回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID —致，那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel
如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel,那么这个Sentinel成为领头Sentinel
因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel，所以在一个配置纪元里面，只会出现一个领头 Sentinel
如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头Sentinel为止

故障转移

在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器
让已下线主服务器属下的所有从服务器改为复制新的主服务器
将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器

选出新的主服务器

向这个从服务器发送SLAVEOF no one命令，这个从服务器就会转换为主服务器

领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，按照以下规则，对列表进行过滤：

删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的
删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的
删除所有与已下线主服务器连接断开超过down-after-milliseconds * 10毫秒的从服务器：down-after-milliseconds选项指定了判断主服务器下线所需的时间，而删除断开时长超过down—after-milliseconds * 10毫秒的从服务器，则可以保证列表中剩余的从服务器保存的数据都是比较新的
根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器
如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器
如果有多个优先级最高、复制偏移量最大的从服务器，那么领头Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器

修改从服务器的复制目标

当新的主服务器岀现之后，领头Sentinel下一步要做的就是，让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送SLAVEOF命令来实现

将旧的主服务器变为从服务器

将已下线的主服务器设置为新的主服务器的从服务器（设置是保存在server1对应的实例结构里面的，当server1重新上线时，Sentinel就会向它发送SLAVEOF命令，让它成为server2的从服务器）

重点

Sentinel只是一个运行在特殊模式下的Redis服务器，它使用了和普通模式不同的命令表，所以Sentinel模式能够使用的命令和普通Redis服务器能够使用的命令不同
Sentinel会读入用户指定的配置文件，为每个要被监视的主服务器创建相应的实例结构，并创建连向主服务器的命令连接和订阅连接，其中命令连接用于向主服务器发送命令请求，而订阅连接则用于接收指定频道的消息
Sentinel通过向主服务器发送INFO命令来获得主服务器属下所有从服务器的地址信息，并为这些从服务器创建相应的实例结构，以及连向这些从服务器的命令连接和订阅连接
在一般情况下，Sentinel以每十秒一次的频率向被监视的主服务器和从服务器发送INFO命令，当主服务器处于下线状态，或者Sentinel正在对主服务器进行故障转移操作时，Sentinel向从服务器发送命令的频率会改为每秒一次
对于监视同一个主服务器和从服务器的多个Sentinel来说，它们会以每两秒一次的频率，通过向被监视服务器的__ sentinel __:hello频道发送消息来向其他Sentinel宣告自己的存在
每个Sentinel也会从__ sentinel __:hello频道中接收其他Sentinel发来的信息，并根据这些信息为其他Sentinel创建相应的实例结构，以及命令连接
Sentinel只会与主服务器和从服务器创建命令连接和订阅连接，Sentinel与Sentinel之间则只创建命令连接
Sentinel以每秒一次的频率向实例（包括主服务器、从服务器、其他Sentinel）发送PING命令，并根据实例对PING命令的回复来判断实例是否在线，当一个实例在指定的时长中连续向Sentinel发送无效回复时，Sentinel会将这个实例判断为主观下线
当Sentinel将一个主服务器判断为主观下线时，它会向同样监视这个主服务器的其他Sentinel进行询问，看它们是否同意这个主服务器已经进入主观下线状态
当Sentinel收集到足够多的主观下线投票之后，它会将主服务器判断为客观下线，并发起一次针对主服务器的故障转移操作

集群

节点

集群由多个节点构成，要组建一个真正可工作的集群，须将各个独立的节点连接起来，构成一个包含多个节点的集群

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

CLUSTER MEET <ip> <port>

向一个节点node发送CLUSTER MEET命令，可以让node节点与ip和port所指定的节点进行握手（handshake ），当握手成功时，node节点就会将ip和port所指定的节点添加到node节点当前所在的集群中

启动节点

一个节点就是一个运行在集群模式下的Redis服务器，Redis服务器在启动时会根据cluster-enabled配置选项是否为yes来决定是否开启服务器的集群模式

集群数据结构

clusterNode结构保存了一个节点的当前状态，每个节点都会使用一个clusterNode结构来记录自己的状态，并为集群中的所有其他节点（包括主节点和从节点）都创建一个相应的clusterNode结构，以此来记录其他节点的状态

struct clusterNode {
    
    //创建节点的时间
    mstime_t ctime;
    
    //节点的名字，由40个十六进制字符组成
    // 例如68eef66df23420a5862208ef5bla7005b806f2ff
    char name[REDIS_CLUSTER_NAMELEN];
    
    //节点标识
    //使用各种不同的标识值记录节点的角色（比如主节点或者从节点）,
    //以及节点目前所处的状态（比如在线或者下线）。
    int flags;
    
    //节点当前的配置纪元，用于实现故障转移
    uint64_t configEpoch;
    
    //节点的IP地址
    char ip[REDIS_IP_STR_LEN];
    
    //节点的端口号
    int port;
    
    //保存连接节点所需的有关信息
    clusterLink *link;
    // ...
};

clusterNode结构的link属性是一个clusterLink结构，该结构保存了连接节点所需的有关信息，比如套接字描述符，输入缓冲区和输出缓冲区

typedef struct clusterLink {
    
    //连接的创建时间
    mstime_t ctime;
    
    //TCP套接字描述符
    int fd;
    
    //输出缓冲区，保存着等待发送给其他节点的消息（message)。
    sds sndbuf;
    
    //输入缓冲区，保存着从其他节点接收到的消息。
    sds rcvbuf;
    
    //与这个连接相关联的节点，如果没有的话就为NULL
    struct clusterNode *node;
} clusterLink;

每个节点都保存着一个clusterState结构，这个结构记录了在当前节点的视角下，集群目前所处的状态，例如集群是在线还是下线，集群包含多少个节点，集群当前的配置纪元等

typedef struct clusterState {
    
    //指向当前节点的指针
    clusterNode *myself;
    
    //集群当前的配置纪元，用于实现故障转移
    uint64_t currentEpoch;
    
    //集群当前的状态：是在线还是下线
    int state;
    
    //集群中至少处理着一个槽的节点的数量
    int size;
    
    //集群节点名单(包括myself节点）
    //字典的键为节点的名字，字典的值为节点对应的clusterNode结构
    dict *nodes;
    // ...
} clusterState;

CLUSTER MEET 命令的实现

通过向节点A发送CLUSTER MEET命令，客户端可以让接收命令的节点A将另一个节点B添加到节点A当前所在的集群里面：

CLUSTER MEET <ip> <port>

收到命令的节点A将与节点B进行握手（handshake)，以此来确认彼此的存在，并为将来的进一步通信打好基础：

节点A会为节点B创建一个clusterNode结构，并将该结构添加到自己的clusterState. nodes 字典里面
之后，节点A将根据命令给定的IP地址和端口号，向节点B发送一条 MEET 消息（message）
如果一切顺利，节点B将接收到节点A发送的MEET消息，节点B会为节点A创建一个clusterNode结构，并将该结构添加到自己的clusterState . nodes字典里面
之后，节点B将向节点A返回一条PONG消息
如果一切顺利，节点A将接收到节点B返回的PONG消息，通过这条PONG消息节点A可以知道节点B已经成功地接收到了自己发送的MEET消息
之后，节点A将向节点B返回一条PING消息
如果一切顺利，节点B将接收到节点A返回的PING消息，通过这条PING消息节点B可以知道节点A已经成功地接收到了自己返回的PONG消息，握手完成

之后，节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点，让其他节点也与节点B进行握手，最终节点B会被集群中的所有节点认识

槽指派

Redis集群通过分片的方式来保存数据库中的键值对：集群的整个数据库被分为16384个槽（slot)，数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点可以处理0个或最多16384个槽

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

通过向节点发送命令，我们可以将一个或多个槽指派(assign)给节点负责：

CLUSTER ADDSLOTS <slot> [slot …]

记录节点的槽指派信息

clusterNode结构的slots属性和numslot属性记录了节点负责处理哪些槽：

struct clusterNode {
    // ...
    unsigned char slots[16384/8];
    int numslots;
    // ...
};

slots属性是一个二进制位数组，这个数组的长度为16384/8=2048个字节，共包含16384个二进制位

值为1代表是该节点负责处理的槽，时间复杂度为O(1)

传播节点的槽指派信息

一个节点还会将自己的slots数组通过消息发送给集群中的其他节点，以此来告知其他节点自己目前负责处理哪些槽

当节点A通过消息从节点B那里接收到节点B的slots数组时，节点A会在自己的clusterState.nodes字典中査找节点B对应的clusterNode结构，并对结构中的slots数组进行保存或者更新。因此，集群中的每个节点都会知道数据库中的16384个槽分别被指派给了集群中的哪些节点

记录集群所有槽的指派信息

空间换时间

clusterState结构中的slots数组记录了集群中所有16384个槽的指派信息：

typedef struct clusterState {
    clusterNode *slots[16384];
    // ...
} clusterState;

记录两次的原因

如果只将槽指派信息保存在各个节点的clusterNode. slots数组里，会出现一些无法高效地解决的问题，而clusterState.slots数组的存在解决了这些问题：

如果节点只使用clusterNode.slots数组来记录槽的指派信息，那么为了知道槽i是否已经被指派，或者槽i被指派给了哪个节点，程序需要遍历clusterState . nodes字典中的所有clusterNode结构，检查这些结构的slots数组，直到找到负责处理槽i的节点为止，这个过程的复杂度为O(N)，其中N为clusterState . nodes字典保存的clusterNode结构的数量
而通过将所有槽的指派信息保存在clusterState. slots数组里面，程序要检査槽i是否已经被指派，又或者取得负责处理槽i的节点，只需要访问clusterState.slots [i]的值即可，这个操作的复杂度仅为O(1)

但使用clusterNode结构的slots数组来记录单个节点的槽指派信息仍然是有必要的：

当程序需要将某个节点的槽指派信息通过消息发送给其他节点时，程序只需要将相应节点的clusterNode . slots数组整个发送出去就可以了
而单独使用clusterState.slots数组，每次要将节点A的槽指派信息传播给其他节点时，程序必须先遍历整个clusterState.slots数组，记录节点A负责处理哪些槽，然后才能发送节点A的槽指派信息，这比直接发送clusterNode.slots数组要麻烦和低效得多

clusterState.slots数组记录了集群中所有槽的指派信息，而clusterNode.slots数组只记录了clusterNode结构所代表的节点的槽指派信息

CLUSTER ADDSLOTS 命令的实现

def CLUSTER_ADDSLOTS (*all_input_slots):
    
    #遍历所有输入槽，检查它们是否都是未指派槽
    for i in all_input_slots:
    
        #如果有哪怕一个槽已经被指派给了某个节点
        #那么向客户端返回错误，并终止命令执行
        if clusterState.slots[i] != NULL:
            reply_error()
            return
    
    #如果所有输入槽都是未指派槽
    #那么再次遍历所有输入槽，将这些槽指派给当前节点
    for i in all_input_slots:
        
        #设置clusterState结构的slots数组
        #将slots[i]的指针指向代表当前节点的clusterNode结构
        clusterState.slots[i] = clusterState.myself
        
        #访问代表当前节点的clusterNode结构的slots数组
        #将数组在索引i上的二进制位设置为1
        setSlotBit(clusterState.myself.slots, i)

在集群中执行命令

在对数据库中的16384个槽都进行了指派之后，集群就会进人上线状态，这时客户端就可以向集群中的节点发送数据命令

当客户端向节点发送与数据库键有关的命令时，接收命令的节点会计算出命令要处理的数据库键属于哪个槽，并检查这个槽是否指派给了自己：

如果键所在的槽正好就指派给了当前节点，那么节点直接执行这个命令
如果键所在的槽并没有指派给当前节点，那么节点会向客户端返回一个MOVED错误，指引客户端转向（redirect）至正确的节点，并再次发送之前想要执行的命令

计算键属于哪个槽

计算方法：

def slot_number(key):
	return CRC16(key) & 16383

使用CLUSTER KEYSLOT<key>命令可以査看一个给定键属于哪个槽

判断槽是否由当前节点负责处理

当节点计算出键所属的槽i之后，节点就会检査自己在clusterState.slots数组中的项i，判断键所在的槽是否由自己负责：

如果 clusterState.slots [i]等于clusterState .myself，那么说明槽 i由当前节点负责，节点可以执行客户端发送的命令
反之，节点会根据clusterState.slots[i]指向的clusterNode结构所记录的节点IP和端口号，向客户端返回MOVED错误，指引客户端转向至正在处理槽i的节点

MOVED 错误

当节点发现键所在的槽并非由自己负责处理的时候，节点就会向客户端返回一个MOVED错误（在集群模式下MOVED错误会被隐藏），指引客户端转向至正在负责槽的节点

一个集群客户端通常会与集群中的多个节点创建套接字连接，而所谓的节点转向实际上就是换一个套接字来发送命令

节点数据库的实现

与单机Redis服务器保存键值对以及键值对过期时间的方式完全相同

区别：

节点只能使用0号数据库，而单机Redis服务器则没有这一限制
节点会用clusterState结构中的slots_to_keys跳跃表来保存槽和键之间的关系
```
typedef struct clusterState {
	// ...
    zskiplist *slots_to_keys;
	// ...
} clusterState;
```
slots_to_keys跳跃表每个节点的分值都是一个槽号，而每个节点的成员都是一个数据库键

重新分片

Redis集群的重新分片操作可以将任意数量已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且相关槽所属的键值对也会从源节点被移动到目标节点

重新分片操作可以在线（online）进行，在重新分片的过程中，集群不需要下线，并且源节点和目标节点都可以继续处理命令请求

重新分片的实现原理

Redis集群的重新分片操作是由Redis的集群管理软件redis-trib负责执行的，Redis提供了进行重新分片所需的所有命令，而redis-trib则通过向源节点和目标节点发送命令来进行重新分片操作

redis-trib 对目标节点发送 CLUSTER SETSLOT <slot> IMPORTING <source_id>命令，让目标节点准备好从源节点导入（import）属于槽slot的键值对
redis-trib对源节点发送 CLUSTER SETSLOT <slot> MIGRATING <target_id>命令，让源节点准备好将属于槽slot的键值对迁移（migrate）至目标节点
redis-trib 向源节点发送 CLUSTER GETKEYSINSLOT <slot> <count> 命令获得最多count个属于槽slot的键值对的键名（key name）

4)对于步骤3获得的每个键名，redis-trib都向源节点发送一个<target_ip> < target_port> <key_name> 0 <timeout>命令，将被选中的键原子地从源节点迁移至目标节点

重复执行步骤3和步骤4,直到源节点保存的所有属于槽slot的键值对都被迁移至目标节点为止
redis-trib 向集群中的任意一个节点发送 CLUSTER SETSLOT <slot> NODE <target_id>命令，将槽slot指派给目标节点，这一指派信息会通过消息发送至整个集群，最终集群中的所有节点都会知道槽slot已经指派给了目标节点

ASK 错误

在进行重新分片期间，源节点向目标节点迁移一个槽的过程中，可能会出现这样一种情况：属于被迁移槽的一部分键值对保存在源节点里面，而另一部分键值对则保存在目标节点里面

源节点会先在自己的数据库里面査找指定的键，如果找到.的话，就直接执行客户端发送的命令
相反地，如果源节点没能在自己的数据库里面找到指定的键，那么这个键有可能已经被迁移到了目标节点，源节点将向客户端返回一个ASK错误，指引客户端转向正在导入槽的目标节点，并再次发送之前想要执行的命令

CLUSTER SETSLOT IMPORTING 命令的实现

clusterState结构的importing_slots_from数组记录了当前节点正在从其他节点导入的槽

typedef struct clusterState {
    // ...
    clusterNode *importing_slots_from[16384];
    // ...
} clusterState;

如果 importing_slots_from[i]的值不为 NULL，而是指向一个clusterNode结构，那么表示当前节点正在从clusterNode所代表的节点导入槽i

如果客户端向节点7003发送以下命令：

# 9dfb...是节点7002的 ID
127.0.0.1:7003> CLUSTER SETSLOT 16198 IMPORTING 9dfb4c4e016e627d9769e4c9bb0d4fa208e65c26
OK

节点7003的 clusterState.importing_slots_from 数组将变成：

CLUSTER SETSLOT MIGRATING 命令的实现

clusterState结构的migrating_slots_to数组记录了当前节点正在迁移至其他节点的槽：

typedef struct clusterState {
    clusterNode *migrating_slots_to[16384];
    // ...
} clusterState;

如果migrating_slots_to[i]的值不为NULL,而是指向一个clusterNode结构，那么表示当前节点正在将槽i迁移至clusterNode所代表的节点

如果客户端向节点7002发送以下命令：

# 0457...是节点7003的 ID
127.0.0.1:7002> CLUSTER SETSLOT 16198 MIGRATING 04579925484ce537d3410d7ce97bd2e260c459a2
OK

那么节点7002的 clusterState . migrating_slots_to数组将变成：

ASK 错误

如果节点收到一个关于键key的命令请求，并且键key所属的槽i正好就指派给了这个节点，那么节点会尝试在自己的数据库里査找键key，如果找到了的话，节点就直接执行客户端发送的命令

与此相反，如果节点没有在自己的数据库里找到键key,那么节点会检査自己的clusterState.migrating_slots_to[i],看键key所属的槽i是否正在进行迁移，如果槽i的确在进行迁移的话，那么节点会向客户端发送一个ASK错误，引导客户端到正在导入槽i的节点去査找键key

接到ASK错误的客户端会根据错误提供的IP地址和端口号，转向至正在导入槽的目标节点，然后首先向目标节点发送一个ASKING命令，之后再重新发送原本想要执行的命令（是因为如果客户端不发送命令，而直接发送想要执行的命令的话，那么客户端发送的命令将被节点拒绝执行，并返回MOVED错误）

ASKING 命令

ASKING命令要做的就是打开发送该命令的客户端的REDIS_ASKING标识

def ASKING():
    #打开标识
	client.flags |= REDIS_ASKING

在一般情况下，如果客户端向节点发送一个关于槽i的命令，而槽i又没有指派给这个节点的话，那么节点将向客户端返回一个MOVED错误；但是，如果节点的clusterState. import ing_s lot s_from[ i ]显示节点正在导人槽i,并且发送命令的客户端带有REDIS_ASKING标识，那么节点将破例执行这个关于槽i的命令一次

ASK错误和MOVED错误的区别

MOVED错误代表槽的负责权已经从一个节点转移到了另一个节点：在客户端收到关于槽i的MOVED错误之后，客户端每次遇到关于槽i的命令请求时，都可以直接将命令请求发送至MOVED错误所指向的节点，因为该节点就是目前负责槽i的节点
ASK错误只是两个节点在迁移槽的过程中使用的一种临时措施：在客户端收到关于槽i的ASK错误之后，客户端只会在接下来的一次命令请求中将关于槽i的命令请求发送至ASK错误所指示的节点，但这种转向不会对客户端今后发送关于槽i的命令请求产生任何影响，客户端仍然会将关于槽i的命令请求发送至目前负责处理槽i的节点，除非ASK错误再次出现

复制与故障转移

Redis集群中的节点分为主节点(master)和从节点(slave),其中主节点用于处理槽，而从节点则用于复制某个主节点，并在被复制的主节点下线时，代替下线主节点继续处理命令请求

如果主节点下线，那么集群中仍在正常运作的几个主节点将在从节点中选择一个作为新的主节点，之前下线的主节点再上线，将成为从节点

设置从节点

向一个节点发送命令CLUSTER REPLICATE <node_id>，可以让接收命令的节点成为node_id所指定节点的从节点，并开始对主节点进行复制

接收到该命令的节点首先会在自己的clusterState.nodes字典中找到node_id所对应节点的clusterNode结构，并将自己的clusterState .myself.slaveof指针指向这个结构，以此来记录这个节点正在复制的主节点
```
struct clusterNode {

    //如果这是一个从节点，那么指向主节点
    struct clusterNode *slaveof;
    // ...
}
```
然后节点会修改自己在clusterState.myself.flags中的属性，关闭原本的REDIS_NODE_MASTER标识，打开REDIS_NODE_SLAVE标识，表示这个节点已经由原来的主节点变成了从节点
最后，根据clusterState.myself.slaveof指向的clusterNode结构所保存的IP地址和端口号，对主节点进行复制，相当于向从节点发送命令SLAVEOF <master_ip> <master_port>

一个节点成为从节点，并开始复制某个主节点这一信息会通过消息发送给集群中的其他节点，最终集群中的所有节点都会知道某个从节点正在复制某个主节点

struct clusterNode {
    //…
    
    //正在复制这个主节点的从节点数量
    int numslaves;
    
    // 一个数组
    // 每个数组项指向一个正在复制这个主节点的从节点的clusterNode结构
    struct clusterNode **slaves;
}

集群中的所有节点都会在代表主节点的clusterNode结构的slaves属性和numslaves属性中记录正在复制这个主节点的从节点名单

故障检测

集群中的每个节点都会定期地向集群中的其他节点发送PING消息，以此来检测对方是否在线，如果接收PING消息的节点没有在规定的时间内，向发送PING消息的节点返回PONG消息，那么发送PING消息的节点就会将接收PING消息的节点标记为疑似下线

当一个主节点A通过消息得知主节点B认为主节点C进入了疑似下线状态时，主节点A会在自己的clusterState.nodes字典中找到主节点C所对应的clusterNode结构，并将主节点B的下线报告（failure report)添加到clusterNode结构的fail_reports链表里面

struct clusterNode {
    // ...
    // 一个链表，记录了所有其他节点对该节点的下线报告
    list *fail_reports;
    // ...
}

struct clusterNodeFailReport {
    
    //报告目标节点已经下线的节点
    struct clusterNode *node;
    
    //最后一次从node节点收到下线报告的时间
    //程序使用这个时间戮来检查下线报告是否过期
    //(与当前时间相差太久的下线报告会被刪除)
    rostime_t time;
    
} typedef clusterNodeFailReport;

举个例子，如果主节点7001在收到主节点7002、主节点7003发送的消息后得知，主节点7002和主节点7003都认为主节点7000进入了疑似下线状态，那么主节点7001将为主节点7000创建图17-38所示的下线报告

如果在一个集群里面，半数以上负责处理槽的主节点都将某个主节点x报告为疑似下线，那么这个主节点x将被标记为已下线（FAIL），将主节点x标记为已下线的节点会向集群广播一条关于主节点X的FAIL消息，所有收到这条FAIL消息的节点都会立即将主节点x标记为已下线

故障转移

当一个从节点发现自己正在复制的主节点进入了已下线状态时，从节点将开始对下线主节点进行故障转移，以下是故障转移的执行步骤：

复制下线主节点的所有从节点里面，会有一个从节点被选中
被选中的从节点会执行SLAVEOF no one命令，成为新的主节点
新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己
新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽
新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

选举新的主节点

和选举领头Sentinel相似

消息

MEET消息：当发送者接到客户端发送的CLUSTER MEET发送者和接收者MEET命令时，发送者会向接收者发送MEET消息，请求接收者加入到发送者当前所处的集群里面
PING消息：集群里的每个节点默认每隔一秒钟就会从已知节点列表中随机选出五个节点，然后对这五个节点中最长时间没有发送过PING消息的节点发送PING消息，以此来检测被选中的节点是否在线。除此之外，如果节点A最后一次收到节点B发送的PONG消息的时间，距离当前时间已经超过了节点A的cluster-node-timeout选项设置时长的一半，那么节点A也会向节点B发送PING消息，这可以防止节点A因为长时间没有随机选中节点B作为PING消息的发送对象而导致对节点B的信息更新滞后
PONG消息：当接收者收到发送者发来的MEET消息或者PING消息时，为了向发送者确认这条MEET消息或者PING消息已到达，接收者会向发送者返回一条PONG消息。另外，一个节点也可以通过向集群广播自己的PONG消息来让集群中的其他节点立即刷新关于这个节点的认识
FAIL消息；当一个主节点A判断另一个主节点B已经进人FAIL状态时，节点A会向集群广播一条关于节点B的FAIL消息，所有收到这条消息的节点都会立即将节点B标记为已下线
PUBLISH消息：当节点接收到一个PUBLISH命令时，节点会执行这个命令，并向集群广播一条PUBLISH消息，所有接收到这条PUBLISH消息的节点都会执行相同的PUBLISH命令

消息头

MEET、PING、PONG 消息的实现

FAIL消息的实现

PUBLISH消息的实现

重点

节点通过握手来将其他节点添加到自己所处的集群当中
集群中的16384个槽可以分别指派给集群中的各个节点，每个节点都会记录哪些槽指派给了自己，而哪些槽又被指派给了其他节点
节点在接到一个命令请求时，会先检查这个命令请求要处理的键所在的槽是否由自己负责，如果不是的话，节点将向客户端返回一个MOVED错误，MOVED错误携带的信息可以指引客户端转向至正在负责相关槽的节点
对Redis集群的重新分片工作是由redis-trib负责执行的，重新分片的关键是将属于某个槽的所有键值对从一个节点转移至另一个节点
如果节点A正在迁移槽i至节点B，那么当节点A没能在自己的数据库中找到命令指定的数据库键时，节点A会向客户端返回一个ASK错误，指引客户端到节点B继续查找指定的数据库键
MOVED错误表示槽的负责权已经从一个节点转移到了另一个节点，而ASK错误只是两个节点在迁移槽的过程中使用的一种临时措施
集群里的从节点用于复制主节点，并在主节点下线时，代替主节点继续处理命令请求
集群中的节点通过发送和接收消息来进行通信，常见的消息包括MEET、PING、PONG、PUBLISH、FAIL 五种

整理于《Redis设计与实现》——黄建宏，侵删

熬粑马

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis设计与实现详解三：多机功能实现

复制在Redis中，用户可以通过执行命令或者设置slaveof选项，让一个服务器去复制（replicate）另一个服务器，我们称呼被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave）进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作“数据库状态一致”旧版复制功能的实现Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作：同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库
复制链接

扫一扫

专栏目录