一、Raft算法是什么？
過去，Paxos一直是分布式協議的標准，但是Paxos難於理解，更難以實現，Google的分布式鎖系統Chubby作為Paxos實現曾經遭遇到很多坑。后來斯坦福大學提出了Raft算法。
Raft是用於管理復制日志的一致性算法。它的效果相當於(multi-)Paxos，跟Paxos一樣高效，但結構與Paxos不同。這使得Raft比Paxos更容易理解，也為構建實用系統提供了更好的基礎。
下圖是斯坦福大學的Diego Ongaro和John Ousterhout在《In Search of an Understandable Consensus Algorithm》一文（提出Raft算法的論文）中，依據Raft學習難度的實驗數據繪制的。實驗對象是斯坦福大學和加州大學伯克利分校的高年級本科生和研究生。這些天才也覺得Paxos很難。所以對於大多數人看不懂Paxos算法是很正常的，看不懂Raft原理也不奇怪。
二、什么是一致性（Consensus）
一致性是分布式系統容錯的基本問題。一致性涉及多個服務器狀態（Values）達成一致。 一旦他們就狀態做出決定，該決定就是最終決定。 當大多數服務器可用時，典型的一致性算法會取得進展。例如，即使2台服務器發生故障，5台服務器的集群也可以繼續運行。 如果更多服務器失敗，它們將停止進展（但永遠不會返回錯誤的結果）。
三、Raft算法
論文Raft算法介紹的章節包括6個部分，了解個大概就行，然后拉到本文后邊，有個可操作的游戲輔助理解這個算法。
1、Raft基礎知識
Raft集群包含多個服務器，5個服務器是比較典型的，允許系統容忍兩個故障。在任何給定時間，每個服務器都處於以下三種狀態之一，領導者（Leader），追隨者（Follower）或候選人（Candidate）。 這幾個狀態見可以相互轉換。
Leader：處理所有客戶端交互，日志復制等，一般一次只有一個Leader
Follower：類似選民，完全被動
Candidate：類似Proposer律師，可以被選為一個新的領導人
2、選舉Leader
Raft使用心跳機制來觸發領導者選舉。 當服務器啟動時，它們以Follower的身份開始。 只要服務器從Leader或Candidate接收到有效的RPC請求，服務器就會保持Follower狀態。 Leader向所有Follower發送定期心跳（不帶日志條目的AppendEntries RPC）以保持其權限。 如果一個Follower在稱為選舉超時的一段時間內沒有接到任何通信，該Follower認為沒有可行的領導者並開始選舉新的Leader。
3、日志復制
一旦Leader當選，它就開始為客戶請求提供服務。每個客戶端請求包含由復制狀態機執行的命令。Leader將命令作為新條目附加到其日志，然后並行地向每個其他服務器發出AppendEntries RPC以復制條目。當條目被安全地復制時，Leader將條目應用於其狀態機並將該執行的結果返回給客戶端。如果Follower崩潰或運行緩慢，或者網絡數據包丟失，Leader將無限期地重試AppendEntries RPC（即使它已經響應客戶端），直到所有Follower最終存儲所有日志條目。（后邊游戲中有個request命令菜單，就是模仿客戶端請求的）
除了以上3點，文章還重點描述了安全、Follower和Candidate崩潰、時間和可用性三個方面。
四、可視化的Raft算法
github上有一個幫助大家理解算法的頁面，地址是
建議用電腦瀏覽器打開，如果在手機微信里打開，需要選擇“訪問原網頁”
我截了一個運行狀態的截圖，左側顯示五台服務器，右側顯示日志。
在服務器圖標上點擊鼠標右鍵會出現操作菜單。操作菜單對應服務節點的狀態改變，其中request模擬客戶端請求服務器集群執行任務，會在右邊產生日志。
多操作一會，一定能夠理解Raft算法是怎么運行的!
五、總結
Raft算法具備強一致、高可靠、高可用等優點，具體體現在：
強一致性：雖然所有節點的數據並非實時一致，但Raft算法保證Leader節點的數據最全，同時所有請求都由Leader處理，所以在客戶端角度看是強一致性的。
高可靠性：Raft算法保證了Committed的日志不會被修改，State Matchine只應用Committed的日志，所以當客戶端收到請求成功即代表數據不再改變。Committed日志在大多數節點上冗余存儲，少於一半的磁盤故障數據不會丟失。
高可用性：從Raft算法原理可以看出，選舉和日志同步都只需要大多數的節點正常互聯即可，所以少量節點故障或網絡異常不會影響系統的可用性。即使Leader故障，在選舉超時到期后，集群自發選舉新Leader，無需人工干預，不可用時間極小。但Leader故障時存在重復數據問題，需要業務去重或冪等性保證。
高性能：與必須將數據寫到所有節點才能返回客戶端成功的算法相比，Raft算法只需要大多數節點成功即可，少量節點處理緩慢不會延緩整體系統運行。
來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/31556438/viewspace-2637112/