三种节点状态

1. follow
2. candidate
3. leader

Raft一致性策略

Raft协议强依赖leader节点来确保集群实现数据一致性

1. 所有client发送过来的数据会被转到leader节点来统一处理
2. leader节点接收到数据后，将数据设置为uncommited状态。
3. 随后leader节点想所有follow节点发送复制数据命令，并等待响应，超过半数的节点响应后，则将数据该为commited状态，并响应client.
4. 在响应client后将想所有follow节点发送通知表明给数据的状态为commited。

leader election

初始化时所有节点都是follow.

1. 节点启动后，或者election timeout内没有收到leader的心跳，则：
   增加本节点的 current term，切换到candidate，并记自己一票，并并行发送选举请求（RequestVote RPCs），并等待其他节点的回复。
   在这个过程中，根据来自其他节点的消息，可能出现三种结果

1. 收到majority的投票（含自己的一票），则赢得选举，成为leader
   第一种情况，赢得了选举之后，新的leader会立刻给所有节点发消息，广而告之，避免其余节点触发新的选举。
2. 被告知别人已当选，那么自行切换到follower.
   比如有三个节点A B C。A B同时发起选举，而A的选举消息先到达C，C给A投了一票，当B的消息到达C时，C不会给B投票，而A和B只都有自己的一票。A胜出之后，会给B,C发心跳消息，节点B发现节点A的term不低于自己的term，知道有已经有Leader了，于是转换成follower。
3. 一段时间内没有收到majority投票，则保持candidate状态，sleep一个随机的时间，重新发出选举。

脑裂怎么办

脑裂了会出现两个集群，比如5个节点，分成两个集群，一个3个节点，一个2个节点。两个节点中虽然有leader，但是leader想其他follow复制时，无法得到超过半数节点的response，所以这个小集群不可用。