五、故障转移
1. 集群从节点下线
根据上文集群启动信息知道端口6383是6379的从节点。
接下来就是让6383下线查看6379的日志信息。
6379会报出连接6383丢失，并且给上标记fail，表示不可用。这个时候集群还是正常工作的。
总结：从节点下线对集群没有影响
当端口6383上线后，所有的节点会把fail的标记清除
2. 集群主节点下线
手动下线主节点6379，查看从节点6383日志信息
此时的6383节点会持续连接6379共计10次。那为什么是10次呢！
是根据我们配置的参数cluster-node-timeout 10来决定的，这里给我们一个信息就是一秒连接一次
直到时间到期后，开始故障转移。
这时6383在故障转移选举中胜任，翻身奴隶把歌唱，成为了主节点。
此时在查看一下集群的节点信息，命令cluster nodes。
会发现这里竟然存在四个主节点，但是其中一个主节点时下线状态
6379原主节点上线
6379上线后，同样所有的节点也会清除fail信息。
并且节点信息也会改变，此时的6379改变为6383的从节点。
3. 新增主节点
在新增俩个端口6385和6386
执行新增命令./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379，这里发送的就是meet消息
执行add-node命令，第一个参数为新节点的ip+端口 第二个参数为已存在集群中的节点。根据下图我们就可以看到新增的节点已经存在集群中了。
注意：虽说6385已经成为集群中的节点了，但是跟其它节点有区别。它没有数据，也就是没有哈希槽
接下来我们就需要把集群中的某些哈希槽分配到这个新节点上，分配结束后这个节点才会成为真正意义上的主节点
执行命令./redis-trib.rb reshard 127.0.0.1:6385
会提示转移多少个哈希槽并填写接收节点的id
最后一步询问是否从所有节点中转移：咔咔使用的是all
使用指令：cluster nodes查看，6385的这个节点就已经拥有三个范围的哈希槽了
主节点已经新增好了，接下来就需要给6385这个主节点配置一个从节点6386
命令：./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0.0.1:6385
master-id是6385的id，第一个参数为新节点的ip+端口 第二个为指定的主节点ip+端口
4. 手动故障迁移
当想对集群中的主节点进行升级的话可以手动执行故障转移到从节点，避免集群可用性受影响。
在从节点执行命令：cluster failover
执行过程
查看节点信息就可以看到6386这个节点已经成为了主机点。
当给从节点发送cluster failover 指令后，从节点会给主节点发送CLUSTERMSG_TYPE_MFSTART包。从节点请求主节点停止访问，从而对比两者的数据偏移量达到一致。
这时客户端不会连接我们淘汰的主节点，同时主节点向从节点发送复制偏移量,从节点得到复制偏移量后故障转移开始,接着通知主节点进行配置切换,当客户端在旧的master上解锁后重新连接到新的主节点上。
六、故障转移原理篇
上文中我们测试了故障转移，主节点下线后从节点变为主节点，接下来剖析这个过程。
1. 故障发现到确认
集群中的每个节点会定期的给其它节点发送ping消息，接收方用pong作为回复。
如果在cluster-node-timeout的时间内ping消息一直失败，则会把接收方的节点标记为pfail状态也就是主观下线。
这个下线状态是不是很熟悉。没错，这个跟哨兵判断主节点是否异常有点相似。当一个哨兵发现主节点有问题时也会标记主节点客观下线(s_down)。 突然发现跑题了，尴尬…
在提一下哨兵，当一个哨兵认为主节点异常后标记主观下线，但是其它哨兵怎么能会同意，不能你说什么就是什么。都会去尝试连接异常的主节点，当半数以上的哨兵都认为主节点异常后会直接让其主节点客观下线。
同样集群也不会因为一个节点判断其状态为下线就行的，节点直接通过Gossip消息传播，集群中节点会不断收集故障节点的下线反馈并且存储到本地的故障节点下线报告中。当有半数以上的集群主节点都标记为主观下线后改变状态为客观下线。
最后向集群广播一条fail消息，通知所有节点将故障节点标记为客观下线。
例如：节点A发送ping到节点B通信异常后标记节点B为pfail，之后节点A会继续给节点C发送ping并且携带节点B的pfail信息然后节点C将节点B的故障保存到下线报告中。当下线报告数量大于有哈希槽主节点的一半数量以上后就会尝试客观下线。
2. 故障恢复（从节点从此翻身奴隶把歌唱）
当故障节点被定义为客观下线后，故障节点的所有从节点承担故障恢复的责任。
故障恢复是从节点通过定时任务发现自己的主机点客观下线后就会执行故障恢复流程。
1. 资格检查
所有的从节点都会进行检查与主节点最后的连接时间，断线时间大于cluster-node-time*cluster-slave-validity-factor时不具备故障转移的资格。
2. 准备选举时间
先说说为什么这里会有一个准备选举时间。
资格检查过后存在多个从节点，那么就需要使用不同的延迟选举时间来支持优先级。这里的优先级就是
以复制偏移量为基准，偏移量越大与故障主节点的延迟越小，那么就更有机会拥有替换主节点的机会。
主要的作用就是确保数据一致性最好的节点优先发起选举
3.选举投票
redis集群的投票机制没有采用从节点进行领导选举，这点切记不要跟哨兵搞混了。集群的投票机制都是持有槽的主机点进行投票的。
故障节点的从节点会广播一个FAILOVER_AUTH_REQUEST 数据包给所有的持有槽的主节点请求投票。
当主节点回复FAILOVER_AUTH_ACK投票后在NODE_TIMEOUT * 2的这段时间不能给其它的从节点投票
从节点获取到半数以上的投票后就会进行故障恢复阶段
4. 故障转移
选举成功的从节点取消复制变为主节点
删除故障节点的槽，并且将故障节点的槽委托到自己身上
向集群广播自己的pong消息，通知主机点的改变和接管了故障节点的槽信息。
你们想要的ssh的背景！！！
一篇利用俩个夜晚才弄完的redis哨兵文章，结果你们的关注点却不在文章本身，啊！小编心很痛
为了满足大家的要求，咔咔忍痛说一下如何设置亮瞎的背景。
咔咔使用的工具是xsheel
打开工具选择选项
接着到查看有个窗口透明就可以设置xsheel透明了。
对喽！你想的没错这就是桌面背景，是不是准备开始设置去了。那设置完了回来再把文章看完好吗？咔咔也需要各路大神给予技术点补充和辨错。
