Redis中的集群(九)

集群

消息

集群中的各个节点通过发送和接收消息(message)来进行通信，我们称发送消息的节点为发送者(sender),接收消息
的节点成为接收者，如图所示。节点发送的消息主要有以下五种:

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

一条消息由消息头(header)和消息正文(data)组成

消息头

节点发送的所有消息都由一个消息头包裹，消息头除了包含消息正文之外，还记录了消息发送者自身的一些信息，因为这些信息也会被消息接收者用到，所以严格来讲，可以认为消息头本身也是消息的一部分。
每个消息头都由一个cluster.h/clusterMsg结构表示clusterMsg.data属性指向联合cluster.h/clusterMsgData，这个联合就是消息的正文:
clusterMsg结构的currentEpoch、sender、myslots等属性记录了发送者自身的节点信息，接收者会根据这些信息在自己的clusterState.nodes字典里找到发送者对应的clusterNode结构，并对结构进行更新

例子

举个例子，通过对比接收者为发送者记录的槽指派信息，以及发送者在消息头的myslots属性记录的槽指派信息，接收者可以知道发送者的槽指派信息是否发生了变化，又或者说，通过对比接收者为发送者记录的标识值，以及发送者在消息头的flags属性记录的标识值，接收者可以知道发送者的状态和角色是否发生了变化，例如节点状态由原来的在线变成了下线，或者由主节点变成了从节点等等

clusterMsg结构表示

typedef struct {
// 消息的长度(包括这个消息头的长度和消息正文的长度)
uint32_t totlen;

// 消息的类型
uint16_t type;

// 消息正文包含的节点信息数量
// 只在发送MEET、PING、PONG这三种Gossip协议信息时使用
uint16_t count;

// 发送者所处的纪元
uint64_t currentEpoch;

// 如果发送者是一个主节点，那么这里记录的是发送者的配置纪元
// 如果发送者是一个从节点，那么这里记录的是发送者正在复制的主节点的配置纪元
uint64_t configEpoch;

// 发送者的名字(id)
char sender[REDIS_CLUSTER_NAMELEN];

// 发送者目前的槽指派信息
unsigned char myslots[REDIS_CLUSTER_SLOTS/8];
// 如果发送者是一个从节点，那么这里记录的是发送者正在复制的主节点的名字
// 如果发送者是一个主节点，那么这里记录的是REDIS_NODE_NULL_NAME
char slaveof[REDIS_CLUSTER_NAMELEN];
// 发送者的端口号
uint16_t port;
// 发送者的标识值
uint16_t flags;

// 发送者所处集群的状态
unsigned char state;
// 消息的正文(或者说，内容)
unio clusterMsgData data;
}clusterMsg;

clusterMsgData表示

union clusterMsgData {
struct {
// MEET、PING、PONG消息都包含两个clusterMsgDataGossip结构
clusterMsgDataGossip gossip[1];
} ping;

// FAIL消息的正文
struct {
clusterMsgDataFail abount;
}fail;

// PUBLISH消息的正文
struct {
clusterMsgDataPublish msg;
}publish;

// 其他消息正文...
}

MEET、PING、PONG消息的实现

Redis集群中的各个节点通过Gossip协议来交换各自不同节点的状态信息，其中Gossip协议由MEET、PING、PONG三种消息实现，这三种消息的正文都由两个cluster.h/clusterMsgDataGossip结构组成:

union clusterMsgData {
// ...
// MEET、PING和PONG消息的正文
struct {
// 每条MEET、PING、PONG消息都包含两个
// clusterMsgDataGossip结构
clusterMsgDataGossip gossip[1];
}ping
};

因为MEET、PING、PONG三种消息都由相同的消息正文，所以节点通过消息头的type属性来判断一条消息是MEET消息、PING消息和PONG消息。每次发送MEET、PING、PONG消息时，发送者都从自己的已知节点列表中随机选出两个节点(可以是这个主节点或者从节点)，并将这两个被选中节点的信息分别保存到两个clusterMsgDataGossip结构里面。
clusterMsgDataGossip结构记录了被选中节点的名字，发送者与被选中节点最后一次发送和接收PING消息和PONG消息的时间戳，被选中节点的IP地址和端口号，以及被选中节点的标识值:

typedef struct {
// 节点的名字
char nodename[REDIS_CLUSTER_NAMELEN];
// 最后一次向该节点发送PING消息的时间戳
uint32_t ping_sent;
// 最后一次从该节点接收到PONG消息的时间戳
uint32_t pong_received;

// 节点的IP地址
char ip[16];
// 节点的端口号
uint16_t port;
// 节点的标识值
uint16_t flags;
}clsterMsgDataGossip

当接收者收到MEET、PING、PONG消息时，接收者会访问消息正文中的两个clusterMsgDataGossip结构，并根据自己是否认识clusterMsgDataGossip结构中记录的被选中节点来选择进行哪种操作:

1.如果被选中节点不存在于接收者的已知节点列表，那么说明接收者是第一次接触到被选中节点，接收者将根据结构中记录的IP地址和端口号等信息，与被选中节点进行握手.
2.如果被选中节点已经存在与接收者的已知节点列表，那么说明接收者之前已经被选中节点进行过接触，接收者将根据clusterMsgDataGossip
结构记录的信息，对被选中节点所对应的clusterNode结构进行更新

例子

举个发送PING消息和返回PONG消息的例子，假设在一个包含A、B、C、D、E、F六个节点的集群里:
1.节点A向节点D发送PING消息，并且消息里面包含了节点B和节点C信息，当节点D接收到这条信息,它将更新自己对节点B和节点C的认知
2.之后，节点D将向节点A返回一条PONG消息，并且消息里面包含了节点E和节点F的消息，当节点A接收到这条PONG消息时，它将更新自己对节点E和节点F的认知。