面试问Redis集群，被虐的不行了( 四 ) _Redis集群

执行过程：查看节点信息就可以看到 6386 这个节点已经成为了主机点。
当给从节点发送 cluster failover 指令后，从节点会给主节点发送 CLUSTERMSG_TYPE_MFSTART 包。从节点请求主节点停止访问，从而对比两者的数据偏移量达到一致。
这时客户端不会连接我们淘汰的主节点，同时主节点向从节点发送复制偏移量，从节点得到复制偏移量后故障转移开始，接着通知主节点进行配置切换。
当客户端在旧的 master 上解锁后，重新连接到新的主节点上。

文章插图

故障转移原理篇
上文中我们测试了故障转移，主节点下线后从节点变为主节点，接下来剖析这个过程。
①故障发现到确认
集群中的每个节点会定期的给其它节点发送 ping 消息，接收方用 pong 作为回复。
如果在 cluster-node-timeout 的时间内 ping 消息一直失败，则会把接收方的节点标记为 pfail 状态也就是主观下线。
这个下线状态是不是很熟悉?没错，这个跟哨兵判断主节点是否异常有点相似。
当一个哨兵发现主节点有问题时也会标记主节点客观下线(s_down) 。突然发现跑题了，尴尬......

文章插图

再提一下哨兵，当一个哨兵认为主节点异常后标记主观下线，但是其他哨兵怎么能会同意，不能你说什么就是什么。
都会去尝试连接异常的主节点，当半数以上的哨兵都认为主节点异常后会直接让其主节点客观下线。
同样集群也不会因为一个节点判断其状态为下线就行的，节点直接通过 Gossip 消息传播，集群中节点会不断收集故障节点的下线反馈并且存储到本地的故障节点下线报告中。
当有半数以上的集群主节点都标记为主观下线后改变状态为客观下线。最后向集群广播一条 fail 消息，通知所有节点将故障节点标记为客观下线。
例如：节点 A 发送 ping 到节点 B 通信异常后标记节点 B 为 pfail，之后节点 A 会继续给节点 C 发送 ping，并且携带节点 B 的 pfail 信息，然后节点 C 将节点 B 的故障保存到下线报告中。
当下线报告数量大于有哈希槽主节点的一半数量以上后就会尝试客观下线。
②故障恢复(从节点从此翻身奴隶把歌唱)
当故障节点被定义为客观下线后，故障节点的所有从节点承担故障恢复的责任。
故障恢复是从节点通过定时任务发现自己的主机点客观下线后就会执行故障恢复流程。
资格检查：所有的从节点都会进行检查与主节点最后的连接时间，断线时间大于 cluster-node-time*cluster-slave-validity-factor 时不具备故障转移的资格。
准备选举时间：先说说为什么这里会有一个准备选举时间。资格检查过后存在多个从节点，那么就需要使用不同的延迟选举时间来支持优先级。
这里的优先级就是以复制偏移量为基准，偏移量越大与故障主节点的延迟越小，那么就更有机会拥有替换主节点的机会。主要的作用就是确保数据一致性最好的节点优先发起选举。
选举投票：Redis 集群的投票机制没有采用从节点进行领导选举，这点切记不要跟哨兵搞混了。集群的投票机制都是持有槽的主机点进行投票的。
【面试问Redis集群，被虐的不行了】故障节点的从节点会广播一个 FAILOVER_AUTH_REQUEST 数据包给所有的持有槽的主节点请求投票。
当主节点回复 FAILOVER_AUTH_ACK 投票后在 NODE_TIMEOUT * 2 的这段时间不能给其他的从节点投票。从节点获取到半数以上的投票后就会进行故障恢复阶段。
故障转移：选举成功的从节点取消复制变为主节点，删除故障节点的槽，并且将故障节点的槽委托到自己身上，向集群广播自己的 pong 消息，通知主机点的改变和接管了故障节点的槽信息。
福利：你们想要的 SSH 的背景
上一篇利用两个夜晚才弄完的 Redis 哨兵文章，结果你们的关注点却不在文章本身，啊!小编心很痛......
为了满足大家的要求，我忍痛说一下如何设置亮瞎的背景，我使用的工具是xsheel 。