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

　　三個(gè)角色

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

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

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

　　Candidate: Leader選舉過程中的臨時(shí)角色。

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

　　以子問題Leader選舉為例?

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

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

　　贏得了多數(shù)的選票，成功選舉為L(zhǎng)eader;

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

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

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