爲了提升服務的高可用、高性能，通常採用多節點架構。
一個節點時候，數據是一致的。多個節點的情況下，如何保證數據一致性呢？
本文介紹的RAFT協議，就是解決多節點情況下，數據一致性問題。
1.基本概念
節點有三種角色：leader， candidate, 和follower.
在Raft選舉中，有兩個控制選舉的超時設置： 選舉超時（election timeout）和心跳超時(heartbeat timeout)
選舉超時是，follower等待成爲candidate的時間。
心跳超時是，leader定期向follower發送心跳消息的時間。
leader節點會定期發送心跳給其他節點。其他節點收到心跳消息後，會重置選舉超時時間。
選舉超時的時間，隨機分配在150ms到300ms之間。
所以，每個follower的選舉超時時間是隨機的，以免重合。
在選舉超時後，follower成爲candidate， 並開始新的選舉週期（election term）。
每發起一次選舉，選舉週期（election term）自動加1。
2.選舉過程
剛開始的時候，節點都是follower。
選舉超時時間最先到的follwer，自動變爲candidate，發起投票。它首先會給自己投一票。
接着向其他節點請求投票，其他節點回復投票。
每個節點一個選舉週期之內只能投一票，它會將票投給最先請求投票的candidate。
如果candidate獲得超過半數的投票，那麼它就成爲leader。
接着，leader定期向其他節點發送心跳消息。
如果leader節點宕機，無法發送心跳消息後，其他follower開始新的一輪選舉。
3.數據更新過程
在RAFT中，數據更新操作是通過Log Replication實現。
系統中所有更新操作都要經過leader。
client向leader發送請求後，leader將消息同步給其他節點。
具體過程：
(1) leader將更新操作(append entry)同步給所有節點，是附加在心跳消息中發送的。此時是未提交狀態uncommited。
(2) leader 如果收到超過半數的回覆，那麼它回覆client OK，接着提交commit，並通知其他節點已提交，其他節點收到消息後也提交。
(2) leader如果沒有收到超過半數的恢復，這個更新操作就不會提交。
通過以上步驟就完成了一次更新。
4.網絡分區
如果遇到網絡分區，RAFT是否仍然可用呢？
假設一個5個節點集羣：A, B, C, D,E.
當時B是leader， term是1。
網絡分區後，A，B一個區， C, D, E是另一個區。
C， D， E無法收到心跳消息，選舉超時後，重新開始投票，term變爲2， 接着選出一個新的leader C。
如果此時有更新操作發送到A， B這個分區。leader B 將更新請求發送到所有節點，只有A，B回覆，不能收到超過半數的回覆，所以無法提交。
而纔是更新操作發送到C，D， E這個分區。leader C 將更新請求發送到所有節點，可以收到超過半數的回覆，所以可以提交。
如果後面網絡分區消失後，leader B發現自己的term小，就會自動退出。並從新leader C同步最新狀態。
從而系統達到一致狀態。
5.容災性
因爲RAFT要求任何更新操作，都要超過半數節點的回覆。
如果不能達到半數，就不會提交。
所以，一個多節點的系統，容災性如下：
2個節點，不具備容性，其中任何一個節點掛掉，系統就不可用。
3個節點，可以允許一個節點失效。
5個節點，可以允許兩個節點失效。