先要明确的几个概念
- Raft协议是基于paxos multi的，属于全新优化精简版本，更加容易实现和理解。zookeeper用的zab协议跟raft基本一样，就是心跳方向是反的，raft是leader向follower发送心跳，zab是follower向leader发送心跳询问leader健康状况。
- 再有一个就是，raft、paxos、zab这些属于强一致性协议，与之相对的还有弱一致性协议，比如DNS的工作原理，比如Cassandra和redis cluster模式用到的gossip协议等。弱一致性也叫最终一致性。一般来说弱一致性的系统性能要好于强一致性。对读写并发要求比较高的场景应该想办法优先使用弱一致性协议。
解决问题的核心
Raft将状态机复制（state machine replication）或者说分布式一致性问题分解为3个子问题：
- leader选举
- log复制
- 异常状况下的数据安全性：leader宕机、选主平票、分区脑裂
leader选举
- 集群启动初始状态下所有节点都是follower，这时候follower会触发选举。当follower无法在本地计时的随机超时时间内收到leader的心跳包，也会触发选举。
- 达到自己超时时间的follower就变成Candidate，然后会向集群中的其他节点发送拉票请求，每个节点会投票给最先发给自己拉票请求的节点，当某个节点获得超过半数节点的票时，会当选为新的leader。每个leader任期内都有一个唯一的term，表示当前集群处于这个节点作为leader这样一个阶段。
Log复制
- 首先所有的写请求必须都由leader处理
- leader会先写本地的log但未真正去写数据、也就是这个写在本地是写未提交的这样一个中间状态。然后在心跳包中包含写请求，将操作给follower。follower收到写请求之后，也在本地写log，进入写未提交状态，同时回复leader。
- leader收到超过半数的follower的回复之后，会先commit提交本地的写log，数据真正写入、然后返回客户端数据写入成功。最后通知各个follower：leader已提交该写操作，各位也提交这个操作。
- follower收到leader的提交通知之后，提交自己本地对应的写log。整个过程结束。
ps: leader应该是会为每个follower维护一个同步进度或者说日志offset的表，这样可以清楚知道每个follower的数据log复制的进度。
比如某个follower宕机了一阵子，再恢复的时候leader仍然会帮它把落下的这段时间的课补上。因为leader知道它的复制进度。
异常状态下的数据安全性
leader宕机
每个follower会不断的随机设置一个超时时间timeout，然后从0开始计时，在timeout之内收到leader的心跳包则会重新从0开始计时。
一旦计时到timeout仍未收到leader的心跳包，这个follower就会启动 “变candidate -> 向其他节点拉票 -> 尝试得到超过半数票成为leader” 这样一个流程。
选主平票
如果出现这个状况，平票的两个节点会各自再来一次随机timeout倒数，然后重新拉票。这样因为两个随机timeout总会有一个时间差的存在、基本大概率两者之间会产生一个胜出者了。
分区脑裂
这里体现出为什么节点个数要定奇数个了。
如果是偶数个，那么发生分区的时候可能会出现两个分区的节点一样多的情况：没有leader的区无法选出新leader，而有leader的区在写日志复制时无法得到超过半数的follower的回复（自己也算）、无法commit所以无法回复客户端已写入、只能回复unknown。这样整个系统呈现出不可用的状态。
而奇数个节点的集群发生分区，总会有一大一小两个分区：如果leader在大分区、可以收到半数以上的回复、可以commit写日志，集群正常工作；如果leader在小分区，由于大分区超半数节点、会选举出来新leader，当小分区的旧leader收到写请求之后，无法达到半数回复，写会失败。这样客户端可以选择新leader进行请求，集群整体可用。
ps:分区恢复之后、旧leader收到新leader的心跳包会发现term比自己的新，所以会变成follower与新leader进行同步。
