raft共识算法小记

前言

raft是一种分布式共识算法，相对于大名鼎鼎的Paxos，raft更易于理解和工程化，本人近期接触到OVSDB的cluster集群，便是基于该算法，记录一下便于后期再温习。
raft算法要求server得是奇数个，如果是偶数反而可能产生读写性能下降，甚至多个leader的“脑裂”现象。

leader选举 (leader election)

每个节点有3种状态：Follower，Leader，Candicate。
在raft算法中有两个timeout控制着选举（election）,第一个就是election timeout,它是follower等待变为candinate的时间，它的时间在150-300ms之间随机产生以保证每个follower成为candinate的时间不同，进而出现一个candiante之后就会立即进行选举成为leader，而不会出现多个candinate同时进行选举的情况。

当图上B先变为candinate之后，就会开始一个election term,发送Request Vote消息给其他节点让他们来为B投票，B也会为自己投上一票。一旦candinate收到了超过一半的投票，他就变为了leader，然后就会发送Append Entries到其他节点，也就是它的followers，而followers也同样会回复Append Entries给leader，这被称为heartbeats.当follower不再收到leader的heartbeats，它就会变为candinate,这个超时也就被称为heartbeats timeout(是我们这里提到的第2个timeout).

重新选举（re-election）

当leader挂了之后，就会有新的follower变成candinate,然后发生新的选举，进而产生新的leader。当我们有4个节点，恰好2个节点同时变为candinate,那么就会出现脑裂的现象，如下图。出现如下情况之后，就会发生重新选举（新的term），得票高的就会成为新的leader。

每个server开始都是follower，当它收不到来自Leader的心跳消息就会变成Candicate，然后给其他节点发送拉票消息，其他节点收到消息就会返回投票消息，如果Candicate收到了超过半数节点的投票消息（当然票数里面会有它自己的一票），他就会变成Leader了，开始规律地给其他节点发送心跳消息，收到心跳消息的节点就是Follower节点。这个过程就是leader election.

网络不可达导致某节点被孤立

如果因为网络问题某个节点被孤立在整个集群之外，必然发生再次选举，但是由于被孤立的节点的角色不同，过程和结果也不尽相同。

leader的失联

由于leader被孤立而产生的问题和上面说的类似，如果是3个节点，那么其他2个节点就会发起重新选举，而产生新的leader，同时term也会更新。但是这时候原来leader的角色会依然保持不变，任期（term）也会保持不变。
也就是说，这3台机器会同时出现2个leader以及term值，当网络恢复后，由于老的leader的term值要小于新的leader的值，就会变成新的leader的follower，此后集群恢复稳定。

follower的失联

如果follower因为网络问题而和集群中其他的机器失联，就会不断的发起选举，但是由于他只能得到自己的一票,无法得到大多数票数，所以选举一直失败，但是raft_run函数一直在main loop中迭代执行，也就是依然在不断的选举，导致选举任期（term）在不断增加，直到和失联集群重新恢复连接。
而由于这个节点在失联过程中，它的term一直在增加，因此它的term一般来说会比其他2台机器的term都要大，导致该失联节点重新连接后会成为leader，其他2个节点会成为该节点在该term下的follower.

日志复制（Log Replication）

首先client会将消息发送给leader,然后消息就会变为leader的log，而后在下一次心跳的时候，这个log就以Append Entries的形式会发送给它的followers，当超过一半的followers也通过heartbeats确认过已经收到之后，这个entry就会在leader上被commited,然后再回复给client以及将commited消息以heartbeat形式发给followers，这样全局就完成了日志的复制，也就是消息的同步，是不是看起来有点像三次握手？

由于每次选举都会有term，且每个log都会有index，因此即使raft集群中间出现过如下网络隔离，也不会影响数据的同步，其中B节点虽然是leader，但是由于收不到超过一半的确认，它的数据本身也无法被commited，而当网络恢复之后，由于上面是在term2而下面在term1，所以A和B就会自动更新到term2上。

总结

raft将共识问题分解成两个相对独立的问题，leader election，log replication。流程是先选举出leader，然后leader负责复制、提交log（log中包含command），且在同一个cluster中只会存在一个leader。

为了在任何异常情况下系统不出错，即满足safety属性，对leader election，log replication两个子问题有诸多约束

leader election约束：
同一任期内最多只能投一票，先来先得
选举人必须比自己知道的更多（比较term，log index）

log replication约束：

一个log被复制到大多数节点，就是committed，保证不会回滚
leader一定包含最新的committed log，因此leader只会追加日志，不会删除覆盖日志
不同节点，某个位置上日志相同，那么这个位置之前的所有日志一定是相同的
Raft never commits log entries from previous terms by counting replicas.
  本文参考和借鉴了如下的文章，尤其是动画，建议看看，有助于理解。raft算法原文点击这里。

https://www.cnblogs.com/xybaby/p/10124083.html
https://blog.csdn.net/u010588262/article/details/82687074