故障处理流程

1) 故障判定

集群中的所有节点，都会周期性地使用心跳包进行通信

1. 节点A给节点B发送ping包，B就会给A返回一个pong包。ping和pong除了message type属性之外，其他部分都是一样的。这里包含了集群的配置信息（该节点的id，该节点从属于哪个分片，是主节点还是从节点，从属于谁，持有哪些slots的位图等）
2. 每个节点，每秒钟，都会给一些随机的节点发起ping包，而不是全发一遍

这样设定是为了避免在节点很多的时候，心跳包也非常多（比如有9个节点，如果全发，就是9*8有72组心跳了，而且这是按照N²这样的级别增长的）

3. 当节点A给节点B发起ping包，B不能如期回应的时候，此时A就会尝试重置和B的tcp连接，看能否连接成功。如果仍然连接失败，A就会把B设为PFAIL状态（相当于主观下线）。

4. A判定B为PFAIL之后，会通过redis内置的Gossip协议，和其他节点进行沟通，向其他节点确认B的状态。

每个节点都会维护一个自己的“下线列表”，由于视角不同，每个节点的下线列表也不一定相同

5. 此时A发现其他很多节点，也认为B为PFAIL，并且数目超过总集群个数的一半，那么A就会把B标记成FAIL（相当于客观下线），并且把这个消息同步给其他节点（其他节点收到之后，也会把B标记成FAIL）。

至此，B就彻底被判定为故障节点了。

集群宕机（称为fail状态）

某个或者某些节点宕机，有的时候会引起整个集群都宕机（称为fail状态）。

以下三种情况会出现集群宕机：

• 某个分片，所有的主节点和从节点都挂了。
• 某个分片，主节点挂了，但是没有从节点。
• 超过半数的master节点都挂了。

2) 故障迁移

上述例子中，B故障，并且A把B FAIL的消息告知集群中的其他节点。

• 如果B是从节点，那么不需要进行故障迁移。
• 如果B是主节点，那么就会由B的从节点（比如C和D）触发故障迁移了。

所谓故障迁移，就是指把从节点提拔成主节点，继续给整个redis集群提供支持。

具体流程：

1. 从节点判定自己是否具有参选资格。如果从节点和主节点已经太久没通信（此时认为从节点的数据和主节点差异太大了），时间超过阈值，就失去竞选资格。
2. 具有资格的节点，比如C和D，就会先休眠一定时间。休眠时间=500ms基础时间+[0,500ms]随机时间+排名*1000ms。offset的值越大，则排名越靠前（越小）。
3. 比如C的休眠时间到了，C就会给其他所有集群中的节点，进行拉票操作。但是只有主节点才有投票资格。
4. 主节点就会把自己的票投给C（每个主节点只有1票）。当C收到的票数超过主节点数目的一半，C就会晋升成主节点。（C自己负责执行slaveof no one，并且让D执行slaveof C）。
5. 同时，C还会把自己成为主节点的消息，同步给其他集群的节点。大家也都会更新自己保存的集群结构信息。

上述选举的过程，称为Raft算法，是一种在分布式系统中广泛使用的算法。

集群扩容

分布式的本质，其实就是使用更多的机器，引入更多的硬件资源

第一步：把新的主节点加入到集群

第二步：重新分配slots

执行之后，会进入交互式操作，redis会提示用户输入以下内容：

• 多少个slots要进行reshard？（如填写4096）
• 哪个节点来接收这些slots？（如填写172.30.0.110这个节点的集群节点id）
• 这些slots从哪些节点搬运过来？（如填写all，表示从其他所有的节点都进行搬运）

确定之后，会初步打印出搬运方案，让用户确认。之后就会进行集群的key搬运工作

第三步：给新的主节点添加从节点

光有主节点了，此时扩容的目标已经初步达成。但是为了保证集群可用性，还需要给这个新的主节点添加从节点，保证该主节点宕机之后，有从节点能够顶上