資料一致性是在乙個需要容錯的分布式系統中提出的概念。這裡的一致性我們要特別搞清楚，主要有以下兩層含義：
一直以來一致性演算法都是乙個高深莫測的領域,特別是一致性演算法的鼻祖paxos，以複雜難懂而著稱！ 然而在耐心研讀了raft的***** 14以後，發現這一領域也並不是那麼神秘。首先我想說raft的*****質量非常好好！它不僅闡述了複雜的一致性演算法，而且展示了一種解釋複雜問題的方法。它深刻吸取paxo抽象難懂的教訓，在*****中特別強調了understandable! 嗯，understandable， 作者是認真的。 為了證實raft更容易理解和掌握，作者專門組織了一幫大學學生，分為兩組，分別學習raft和paxos, 然後對學員的掌握情況進行測試，測試結果也以**形式發出。真是下了不少功夫啊！
這裡簡單梳理一下raft *****中的框架內容，若要全面了解raft協議，強烈建議讀原*****.
logreplicated state machine
複製狀態機中儲存的是實際的客戶資料，資料的讀取都需要從狀態機中讀。因此leader在返回給client成功時，資料一定要寫入狀態機，不然會造成client讀取不到最新資料。
leader
leader是服務客戶端的唯一server。 leader要不斷地向follower傳送心跳包還確保自己的leader地位。
candidate
candidate是乙個臨時角色，一般來講，任何乙個節點都不會長時間處於這樣一種角色。它是由follower節點轉換來的。即當乙個follower節點在一定時間(election timeout)沒有收到leader的心跳包，這個follower就會轉換為candidate,發起投票選舉自己為leader, 如果它能獲取到多數投票，它就會成為下乙個任期（term）的leader. 若不能，則有兩種情況: 繼續投票或轉換角色為follower.
follower
follower角色接受leader的日誌複製，負責高可用。當leader掛掉時，其中最先election timeout 的follower會變為candidate, 發起投票選舉自己為leader. 這裡的election timeout是乙個時間範圍內的隨機值（raft *****建議150ms - 300ms.），這樣確保不會一直有兩個candidate同時選舉。 在tikv中election timeout是10s(如果處於無主狀態，大約經過 raft-base-tick-intervaldefault 1s* raft-election-timeout-ticksdefault 10時間以後發起選舉)
requestvote rpc
candidate傳送requestvote rpc來發起選舉。
installsnapshot rpc
當乙個follower角色落後leader太多時，會使用installsnapshot rpc 來使其快速補充資料。任何乙個節點都會做日誌定期快照。可以參照redis的log rewrite來理解這裡的snapshot.
leader election
集群中的server從follower角色開始，在經歷election timeout週期沒有收到leader的心跳時，該server會轉換角色為candidate, 將自己的任期加1， 投自己一票，並傳送requestvote rpc向集群中的其它server發起投票。如果它能夠獲得大多數投票，它就會當選為leader。當然這裡面涉及到許多細節，這裡不詳細闡述。 leader election活動在raft系統中發生的並不頻繁。
理解raft成員變更可以參考mysql mgr中的view & viewchanges 4. 當集群中某個節點宕機或者新增新的節點到集群時，會觸發membership change. raft採用joint consensus機制來保證平滑過渡，並且不影響對client請求的處理。這一活動在raft系統中也不常見。
log compaction
log不能無限增長。raft會定期對日誌做快照（snapshot），這一操作與redis中的log rewrite類似（如下圖）。在實際的實現中，龐大的資料集可能會使日誌占有巨大空間，即使經過壓縮後，日誌量還是很大，還應實現定時清理機制。tikv中通過一些引數（如：raft-log-gc-size-limit）設定來控制raft log的殘餘量,超過這一設定會被清理以節省空間。
簡單來看，上述幾個部分包含了raft協議的主要內容。希望對了解raft概貌有些幫助。對細節的闡述往往使問題變得複雜，學習新鮮事物時，我們可以先從全域性來看其全貌，將其拆解為幾大模組，然後再分別詳細研究各個模組的細節，等了解了細節，再從全域性來看各各模組之間的關係，直到徹底了解整個系統。
Raft一致性協議
什麼是raft協議？我們應當知道，分布式儲存系統通常通過維護多個副本來進行容錯，提高系統的可用性。要實現此目標，就必須要解決分布式儲存系統的最核心問題 維護多個副本的一致性。raft協議就可以完成這個操作。為什麼用raft？除了raft，還有很多協議可以實現這個功能，比如說 兩階段提交協議，三階段提...
一致性演算法 Raft
乙個 raft 集群包含若干個伺服器節點 通常是 5 個，這允許整個系統容忍 2 個節點的失效，每個節點處於以下三種狀態之一 raft通過選出乙個leader來簡化日誌副本的管理，例如，日誌項 log entry 只允許從leader流向follower。基於leader的方法，raft演算法可以分...
raft 一致性演算法
redis使用raft leader election進行master選舉。概念 乙個cluster中有多個node，最終狀態有乙個leader，多個follower。leader通過heartbeat週期性和follower通訊。node有三種狀態 leader，follower，candidat...