分散式一致性協議實現原理
一致性演算法——Paxos、Raft、ZAB
1.1 CAP理論
分散式系統的CAP理論：理論首先把分散式系統中的三個特性進行了如下歸納：
● 一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
● 可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
● 分割槽容錯性（P）：以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。
1.2 什麼是一致性？
有兩種一致性模型，分別是弱一致性和強一致性
1）弱一致性
（1）最終一致性
DNS域名系統（英文：DomainNameSystem，縮寫：DNS）
在域名解析服務提供商上新增域名解析，一般都是10分鐘以內之後才能通過域名訪問到當前新增的網站，因為你的域名解析ip服務只在當前供應商的伺服器上新增，同步到全球或者全國需要一定的時間，在其他地區或者其他DNS伺服器就有可能訪問不到當前網站，需要等待一段時間。
2 ）強一致性
（1）同步
（2）Paxos
（3）Raft（multi-paxos）
（4）ZAB（multi-paxos）
1.3 Paxos
1）明確問題
一致性演算法的為什麼會出現，因為資料不能存在單節點上，但是存在叢集中有一致性的問題（網路、宕機等原因）。
但是有其他的演算法比如說主從，但是主從的可用性極低，一旦有一個節點宕機則無法對外提供服務。
所以需要在保持一致性的同時儘可能的提高可用性。
2）基本思想
多數派：
每次寫入都要保證寫入N/2的節點，每次讀保證從何大於N/2個幾點中讀取
多數派加順序存取：
在其基礎上，因為有叢集的概念，所以還有一個系統正確性需要保證，所以順序非常重要！
- 1
- 2
- 3
- 4
3）Basic Paxos
Paxos演算法是萊斯利·蘭伯特（Leslie Lamport，就是LaTeX中的"La"，此人現在在微軟研究院）於1990年提出的一種基於訊息傳遞的一致性演算法。這個演算法被認為是類似演算法中最有效的。
（1）角色介紹：
Client：產生議題者或者是請求發起者 ，類似於民眾
Proposer ：提議者，接收民眾的建議並提出議案，在衝突時有調節作用，類似於議員
Acceptor：決策者或者是投票者，國會成員或者議員等
Learner：最終決策記錄者 備份，對叢集一致性沒有影響
（2）基本流程：
（3）全票通過的場景
（4）部分Accepter通過
但是達到了1/2以上的節點，提案通過，反之則不通過
（5）proposer宕機或者失敗
當前提案不會通過，但是有其他的proposer處理（客戶端需要有重試機制）
（6）活鎖問題的產生
https://www.cnblogs.com/sunnyCx/p/8108366.html
timeout解決
4）Multi Paxos
（1）Basix Paxos問題
實現難
效率低（2輪RPC，來回驗證，效率低）
活鎖
- 1
- 2
- 3
（2）區別
Leader：唯一propser，選舉產生
所有的請求都經過leader
- 1
- 2
（3）基本流程
（4）簡化角色
1.4 Raft
http://thesecretlivesofdata.com/raft/
1）角色
（1）Leader
（2）Follwer
（3）Candidate
2）三個場景
（1）Leader Election
（2）Log Repliction
（3）Safety
10.5 ZAB
1.基本與Raft相同
2.叫法的區別：zab將某一個leader的週期成為epoch，而Raft稱之為term
3.心跳方向為leader向follower。ZAB則相反
- 1
- 2
- 3
1）協議原理
ZAB主要包括訊息廣播和崩潰恢復兩個過程，進一步可以分為三個階段，分別是發現（Discovery）、同步（Synchronization）、廣播（Broadcast）階段。ZAB的每一個分散式程序會迴圈執行這三個階段，稱為主程序週期。
· 發現，選舉產生PL(prospective leader)，PL收集Follower epoch(cepoch)，根據Follower的反饋，PL產生newepoch(每次選舉產生新Leader的同時產生新epoch)。
· 同步，PL補齊相比Follower多數派缺失的狀態、之後各Follower再補齊相比PL缺失的狀態，PL和Follower完成狀態同步後PL變為正式Leader(established leader)。
· 廣播，Leader處理客戶端的寫操作，並將狀態變更廣播至Follower，Follower多數派通過之後Leader發起將狀態變更落地(deliver/commit)。
在正常執行過程中，ZAB協議會一直運行於階段三來反覆進行訊息廣播流程，如果出現崩潰或其他原因導致Leader缺失，那麼此時ZAB協議會再次進入發現階段，選舉新的Leader。
2）執行狀態
每個程序都有可能處於如下三種狀態之一
· LOOKING：Leader選舉階段。
· FOLLOWING：Follower伺服器和Leader伺服器保持同步狀態。
· LEADING：Leader伺服器作為主程序領導狀態。