分布式---raft算法

1、Leader的选举和Failover过程

首先了解raft中节点的三种状态：

1、Follower：Follower是请求的被动更新者，从Leader接收更新请求，将日志写入到本地文件
2、Candidate:如果Follower在一定时间内，如果每收到Leader的心跳，则判断Leader可能已经发生了故障，此时启动Leader Election过程，本节点切换为Candidate,值到选主节点结束
3、Leader：所有请求的处理者，接收客户端发起的操作请求，写入本地日之后，同步至其他Follower节点

首先刚启动时所有节点都是处于Follower状态，然后开始进行选举，看哪个节点先超过了选举的超时时间，如果超时时间内还没收到leader节点的心跳那么就会发起一个新一轮的leader节点的选举，先超时的节点会切换为Candidate候选人状态，然后为自己称为Leader投一票，然后该节点会向集群的所有节点发起一个请求进行一次拉票选取，由于目前集群中只有一个候选人状态那么其他节点收到了这个请求，就会将赞成票投给这个节点，然后各个节点就转变为Candidate状态并且也为自己+1票，然后某个Candidate节点得到的票数超过了总结点的一半，那么就会升为leader节点

即当集群中Leader节点出现故障之后，由于其他节点收不到leader节点的心跳检测，那么过了这且节点过了等待心跳的超时时间后就会发起一个leader的选取，然后得到的票数超过了半数就升级为Leader节点

2、出现“投票分裂”的时候如何选出leader节点

注意只要节点处于Candidate状态，那么就会不停的向其他节点发起拉票请求

其实投票分裂问题就是：集群中leader节点宕机了，此时集群中的某两个或多个节点同时过了等待心跳的过期时间，各自等变成Candidate节点，然后各自拉票，然后最终这两个节点收到赞同的票数相同，那么不进行省级操作，此时其他节点也超时了，由于最开始的那两个节点选不出来，因此新的Candidate节点收到的票数就超过了半数，最终升为了Leader节点

3、raft算法的日志复制过程

目前集群中只有两个健康的节点s1,s2,假设此时S1节点是主节点

注意注解点日志有两个状态：未提交、已提交

注解点只有当将日志同步到半数以上的节点后才会将对应的日志设置为已提交状态

1、刚开始时只有两个节点存活

开始同步日志：

此时其他节点恢复了：

然后s1节点会继续向s3节点发起第二条日志，s3接收到之后，除了复制第二条日志之外还会将第一个日志状态设置为已提交状态

以此往复，对于之前其他节点的已经复制的日志，在s3同步第一条日志之后，的时候主节点重新发请求，然后对应的节点就可以将状态设置为已提交状态

4、修复不一致的日志

有新的节点加入到集群，leader节点首先要做的就是一致性检查，

raft算法日志是根据leader节点的强一致性

原来得leader节点s1挂了，并且s1中有4，5两条日志未确认，此时集群做新的一轮leader选取

此时s2先超时然后开始发起leader投票，最终选为leader节点，

再然后s4节点恢复了，那么对于新节点加入集群，leader节点都会进行一个一致性检查，检查后会从最大下标（leader箭头处）开始往前找，看看有没同步的日志，找到未同步的位置之后，就开始进行日志的复制

再然后此时主节点s2新产生了日志图中得3并且提交了，此时原来的s1恢复了，那么此时回复的节点由于不是主节点了，所以会接收leader节点的一致性检查（新加入节点从当前leader节点得最大下标处开始往前检查），然后将日志同步为当前leader节点的（leader节点的强一致性）

5、如何保证数据安全性

Candidate节点发起投票的时候会比较term和index得值

如果这些follower节点发现自己的term和index比candidate节点的新，那么就投反对票

如下图：原来S2节点向所有节点发起心跳机制后宕机了，此时s5节点刚好恢复了，那么接收到心跳之后，返回消息给s3但由于s3宕机了，所以此时没有leader节点，此时s5等待心跳检测的时间过期了，那么s5称为candidate节点发起新一轮的投票，但是其他节点收到之后会进行1、term比较,和index(每个节点当前日志的最大下标），如果小于follower节点，那么投反对票，因此s5没资格当leader(这是因为其他节点都同步日志了，现在一个新兵蛋子啥也么有，如果当了leader那么根据leader日志的强一致性会同步leader的日志，那么之前其他节点的日志就会被覆盖掉）

因此又开始新的一轮leader选举最终s1当选