什麼是拜占庭將軍問題？
在很久很久以前，拜占庭是東羅馬帝國的首都。那個時候羅馬帝國國土遼闊，為了防禦目的，因此每個軍隊都分隔很遠，將軍與將軍之間只能靠信使傳遞訊息。在打仗的時候，拜占庭軍隊內所有將軍必需達成一致的共識，才能更好地贏得勝利。但是，在軍隊內有可能存有叛徒，擾亂將軍們的決定。這時候，在已知有成員不可靠的情況下，其餘忠誠的將軍需要在不受叛徒或間諜的影響下達成一致的協議。
拜占庭將軍問題其實說的是計算機網路中所存在的一致性問題
解決方案：比較有代表性的演算法—raft演算法
raft演算法是簡單易懂的共識演算法，依靠狀態機和主從同步的方式，在各個節點之間實現資料的一致性。
raft的兩個核心要點：
1.選取主節點
2.同步資料
raft演算法在選擇主節點是通過多個節點之間的投票競爭。
raft演算法為節點定義了三種角色（狀態機）：
1.leader（主節點）
2.follower（從節點）
3.candidate（參與投票競爭的節點）
第一步，在最初，還沒有乙個主節點的時候，所有節點的身份都是follower。每乙個節點都有自己的計時器，當計時達到了超時時間（election timeout），該節點會轉變為candidate。
第二步，成為candidate的節點，會首先給自己投票，然後向集群中其他所有的節點發起請求，要求大家都給自己投票。
第三步，其他收到投票請求且還未投票的follower節點會向發起者投票，發起者收到反饋通知後，票數增加。
第四步，當得票數超過了集群節點數量的一半，該節點晉公升為leader節點。leader節點會立刻向其他節點發出通知，告訴大家自己才是老大。收到通知的節點全部變為follower，並且各自的計時器清零。
這裡需要說明一點，每個節點的超時時間都是不一樣的。比如a節點的超時時間是3秒，b節點的超時時間是5秒，c節點的超時時間是4秒。這樣一來，a節點將會最先發起投票請求，而不是所有節點同時發起投票請求。
為什麼這樣設計呢？設想如果所有節點同時發起投票，必然會導致大家的票數差不多，形成僵局，誰也當不成老大。
那麼，成為leader的節點是否就坐穩了老大的位置呢？並不是。leader節點需要每隔一段時間向集群其他節點傳送心跳通知，表明你們的老大還活著。
一旦leader節點掛掉，發不出通知，那麼計時達到了超時時間的follower節點會轉變為candidate節點，發起選主投票，周而復始…
第一步，由客戶端提交資料到leader節點。
第二步，由leader節點把資料複製到集群內所有的follower節點。如果一次複製失敗，會不斷進行重試。
第三步，follower節點們接收到複製的資料，會反饋給leader節點。
第四步，如果leader節點接收到超過半數的follower反饋，表明複製成功。於是提交自己的資料，並通知客戶端資料提交成功。
第五步，由leader節點通知集群內所有的follower節點提交資料，從而完成資料同步流程。
etcd:共享配置和服務發現的kv儲存系統，使用raft演算法來保證分布式一致性
paxos 演算法：
早期的共識演算法，由拜占庭將軍問題的提出者 leslie lamport 所發明。谷歌的分布式鎖服務 chubby 就是以 paxos 演算法為基礎。
zab 演算法：
zookeeper 所使用的一致性演算法，在流程上和 raft 演算法比較接近。
pbft 演算法：
區塊鏈技術所使用的共識演算法之一，適用於私有鏈的共識。
分布式 Raft演算法
raft也是分布式一致性協議，主要是用來競選主節點。有三種節點 follower，candidate和leader。leader會週期性的傳送心跳給follower。每個follower都設定了乙個隨機的競選超時時間，一般為150ms 300ms，如果在這個時間內沒有收到leader的心跳包，就會變...
分布式系統的Raft演算法
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...
分布式系統的Raft演算法
過去,paxos一直是分布式協議的標準，但是paxos難於理解，更難以實現，google的分布式鎖系統chubby作為paxos實現曾經遭遇到很多坑。來自stanford的新的分布式協議研究稱為raft，它是乙個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。在了解raft之前，我們先了解...