redis学习笔记之十一：集群的故障判断及故障恢复

n 故障判定
1：集群中每个节点都会定期向其他节点发出ping命令，如果没有收到回复，就认为
该节点为疑似下线，然后在集群中传播该信息
2：当集群中的某个节点，收到半数以上认为某节点已下线的信息，就会真的标记该
节点为已下线，并在集群中传播该信息
3：如果已下线的节点是master节点，那就意味着一部分插槽无法写入了
4：如果集群任意master挂掉，且当前master没有slave，集群进入fail状态
5：如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态
6：当集群不可用时，所有对集群的操作做都不可用，收到CLUSTERDOWN The
cluster is down错误信息
n 故障恢复
发现某个master下线后，集群会进行故障恢复操作，来将一个slave变成master，基
于Raft算法，大致步骤如下：
1：某个slave向集群中每个节点发送请求，要求选举自己为master
2：如果收到请求的节点没有选举过其他slave，会同意
3：当集群中有超过节点数一半的节点同意该slave的请求，则该Slave选举成功
4：如果有多个slave同时参选，可能会出现没有任何slave当选的情况，将会等待一个随机时
间，再次发出选举请求
5：选举成功后，slave会通过 slaveof no one命令把自己变成master
如果故障后还想集群继续工作，可设置cluster-require-full-coverage为no，默认yes
n 对于集群故障恢复的说明
1：master挂掉了，重启还可以加入集群，但挂掉的slave重启，如果对应的master变化了，是
不能加入集群的，除非修改它们的配置文件，将其master指向新master
2：只要主从关系建立，就会触发主和该从采用save方式持久化数据，不论你是否禁止save
3：在集群中，如果默认主从关系的主挂了并立即重启，如果主没有做持久化，数据会完全丢
失，从而从的数据也被清空