什么是Raft算法？

　　不同于Paxos算法直接從分布式一致性問題出發推導出來，Raft算法則是從多副本狀態機的角度提出。Raft實現了和Paxos相同的功能，它將一致性分解為多個子問題: Leader選舉(Leader election)、日志同步(Log replication)、安全性(Safety)、日志壓縮(Log compaction)、成員變更(Membership change)等。同時，Raft算法使用了更強的假設來減少了需要考慮的狀態，使之變的易于理解和實現。

　　三個角色

　　Raft將系統中的角色分為領導者(Leader)、跟從者(Follower)和候選人(Candidate):

　　Leader: 接受客戶端請求，并向Follower同步請求日志，當日志同步到大多數節點上后告訴

　　Follower提交日志。 Follower: 接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。

　　Candidate: Leader選舉過程中的臨時角色。

　　Raft要求系統在任意時刻最多只有一個Leader，正常工作期間只有Leader和Followers。

　　以子問題Leader選舉為例?

　　Raft 使用心跳(heartbeat)觸發Leader選舉。當服務器啟動時，初始化為Follower。Leader向所有Followers周期性發送heartbeat。如果Follower在選舉超時時間內沒有收到Leader的heartbeat，就會等待一段隨機的時間后發起一次Leader選舉。

　　Follower將其當前term加一然后轉換為Candidate。它首先給自己投票并且給集群中的其他服務器發送 RequestVote RPC (RPC細節參見八、Raft算法總結)。結果有以下三種情況:

　　贏得了多數的選票，成功選舉為Leader;

　　收到了Leader的消息，表示有其它服務器已經搶先當選了Leader;

　　沒有服務器贏得多數的選票，Leader選舉失敗，等待選舉時間超時后發起下一次選舉。

　　選舉出Leader后，Leader通過定期向所有Followers發送心跳信息維持其統治。若Follower一段時間未收到Leader的心跳則認為Leader可能已經掛了，再次發起Leader選舉過程。