Raft算法介绍
raft是一个协议，可以用来实现分布式系统的一致性。
raft算法中节点的三种状态
Leader：处理所有客户端交互，日志复制等，一般一次只有一个Leader
Follower：随从，完全被动
Candidate：候选者
一个简单的工作流程
1.领导的选举过程
这三种状态可以通过选举机制互相转换。所有节点在初始状态下都是以随从份出现，如果follower没有听到领导者的指令，他就会变成候选者，给所有的其他节点发送投票，其他节点回复候选者的投票，如果一个节点受到大多数节点（包括自己投自己）的投票，那么该节点从候选者变成领导者。
初始状态
候选者状态，并给所有节点发送投票请求
变成领导者
2.主节点数据同步过程（日志复制）
客户端数据提交
所有对于系统的改变都必须通过领导。
客户端更新数据5，发送给领导
每一个改变命令都会变为节点日志，此时领导者没有提交数据5。
主节点复制数据发给随从节点
随从节点收到数据后，响应领导，同时领导节点等待大多数节点的响应，如果领导节点受到大多数节点的响应，就提交数据
领导提交数据，提交成功后，通知随从节点提交数据
随从节点提交数据
主节点响应客户端数据提交成功。
Raft算法包括两个部分
Leader Election & Log Replication
Leader Election
选举超时(Election timeout)
随从变为候选者的过程，这个时间一般为150ms到300ms。
先结束自旋的节点变成候选人。
term:1 第一轮
vote count : 1 首先自己投自己一票
发起投票请求
其他节点收到投票请求，进行投票
在同一轮中，如果收到投票请求的节点，还没有投票则可以允许他进行投票，但是如果他已经投过票了，则不允许继续投票，即同一轮中同一个节点只能投一票。
同时投完票的节点重新进入自旋状态
重新进入选举超时，防止领导节点挂了
领导为随从发送日志
heartbeat timeout
消息发送也有超时时间即心跳超时。
领导者和随从维持心跳检查，如果超时则随从节点满足选举超时，重新进入选举过程。
所以heartbeat timeout<vote timeout
这一届领导班子一直会维系到一个随从节点停止接收心跳并且成为了一个候选者。
领导节点故障
其中一个节目率先变成候选者
进行第二轮投票
自己一票，B节点一票，虽然受不到节点A的投票，但是期已经获得了大多数投票，所以此时C胜利当选。一轮投票只能产生一个领导。
投票分离
某一轮选举过程中出现多个候选者
A,D节点同时变成候选者，向随从节点发送投票请求
随从节点将票投给先到达该节点的投票请求的一方，同时拒收其他节点的投票请求。
图中，B节点先收到A的投票请求，投票给A，同时拒收D的投票请求。同时C投票给D，那么本轮投票A,D票数相同，那么所有节点重新进入自旋。
所有节点重新进入选举超时（自旋）
等待节点重新变成候选者，并且重新进行选举，直到选出新的领导人。
Log Replication
日志复制，每次同步数据都必须在心跳时间内将数据同步请求发送出去
客户端请求领导节点
领导节点在下一次心跳中，将日志同步给随从节点
大多数节点都回复领导节点
此时领导节点可以提交数据，同时领导节点响应给客户端
此时不通知随从节点提交数据
领导节点在下一次心跳中，通知随从节点提交数据
同时随从节点提交后，响应给领导节点
Raft算法在网络分区中如何保证一致性
在Raft算法中，如果出现网络分区，会有一个区域分得当前领导节点，该节点因为收不到大多数请求的响应而拒绝提交数据，而其他区域重新选举，等到网络分区结束，统一听最新选举产生的领导节点，老领导退位回滚网络分区过程中未提交的数据，然后同步最新领导的数据。
网络分区过程中Raft算法保持一致性的过程
network partition(网络分区)
原领导节点不在的区域重新进行选举
此时B节点作为领导节点分给了下半个区域，其所在的区域不用重新选举，而上半个区域没有领导则需要重新进行选举
客户端请求（下半区）
因为网络分区了，所以此时分出了两个客户端，每个客户端只能访问自己所有区域的领导者。
uncommitted
此时无论客户端请求B节点保存任何数据，B节点都会回复客户端保存失败，因为B节点作为原先的领导，此时只收到了节点A的同步回复，并没有收到大多数的回复，所以此时节点B不能提交数据，回复客户端提交失败
客户端请求（上半区）
因为上半区是新选举出来的领导，可以获得大多数同步回复，所以可以正常提交数据。
网络恢复
此时B(Term:1)要听更高一轮选举（C term:2）的命令，所以B要退位,然后A,B两个节点没有提交的日志（数据）回滚，然后接收新领导的数据。
从而达到节点数据一致。
