什麼是分佈式一致性
首先假設我們服務器系統中只有一個結點（node），這個結點可以是一個數據庫服務器存儲着單一的值，有一個客戶端向這個服務器發送了一個值，這個值可以很容易就滿足一致性。但是，如果我們的服務器部署在集羣上，有多個結點，每次對這些服務器發起的操作，都需要使他們的結果達成一致，看起來像是一臺機器一樣，這就是分佈式一致性問題。Raft就是一種實現分佈式一致性的協議
結點的狀態
每個結點可以有三種狀態：Follower，Candidate，Leader。所有的結點都是從Follower狀態開始的，如果followers沒有收到leader的RPC消息，則可以轉換爲candidate，而candidate需要發起投票，其他結點參與投票，回覆他們的投票結果，如果這個candidate獲得了大部分的選票，就可以成爲leader結點了。這就是Leader Election過程。。
Leader Election
下面來看看選舉的具體過程。Raft裏有兩個管理選舉的計時器，第一個選舉計時器（election timeout）是記錄follower結點變成candidate結點所需要的時間，一般在150ms-300ms之間（隨機），在這一輪計時結束後，有的follower結點轉換成了candidate結點，就開始了真正的選舉，首先candidate結點會投票給自己，然後向其他結點發起投票請求，如果收到消息的結點在這一輪倒計時中沒有投出票，默認是投給candidate結點的。一旦一個candidate得到了大部分的選票，就轉換成了leader結點。大部分的選票保證了一次選舉只會有一個leader結點
然後每個節點重置他們的第二個election timeout（headrbeat timeout）,Follower接收到Leader的心跳包的同時也重置選舉定時器這個leader結點開始要做的就是發送AppendEntries消息給他的follower結點。這種消息就像心跳包一樣，在固定的間隔時間會發送。Follower結點也會回覆每一條AppendEntries消息。這一輪的選舉週期會持續直到一個follower結點停止接收心跳包（可能有很多種原因）併成爲了candidate結點。
這時就會重新選舉（re-election），過程和前面一樣。
此外，如果選舉的時候有兩個或多個結點同時成爲candidate結點，則會發生競選的過程，當然，這個過程和前面過程也一樣，直到有candidate結點獲得大部分選票才能成爲leader結點。
Log Replication
現在，所有的請求都需要先經過leader結點，每一條leader會把它作爲一個log entry，添加到節點的日誌裏，log現在還沒有提交，所以不會修改結點的值，而是先給其它的server發AppendEntriesRPC，leader結點會等待直到大部分結點修改了他們的entry，然後log可以被提交了，值也會被修改，然後leader會告訴其他結點entry提交了，其他節點執行相同的操作，這樣，所有結點保持了一致性
如果出現了網絡分區（network partitions），則會出現兩個leader的情況，小分區的nodes的日誌不會被提交，因爲這個分區的leader得不到大部分nodes的回覆（相對於整個系統來說），當解決了分區問題，則這個小分區的nodes都會重新根據大分區leader的日誌來保持一致性。