背景：分佈式
一致性模型
1.弱一致性：（最終一致性）
1.1 DNS
1.1 Gossip
2.強一致性：
2.1 同步
2.1 paxos
2.1 raft（multi-paxos）
2.1 ZAB（multi-paxos）----與raft相似，心跳發起者相反（raft由master發起心跳，zab由slave發起）
注：強一致性的算法主要是保證：多數派、順序性
概念區分：raft、paxos算法實際上是狀態機複製的共識算法，raft/paxos/zab + client = 一致性算法
paxos算法：
作者論文中模型的概念：
- Proposal提案，即分佈式系統的修改請求，可以表示爲[提案編號N，提案內容value]
- Client用戶，類似社會民衆，負責提出建議
- Propser議員，類似基層人大代表，負責幫Client上交提案
- Acceptor投票者，類似全國人大代表，負責爲提案投票，不同意比自己以前接收過的提案編號要小的提案，其他提案都同意，例如A以前給N號提案表決過，那麼再收到小於等於N號的提案時就直接拒絕了
- Learner提案接受者，類似記錄被通過提案的記錄員，負責記錄提案
其他總結：
basic-Paxos：
邏輯流程圖：
1.客戶端發起寫請求
2.proposer負責轉發（專職人員---表示請求合法性）
3.發送給有投票權的Acceptor
4.Acceptor同意update或者insert，返回proposer，並通知learner記錄下來
注：Acceptor纔是真正的數據節點，主要保證的是Acceptor數據的一致性
multi Paxos：
設計理由：basic paxos的弊端
1.難以實現
2.效率較低（2輪RPC、一輪類似於選舉leader、一輪寫入請求）
3.活鎖（存在多個proposer，就會出現同時提出多個法案，或者說請求，acceptor會選取版本號大的，認爲版本號小的過時了，這樣就可能出現各個請求由於重試，增大版本號，相互競爭，卻都不能寫入成功-----通常給定一個隨機的等待時間解決，重試之前等待，但是依然不是很優雅）
基本流程：（角色未簡化）
大致邏輯與basic paxos一致
主要優化：
只有一個proposer----只有一個可以合法發送請求者，這個proposer的高可用性可以通過集羣實現，所以會有選舉leader流程（確認身份）（啓動、異常時），保證不需要每次都進行請求的版本檢查，減少一次rpc、不會有請求衝突
簡化角色：將proposer和acceptor整合成一個角色----分別是角色server的leader和follower
Raft算法：
設計理由：
1.paxos實現太複雜
2.raft爲paxos的簡化版
1.簡化成三個子問題：
1.1 Leader Election
1.2 Log Replication
1.3 Safety
2.重定義角色：
1.1 Leader
1.2 Follower
1.3 Candidate（可以理解成一種中間狀態，當Leader掛掉時候，follower想成爲leader先要成爲Candidate狀態）
過半原則寫入問題：
當機器節點被分爲兩個集羣（網絡不通）時，有過半原則；
例如：
3節點+2節點網絡斷開，3節點的集羣可以通過master正常寫入
2節點的集羣可接收請求，但是寫入會失敗，因爲沒有過半，但是2節點的集羣也是在運作的，並且也有一個leader，一個follower；由於這個小集羣不能寫入（不可用），所以還是認爲這個完整的集羣是隻有一個leader的
當網絡突然又好了，2節點的小集羣發現leader的版本號落後了，所以會選擇放棄自己沒有commit的數據，同步3節點的集羣的數據，達到一致性
以下兩個動畫是官方的，可以很好的理解raft原理，這裏不再贅述
原理動畫：http://thesecretlivesofdata.com/raft/
注：會降低一點可用性，幾百毫秒的不可用（請求timeout）