這是一篇來自研究生一年級的課程——《分布式系統》的作業記錄部落格。
其主要是實現分布式系統中一致性的演算法raft。
我們假設有乙個客戶端 x 和乙個伺服器 y ，然後 x 傳送乙個值給 y，那麼唯一的乙個伺服器就有了這個值。
但我們試想一下現實世界中，伺服器的數量不可能只有乙個，所以假設有 n 個伺服器 y[n] ，如何將客戶端 x 發的值
讓多個伺服器都能一致起來，這就是需要**的乙個問題。
而在**中提到，一致性演算法是從複製狀態機的背景下提出的。複製狀態機圖示如下：
複製狀態機是基於複製日誌來實現的，從上圖可知，每乙個伺服器都儲存乙個包含一系列指令的日誌。
客戶端向一致性模組傳送指令，一致性模組接收到指令然後增加到自己的日誌中，它和其他伺服器上的一致性模組進行通訊來保證每乙個伺服器上的日誌最終都以相同的順序包含相同的請求。
一旦指令被正確的複製，每乙個伺服器的狀態機按照日誌順序處理它們，然後輸出結果被返回給客戶端。
針對上面提到的分布式系統中一致性問題，raft 便是一種可以實現一致性的協議（或者演算法）。具體的講，它就是用來管理上圖複製狀態機中複製日誌的演算法。
raft通過選舉乙個leader，並賦予給它完全的管理複製日誌許可權來實現一致性。
leader從client接收日誌條目，然後將日誌條目複製到其他伺服器中，並當可以保證安全性時告知其他的伺服器需要應用日誌條目到它們的狀態機中。
這樣我們就將 raft 演算法分成三部分：
具體內容下面分別來講述。
我們首先要了解一下raft的一些基礎知識。
首先 raft 中的伺服器一共有 3 個狀態：
三個狀態相互轉化關係圖如下：
也就是說，每個伺服器起始的狀態都是 follower，然後開始選舉之後，其中乙個伺服器稱為 candidate， 然後接受投票，若獲得大部分的投票則稱為 leader，當然從 candidate 和 leader 狀態都可以轉化成 follower狀態。
而每乙個時期，系統只能存在乙個 leader，如果大於1個，則錯誤，而其他的節點都是 follower。follower 都是被動的：他們不會傳送任何請求，只是簡單的響應來自 leader 或者 candidate 的請求。
領導選舉是一種非常關鍵的步驟，也是實現raft的第乙個步驟。
過程如下：
首先系統中存在多個伺服器，每個伺服器都維護著自己的乙個election timeout，它是隨機設定的（一般是150~300ms）。
如果乙個 follower 在其 election timeout 時間裡都沒有收到任何訊息，則它認為系統中沒有可用的 leader，那麼它會發起選舉已選出新的leader。
如下圖所示，一共有 3 個伺服器，每個伺服器有乙個 「進度條」 代表其election timeout。
一旦其中乙個節點（下圖顯示的是節點a）的進度條走完，便成為 candidate。此時a開始乙個新的 election term，並為自己投票。
request vote（請求投票）rpc。
一旦 candidate獲得了絕大多數 follower 的投票，則它成為 leader。【小弟們都服我做老大】
最後，leader 便開始按另乙個 timeout ——heartbeat timeout（附加日誌項）rpc。傳送這個rpc是為了 【告知其他伺服器我是老大，從而建立自己的權威並且阻止新的老大的產生】。
【有小弟不接收老大的指揮，不幹了，要反抗，自己想成為老大】。
以上便是 leader election的細節。
總的來說，要開始一次選舉過程，follower 先要增加自己的當前任期號並且轉換到 candidate 狀態。然後它再並行地向集群中的其他伺服器節點傳送request voterpcs 來為自己拉票。candidate 會繼續保持著當前狀態直到以下三件事情之一發生：
情況二：其他的伺服器成為 leader ；
情況三：一段時間之後沒有任何乙個獲勝的人。
在等待投票的時候，候選人可能會從其他的伺服器接收到宣告它是領導人的附加日誌項 rpc。如果這個領導人的 term（包含在此次的 rpc中）大於等於候選人的currentterm，那麼候選人會承認領導人並回到跟隨者狀態。 相反，如果此次 rpc 中的 term 比自己的currentterm 還小，那麼候選人就會拒絕這次的 rpc 並且繼續保持候選人狀態。【你強我就服你，你繼續上，我繼續成為小弟。但如果我強，我就不服，我就要反抗】
分布式系統 Raft演算法
什麼是拜占庭將軍問題？在很久很久以前，拜占庭是東羅馬帝國的首都。那個時候羅馬帝國國土遼闊，為了防禦目的，因此每個軍隊都分隔很遠，將軍與將軍之間只能靠信使傳遞訊息。在打仗的時候，拜占庭軍隊內所有將軍必需達成一致的共識，才能更好地贏得勝利。但是，在軍隊內有可能存有叛徒，擾亂將軍們的決定。這時候，在已知有...
分布式系統的Raft演算法
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...
分布式系統的Raft演算法
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...