Redis集群模式之Redis Cluster（2）

        上篇文章我们讲解了Redis Cluster中的主要模块和两种重定向方式，这篇文章我们来讲解一下Redis Cluster的状态监测和维护。

Redis Cluster状态监测及维护

        要讲解Redis Cluster中节点的状态如何维护，我们要先知道Redis Cluster中的节点有哪些状态，gossip协议是什么以及具体的通讯（心跳）机制。

节点状态

        Redis Cluster中的每个节点都维护着一份在自己看来当前整个集群的状态，主要包括：

        （1）当前集群的状态；

        （2）集群中各节点所负责的Slots信息，及其migrate状态；

        （3）集群中各节点的Master-Slave状态；

        （4）集群中各节点的存活状态及不可达投票。

        当集群的状态发生变化时，比如新节点的加入、Slot迁移、节点宕机、新Master的出现等，我们希望这些变化尽快的被发现，传播到整个集群的所有节点并达成一致。节点之间相互的心跳（PING、PONG、MEET）及其携带的数据是集群状态传播最主要的途径。

gossip协议

        gossip协议又称为epidemic协议，是基于流行病传播方式的节点或进程之间信息交换的协议。在分布式系统中被广泛使用，比如我们可以使用gossip协议来确保网络中所有节点的数据一样。

        gossip协议已经是P2P网络中比较成熟的协议了。gossip协议的最大好处是，即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。这就允许Consul管理的集群规模能横向扩展到数千个节点。

        Redis集群是去中心化的，彼此之间状态同步靠gossip协议通信，集群的消息有以下几种类型：

        （1）Meet：通过cluster meet ip port命令，已有集群的节点会向新的节点发送邀请，加入现有集群。

        （2）Ping：节点每秒会向集群中其他节点发送Ping消息，消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等。

        （3）Pong：节点收到Ping消息后会回复Pong消息，消息中同样带有自己已知的两个节点消息。

        （4）Fail：节点Ping不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记为已下线。        

        集群中的每个节点都会定期地向集群中的其他节点发送PING消息，以此交换各个节点状态信息，检测各个节点的状态：在线状态、疑似下线状态PFAIL、已下线状态FAIL。

        当主节点A通过消息得知主节点B认为主节点D进入疑似下线状态时，主节点A会在自己的clusterState.nodes字典中找到主节点D所对应的clusterNode结构，并将主节点B的下线报告添加到clusterNode结构的fail_reports链表中，并后续关于节点D疑似下线的状态通过gossip协议通知其他节点。

        如果集群中，半数以上的主节点都将主节点D报告为下线状态，那么主节点D就被标记为已下线状态，将主节点D标记为已下线的节点会向集群广播主节点D的Fail消息，所有收到Fail消息的节点都会立即更新nodes里面主节点D的状态，标记为已下线。

        将node标记为FAIL需要满足一下两个条件：①有半数以上的主节点将node标记为PFAIL状态。②当前节点也将node标记为PFAIL状态。

通讯状态和维护

        什么时候进行心跳？

        Redis节点会记录其向每一个节点上一次发出ping和收到pong的时间，心跳发送时机与这两个值有关。通过下面的方式既能保证及时更新集群状态，又不至于使心跳次数过多：

        （1）每次Cron向所有未建立链接的节点发送ping或meet；

        （2）每1秒从所有已知节点中随机选取5个，向其中上次收到的pong最久远的一个发送ping。

        （3）每次Cron向收到pong超过timeout/2的节点发送pong；

        （4）收到ping或者meet，立即回复pong。

        发送哪些心跳数据？

        （1）Header：发送者自己的信息，包括所负责的slots信息、主从信息、ip port信息和状态信息。

        （2）gossip：发送者所了解的部分其他节点的信息，包括ping_sent,pong_received、ip,port信息、状态信息（比如发送者认为该节点已经不可达，会在状态信息中标记其为PFAIL或FAIL）。

        如何处理心跳数据？

        （1）新节点的加入。发送meet包加入集群，从pong包中的gossip得到未知的其他节点。通过循环上述过程，直到最终加入集群。

        （2）slots信息。判断发送者声明的slots信息，跟本地记录的是否有不同。如果不同，并且发送者epoch较大，更新本地记录；如果不同，并且发送者epoch比较小，发送update信息通知发送者。

        （3）Master slave信息。发现发送者的master、slave信息变化，更新本地状态。

        （4）节点FAIL探测（故障发现）。超过超时时间仍然没有收到pong包的节点会被当前节点标记为PFAIL；PFAIL标记会随着gossip传播；每次收到心跳包会检测其中对其他节点的PFAIL标记，当做对该节点FAIL的投票维护在本机；对某个节点的PFAIL标记达到大多数时，将其变为FAIL标记并广播FAIL消息。

        gossip的存在使得集群状态的改变可以更快的达到整个集群。每个心跳包中会包含多个gossip包，那么多少个才是合适的呢，Redis的选择是N/10，其中N是节点数，这样可以保证在PFAIL投票的过期时间内，节点可以收到80%机器关于失败节点的gossip，从而使其顺利进入Fail状态。

        如何将信息广播给其它节点？

        当需要发布一些非常重要需要立即送达的消息时，上述心跳+gossip的方式就显得捉襟见肘了，这时就需要向所有集群内的机器广播信息，使用广播发的场景：

        节点的Fail信息：当发现某一节点不可达时，探测节点会将其标记为PFAIL状态，并通过心跳传播出去。当某一节点发现这个节点的PFAIL超过半数时修改其为FAIL并发起广播。

        Failover Request信息：slave尝试发起FailOver时广播其要求投票的信息。

        新Master信息：Failover成功的节点向整个集群广播自己的信息。

故障恢复

        当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的Master。由于挂掉的Master可能会有多个Slave。Failover的过程需要经过类Raft协议的过程在整个集群内达到一致，具体的过程如下：

        （1）Slave发现自己的Master变为FAIL；

        （2）将自己记录的集群currentepoch+1，并广播Failover Request信息；

        （3）其他节点收到该消息，只有Master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack；

        （4）尝试Failover的Slave收集FAILOVER_AUTH_ACK；

        （5）超过半数后变为新Master；

        （6）广播Pong通知其他集群节点。

        这篇文章我们主要讲解了Redis Cluster的状态监测和维护，大家有什么问题或勘误可以在评论区留言，笔者看到都会回复的。