RAFT算法

RAFT算法：

RAFT算法引用原文论文翻译的第一句话：RAFT是一种为了管理复制日志的一致性算法(https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md)。

同样RAFT算法中也先引入几个角色和概念：

Leader：领导者

Follower：群众

Candidate：竞选者

Term：任期

构建一个现实的环境场景来帮助理解，在一个封闭网络中，有多个分布式节点，节点间开始权利和义务一样，互相平等，然后通过一种投票的模式：

首先所有节点都是群众，开始投票，所有群众可以参与投票也可以参与竞选，参与竞选的群众就变成了竞选者，然后选择领导者，对领导者有一个任期的概念，在选举结束后，领导者开始任期，之前候选人变成群众，直到第二期选举开始。 

从角色角度来看：群众-竞选者-领导者在选举过程中不停变化。 

每个节点的角色随着投票选举过程一直在群众-竞选者-领导者-群众之间转换。

再细分下整个过程：

领导者的选举过程

所有网络中的节点，一开始都是群众，投票开始节点A、B、C等节点都转变为竞选者，这里会有一个问题，之前有个朋友也问过我，每个人都投自己那么这个领导者怎么出来，这个环节其实很有意思，每个人投票开始时间不同，那么都有一个超时时间的控制，一旦出现超时还没有选出领导者，那么超时部分节点就变成了群众，他就必须在随机休息一段时间、再次投票就只能去投其他的竞选者，这个问题也就解决了。这样的模式下来领导者很快就能出现。

领导者在整个系统中用来确保分布式集群的一致性，客户终端发送请求至领导者，领导者接受一个未确认信息、然后把未确认信息发送给群众节点，收集群众节点的返回信息，一旦超过半数节点返回，领导者再发送信息给客户端，确认信息，确认信息后，领导者再发送确认信息给群众节点，确保信息一致。 

选出领导者后，那么领导者一直和网络中其他节点进行心跳通信，一旦一段时间内领导者没有发出通信，那么就认为领导者出现不确定故障（主机宕机、网络故障等），那么就再发起一轮新的选举。

再假设几个场景：

1.领导者在接收客户端消息的时候出现故障。这个时候领导者和客户端就失去联系，客户端认为超时，那么领导者上没有数据，同样群众节点也就不会有数据，这个时候确定领导者出现问题就执行再次选举操作。

2.客户端数据到达领导者，领导者发送到至群众节点，群众节点数据一致，但是这时候领导者出现故障，那么这时候即刻进行领导者选举，客户端这时候虽然不知道数据是否递交成功，但是可以尝试重新提交，这时候RAFT通过内部去重方式保证一致性。

3.数据到达领导者，领导者部分发送成功给群众节点，领导者出现故障，那么RAFT模式要求投票选举时候只能拥有最新的数据的节点才能成为竞选者，新的领导者出现数据再次同步，保证一致性。

4.数据到达领导者，发送给群众节点，领导者已提交确认，但是群众节点未全部确认，那么这时候同样2的方法处理重新选举，去重后再保证一致性。

5.数据到达领导者，发送给群众节点，所有节点提交，但是领导者未响应客户端，这个时候其实数据已经一致，故可重复操作无影响。

6.网络脑裂出现双领导者，这种方式下会出现两个领导者分区，但是多数原则保证有一个领导者会提交不成功，所有只能等待网络恢复，更新TERM后，领导者降级后在同步数据一致性。

最后对选择过程中的时间再说明：

选举过程是有一个时间限制，就像上文说到一直自己投自己情况如何控制，选择过程中有超时时间设定，然后中间会有一个分裂投票的概念（split vote），这个时候两个竞争者都要求大家投票给自己，两个竞争者在选举时间内得到相同的票，那就再发起投票，在一段时间内只对两个竞争者发起投票，首先发起的理论上得到更多的同意，那么另外一个就称为群众。

简单对RAFT算法做了一个说明，想要深入了解的可以查一下网址：https://raft.github.io/