Redis集群之复制、故障转移及消息实现

        在Redis集群实现原理一节，我们介绍了 Redis 集群的实现细节，以及所使用的主要数据结构，本节将对集群节点的复制方法，检测节点是否下线的方法，以及对下线主节点进行故障转移的方法一一进行探讨。
        Redis 集群中的节点分为主节点（master）和从节点（slave），其中主节点用于处理槽，而从节点则用于复制某个主节点，并在被复制的主节点下线时，代替下线主节点继续处理命令请求。

        设置从节点
        向一个节点发送“CLUSTER REPLICATE <node_id>”命令，可以让接收命令的节点成为 node_id 所指定节点的从节点，并开始复制主节点：
        * 接收到该命令的节点首先会将自己的 clusterState.myself.slaveof 指针指向 clusterState.nodes 字典中 node_id 所对应节点的 clusterNode 结构，以此记录这个节点正在复制的主节点。
        * 然后节点会修改自己在 clusterState.myself.flags 中的属性，关闭原本的 REDIS_NODE_MASTER 标识（如果设置），并打开 REDIS_NODE_SLAVE 标识，表示这个节点已经由原来的主节点变成了从节点。
        * 最后，节点会根据 slaveof 指向的 clusterNode 结构中的 IP 和端口，调用复制代码对主节点进行复制。因为节点的复制功能和单机 Redis 服务器的复制功能（见数据库复制一节）使用了相同的代码，所以让从节点复制主节点相当于向从节点发送命令“SLAVEOF <master_ip> <master_port>”。
        一个节点成为从节点，并开始复制某个主节点这一信息会通过消息发送给集群中的其他节点。集群中的所有节点都会在代表主节点的 clusterNode 结构的 slaves 和 numslaves 属性中记录正在复制这个主节点的从节点名单。

        故障检测和故障转移
        集群中的每个节点都会定期地向其他节点发送 PING 消息，以此来检测对方是否在线。如果接收 PING 消息的节点没有在规定的时间内返回 PONG 消息，则发送 PING 消息的节点就会将其标记为疑似下线（probable fail，PFAIL），具体为在自己的 clusterState.nodes 字典中找到对方的 clusterNode 结构，然后打开其中 flags 属性中的 REDIS_NODE_PFAIL 标识，以表示该节点进入了疑似下线状态。
        集群中的各个节点会通过互相发送消息的方式来交换集群中各个节点的状态信息。当一个主节点 A 通过消息得知主节点 B 认为主节点 C 进入了疑似下线状态时，主节点 A 会在自己的 clusterState.nodes 字典中找到 C 所对应的 clusterNode 结构，并将主节点 B 的下线报告添加到其中的 fail_reports 链表里面。每个下线报告由一个 clusterNodeFailReport 结构表示。

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

        如果在一个集群里面，半数以上负责处理槽的主节点都将某个主节点 X 报告为疑似下线，则该主节点 X 将被标记为已下线（FAIL），将主节点 X 标记为以下线的节点会向集群广播一条关于主节点 X 的 FAIL 消息，所有收到这条消息的节点（包括从节点）都会立即将主节点 X 标记为已下线。
        当一个从节点发现自己正在复制的主节点进入了已下线状态时，从节点将开始对下线主节点进行故障转移，执行步骤如下：
        1）从下线主节点的所有从节点里面选举一个来执行“SLAVEOF no noe”命令，成为新的主节点。
        2）新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己。
        3）新的主节点向集群广播一条 PONG 消息，以告知集群中的其他节点，自己已经由从节点变成了主节点，并且已经接管了原本由已下线主节点复杂处理的槽。
        4）新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

        消息
        集群中的各个节点通过发送和接收消息来进行通信，比如前面提到的 MEET、PING、PONG、FAIL 和 PUBLISH 等消息。一条消息由消息头和消息正文组成。
        消息头除了包含消息正文之外，还记录了消息发送者自身的一些信息。每个消息头都由一个 clusterMsg 结构表示：

