Redis学习笔记---官方Cluster分区集群容灾解决方式

Redis学习笔记—官方Cluster分区集群容灾解决方式

1.容灾（failover）也可以叫故障迁移

2.容灾（failover）第一步—故障检测

1. 集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PING消息
2. 如果在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B标识为pfail。
3. A在后续发送ping时，会带上B的pfail信息， 通知给其他节点。
4. 如果B被标记为pfail的个数大于集群主节点个数的一半（N/2 + 1）时，B会被标记为fail，A向整个集群广播，该节点已经下线。
5. 其他节点收到广播，标记B为fail。

3.容灾（failover）第二步—从节点选举

1. 通过raft方式，每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。
2. slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选，master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。
3. slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。
4. 所有的Master开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 +1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。
5. RedisCluster失效的判定：
   1. 集群中半数以上的主节点都宕机（无法投票）
   2. 宕机的主节点的从节点也宕机了（slot槽分配不连续）

4.容灾（failover）第三步—变更通知

1. 当slave 收到过半的master 同意时，会成为新的master。此时会以最新的Epoch 通过PONG 消息广播自己成为master，让Cluster 的其他节点尽快的更新拓扑结构(node.conf)。

5.容灾（failover）第四步—主从切换（手动切换），自动切换：就是上面讲的从节点选举

1. 人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式(数据无丢失)将当前master节点和其中一个slave节点(执行cluster-failover的节点)交换角色
2. 向从节点发送cluster failover 命令（slaveof no one）
3. 从节点告知其主节点要进行手动切换（CLUSTERMSG_TYPE_MFSTART）
4. 主节点会阻塞所有客户端命令的执行（10s）
5. 从节点从主节点的ping包中获得主节点的复制偏移量
6. 从节点复制达到偏移量，发起选举、统计选票、赢得选举、升级为主节点并更新配置
7. 切换完成后，原主节点向所有客户端发送moved指令重定向到新的主节点
8. 以上是在主节点在线情况下：如果主节点下线了，则采用cluster failover force或cluster failover takeover 进行强制切换。

6.副本漂移

1. 我们知道在一主一从的情况下，如果主从同时挂了，那整个集群就挂了。
2. 为了避免这种情况我们可以做一主多从，但这样成本就增加了。
3. Redis提供了一种方法叫副本漂移，这种方法既能提高集群的可靠性又不用增加太多的从机。
4. 如图所示：
   
   Master1宕机，则Slaver11提升为新的Master1
   集群检测到新的Master1是单点的（无从机）
   集群从拥有最多的从机的节点组（Master3）中，选择节点名称字母顺序最小的从机（Slaver31）漂移
   到单点的主从节点组(Master1)。
5. 具体流程如下（以上图为例）：
   1、将Slaver31的从机记录从Master3中删除
   2、将Slaver31的的主机改为Master1
   3、在Master1中添加Slaver31为从节点
   4、将Slaver31的复制源改为Master1
   5、通过ping包将信息同步到集群的其他节点