《Redis设计与实现》第十七章总结三：集群之善后

继《Redis设计与实现》第十七章总结二：集群之运转

17.6 复制与故障处理

集群中节点分为主节点和从节点，主节点为之前讲解的处理槽的节点，从节点则用于复制某个主节点，确保在被复制的主节点下线时，能代替下线节点继续处理命令请求，达到高可用的目的

每个主节点可以有多个从节点，当某个从节点被选中为新的主节点时，其他从节点会从原来的复制节点改为复制新的主节点；原先的主节点重新上线后，会成为新的主节点的从节点

17.6.1 设置从节点的方法

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

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

接收到命令的节点发生的事情：

例子：7004复制7000

主节点发生的事情：记录其从节点

例子：7004、7005为7000的从节点

17.6.2 故障检测

执行的任务：

标记的地方为：发送节点clusterState.nodes中接收ping的节点的clusterNode结构的flasgs属性打开REDIS_NODE_PFAIL标识

集群中的各个节点会通过互相发送消息的方式来交换集群中各个节点的状态信息(在线、疑似下线、已下线)，记录在fail_reports属性中：

例子：7001收到7002、7003的消息，认为7000进入疑似下线状态，则7001为7000创建如图的下线报告

疑似下线变为已下线的情况和进行的处理：

例子：集群中有7000、7001、7002、7003，7002和7003都认为7000为疑似下线；此时7001也认为7000疑似下线，则7001检测到已达到半数以上，会将7000标记为已下线，并向集群广播一条关于7000的FAIL消息

17.6.3 故障转移

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

17.6.4 选举新的主节点

17.6.3的第一步：新的主节点是通过选举产生的：

算法类似选举领头Sentinel，都是基于Raft算法领头选举方法来实现的

17.7 消息

集群中的各个节点通过发送(发送者)和接收(接收者)消息来进行通信

一条消费由消息头和消息正文组成，节点发送的所有消息包括消息正文都由一个消息头包裹

消息正文的类型主要有五种：

17.7.1 消息头

cluster.h/clusterMsg结构：

clusterMsg的data属性指向cluster.h/clusterMsgData，为消息的正文：

clusterMsg的currentEpoch、sender、myslots属性：

例子：

17.7.2 MEET、PING、PONG消息的实现

这三种消息的正文都由两个cluster.h/clusterMsgDataGossip结构组成：

Gossip：Redis集群中的各个节点通过此协议来交换各自关于不同节点的状态信息，由MEET、PING、PONG三种消息实现

节点通过消息头的type属性来判断一条消息是MEET、PING还是PONG

发送MEET、PING、PONG消息时发送的事情：

clusterMsgDataGossip结构：

收到MEET、PING、PONG消息时发送的事情：

例子：集群有ABCDEF六个节点，测试发送接收PING和PONG

17.7.3 FAIL消息的实现

FAIL消息的正文由cluster.h/clusterMsgDataFail结构表示：

发送FAIL的情况：

单独设计，而不使用Gossip的原因：FAIL需要传播给所有节点，MEET、PING、PONG不需要

17.7.4 PUBLISH消息的实现

消息正文由cluster.h/clusterMsgDataPublish结构表示：

bulk_data数组的0到channel_len-1字节保存channel参数，channel_len到channel_len+message_len-1字节保存message参数

PUBLISH的过程：

例子：集群有7000、7001、7002、7003节点，客户端向7000发送PUBLISH命令

不直接向节点广播PUBLISH命令的原因：因为不符合集群的”各个节点通过发送和接收消息来进行通信“的规则