typedef struct {
    uint32_t totlen;        // 消息的长度，包括消息头和消息正文
    uint16_t type;          // 消息的类型
    // 消息正文包含的节点信息数量，只在发送 MEET、PING、PONG 这三种 Gossip 协议消息时使用
    uint16_t count;

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

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

    char sender[REDIS_CLUSTER_NAMELEN];    // 发送者的名字（ID）
    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;   // 发送者所处集群的状态

    union clusterMsgData data;    // 消息的正文
}clusterMsg;

union clusterMsgData{
    struct {
        clusterMsgDataGossip gossip[2];
    } ping;                // MEET、PING、PONG 消息的正文

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

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

    /* 其他消息的正文 */
};

typedef struct {
    char nodename[REDIS_CLUSTER_NAMELEN];    // 节点的名字
    uint32_t ping_sent;    // 最后一次向该节点发送 PING 消息的时间戳
    uint32_t pong_sent;    // 最后一次从该节点收到 PONG 消息的时间戳
    char ip[16];           // 节点的 IP
    uint16_t port;         // 节点的端口号
    uint16_t flags;        // 节点的标识值
} clusterMsgDataGossip;

typedef struct {
    char nodename[REDIS_CLUSTER_NAMELEN];   // 已下线节点的名字
} clusterMsgDataFail;

typedef struct {
    uint32_t channel_len;        // channel 参数的长度
    uint32_t message_len;        // message 参数的长度

    // 该字节数组保存了客户端通过 PUBLISH 命令发送的 channel 和 message 参数
    // 定义为 8 字节只是为了对齐其他消息结构
    // 实际的长度由保存的内容决定
    // channel 参数的内容是前 channel_len 字节
    // message 参数的内容则是 channel+message_len-1 字节
    unsigned char bulk_data[8];
} clusterMsgDataPublish;

        clusterMsg 结构的 currentEposh、sender、myslots 等属性记录了发送者自身的节点信息，接收者会根据这些消息，在自己的 clusterState.nodes 字典里找到发送者对应的 clusterNode 结构来更新相关信息。比如，通过对比接收者为发送者记录的槽指派信息和发送者在消息头的 myslots 属性记录的槽信息，接收者可以知道发送者的槽指派信息是否发生了变化。
        每次发送 MEET、PING 和 PONG 消息时，发送者都从自己的已知节点列表中随机选出两个节点（可以是主节点或者从节点），并将它们的信息分别保存到两个 clusterMsgDataGossip 结构里面。当接收者收到这三种消息时，它会访问消息正文中的两个 clusterMsgDataGossip 结构，并根据自己是否认识其中的节点来选择进行哪种操作：
        * 如果被选中的节点不存在于接收者的已知节点列表，则说明接收者是第一次接触到被选中节点，接收者将与之进行握手。
        * 如果被选中的节点已经存在于接收者的已知节点列表，则说明两者之前已经接触过，接收者将根据 clusterMsgDataGossip 结构记录的信息来更新被选中节点所对应的 clusterNode 结构。
        对于 FAIL 消息，在集群的节点数量比较大的情况下，单纯使用 Gossip 协议来传播节点的已下线信息会给节点的信息更新带来一定的延迟，因为 Gossip 协议消息通常需要一段时间才能传播至整个集群，而发送 FAIL 消息可以让集群里的所有节点立即知道某个主节点已下线，从而尽快判断是否需要将集群标记为下线，又或者对下线主节点进行故障转移。
        当客户端向集群中的某个节点发送命令“PUBLISH <channel> <message>”时，接收到 PUBLISH 命令的节点不仅会向 channel 频道发送消息 message，它还会向集群广播一条 PUBLISH 消息，所有接收到这条消息的节点都会向 channel 频道发送 message 消息（集群中之所以没有像在复制 PUBLISH 命令时采用广播 PUBLISH 命令的方式通知所有节点，主要是为了符合 Redis 集群的“各个节点通过发送和接收消息来进行通信”这一原则）。


参考书籍：
1、《Redis设计与实现》第17章——集群。