一、分佈式共識協議引入
什麼是分佈式共識協議呢？讓我們從一個簡單的例子開始。
看看我們只有一個節點的系統，在這個系統中，你可以將節點想象爲一個數據庫系統，這個系統存儲了一個值X。
我們有一個客戶端（綠色圓圈）可以發送交易給這個系統。
例如客戶端發送了值“8”給這個系統。我們很容易理解，由一個單獨節點組成的系統要就某個值達成一致或共識很容易。
但如果我們的系統中有多個節點，應該如何達成共識呢？這就是分佈式系統的共識問題，爲了解決這個問題，科學家們提出了分佈式共識協議。
二、Raft分佈式共識協議
（一）概述
Raft是一種分佈式共識協議的實現，在Raft中，一個節點可以處於三種狀態中的一種：Follower、Candidate、Leader，如下圖所示。
所有節點在最開始都處於Follower狀態。
（二）Leader選舉
Leader選舉是分佈式共識協議的核心功能，它是確保分佈式共識協議能夠有效處理外部請求的關鍵。
1、Leader選舉之首次選舉
在Raft中，有兩個控制節點選舉的超時機制。第一個是選舉超時，這是Follower節點變爲Candidate節點的時間，這個時間被隨機設置爲150ms~300ms之間。在一個選舉超時時間週期後，Follower節點成爲Candidate節點並進入一個新的選舉週期，如下圖所示。
Candidate節點首先給自己投一票，並將請求vote投票的Request請求發送給其他節點。
如果接受到請求的節點在這一輪中還沒有投票，則爲該candidate節點vote投票，並重置選舉超時時間。
當Canditate節點收到大多數votes投票，它便成爲Leader節點。
Leader節點開始向Follower節點發送追加條目消息，這些消息按照心跳超時的指定時間發送。
Follower節點隨後響應每條追加條目信息。
這個選舉期限將持續到Follower節點停止接收來自Leader節點的心跳併成爲候選人爲止。
2、Leader選舉之重新選舉
接下來我們停止leader節點（節點A）並觀察一下重新選舉leader的過程。
節點C從Follower變爲Canditate的隨機時間比節點B短，率先發起了投票，所以搶得了Leader節點。
現在，節點C成爲第二輪選舉期限的Leader節點。
3、Leader選舉之分裂投票
需要多數投票才能保證每個任期只能選舉一名領導人，如果兩個節點同時成爲領導人，可能會發生分裂投票。
讓我們來看看分裂投票的例子。如下圖所示，節點A和節點D兩個節點同時成爲Canditate並開始了新一輪選舉，並且每個節點都先於另一個節點到達單個Follower節點，所以每個Canditate都收到了同等數量的投票，且均不超過半數節點。
每個Canditate在無法成爲Leader節點後，會重新成爲Follower節點，並重置競選超時時間，該超時時間是隨機的，這使得不同的節點不會總是同時成爲Canditate節點，使得選出唯一Leader成爲可能。
（三）日誌複製Log Replication
日誌複製是Raft共識算法中的另一個核心實現，它是確保所有節點能夠他同步數據的關鍵。
一旦我們選出了領導者，我們需要將對系統的所有更改複製到所有節點。這是通過使用用於heartbeats的相同Append Entries消息來完成的。
首先客戶端發送修改給leader，這個修改將被追加到leader的log中。
然後修改將隨着Leader的心跳發送給Followers。
一旦大多數Follower承認它，Leader就會提交一個條目......然後提交一個響應給客戶端。
隨後客戶端發送add 2的命令，經過Leader接收、Followers同步commit，系統的值將被更新爲7。
（四）網絡分區一致性
Raft甚至可以在出現網絡分區時維持一致性。
現在我們在A&B、C&D&E之間增加一個分區，因爲分區的存在，現在我們在不同的terms中擁有兩個Leaders。
現在我們嘗試增加另外一個客戶端來嘗試更新兩個Leaders，客戶端1將嘗試更新Node B的值爲3，node B無法複製到多數節點，因此其日誌條目保持未提交狀態。
另一個客戶端2嘗試更新Node D的值爲8，這個操作將成功，因爲它可以複製到多數節點。
現在我們嘗試恢復網絡分區，Node B將看到更高的選舉term並下臺，Node A&B都將回滾他們未提交的entries並同步新Leader的log。因此我們的log實現了跨集羣一致性。
