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

　　三個角色

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

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

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

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

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

　　以子問題Leader選舉為例?

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

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

　　贏得了多數(shù)的選票，成功選舉為Leader;

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

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

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