中我們成功論證了raft保證集群資料一致性的問題。然而現實世界是非常複雜的，任何情況都可能發生。那麼對於各種異常場景raft集群究竟如何應對的呢？
文章的同學可以先看一下，這篇相當於上篇的加強補充篇。
在乙個集群中，如果發生了網路分割槽，會不會出現兩個leader導致資料不一致呢？
上圖中展示了由5個藍色節點組成的raft集群，綠色代表client，用黑色圈起來的b是當前的leader。這個時候發生了網路分割槽（黑色虛線把集群分成了上下兩部分）。上方c、d、e三個follower處於乙個分割槽，由於當前沒有leader，會出現心跳超時，部分節點成為candidate，而三個節點是多數派，最終能選舉出乙個leader。而下方的分割槽只有兩個節點，b作為old leader雖然仍能接受client寫入請求，但是無法在多數節點寫入（多數至少需要3個節點），故無法提交。
如下圖詳細分析一下，e被推選為上方分割槽leader後，這時客戶端傳送「set 8」的請求，能夠得到c、d的成功響應，加上e自身共三個，形成多數，所以請求被提交，服務正常執行。下方分割槽old leader b接受乙個客戶端「set 3」的寫入請求，由於無法形成多數，請求會一直無法提交，客戶端得不到成功的響應，最終超時。
集群在執行的過程中，有可能出現一種比較複雜的情況，如下圖。
集群有s1-s5五個節點，方塊中數字表示任期號term，用粗線框起來代表當前任期的leader。最上方一行數字表示log index。
leader永遠只主動提交最新接受到的log entry。一旦最新的entry被提交成功，之前的entry就自動預設都已提交。
參考引用
diego ongaro，john ousterhout.《in search of an understandable consensus algorithm(extended version)》
分布式一致性演算法Raft
我們先來看乙個例子 我們有乙個單節點node，這個節點可以是資料庫，也可以是一台伺服器，當client向node傳送data時，x節點收到data，記錄下來 由此可見對於單個節點，一致性是很容易實現的。然而對於多個節點，我們如何來實現一致性，這就是分布式一致性的問題。raft就是乙個實現分布式一致性...
Raft一致性協議
什麼是raft協議？我們應當知道，分布式儲存系統通常通過維護多個副本來進行容錯，提高系統的可用性。要實現此目標，就必須要解決分布式儲存系統的最核心問題 維護多個副本的一致性。raft協議就可以完成這個操作。為什麼用raft？除了raft，還有很多協議可以實現這個功能，比如說 兩階段提交協議，三階段提...
分布式一致性協議Raft 從入門到愛上
在分布式領域，始終都要面臨的乙個挑戰就是 資料一致性。它是指資料在各個機器節點上流轉的時候，如何保證任一時刻資料都是正確並且最新的。為此，萊斯利 蘭伯特 leslie lamport 在1990年提出了一種實現演算法，也就是著名的paxos。如今它是業界公認此類問題的最有效解。雖然paxos在理論界...