1. leader選舉流程解剖
leaderElection/AuthFastLeaderElection/FastLeaderEletion(默認)
FastLeaderElection
- serverId:在配置server集群的時候，給定服務器的標識id(myid)
- zxid:服務器在運行時產生的數據ID，zxid的值越大，表示數據越新
- Epoch：選舉輪數
- server的狀態：Looking、Following、Observering、Leading
第一次初始化啟動的時候：Looking
- 所有在集群中的server都會推薦自己為leader，然後把（myid、zxid、epoch)作為廣播信息，廣播給集群中的其他server,然後等待其他服務器返回
- 每個服務器都會接受來自集群中的其他服務器的投票。集群中的每個服務器在接受投票後，開始判斷投票的有效性判斷邏輯時鐘（Epoch）,如果Epoch大於自己當前的Epoch，說明自己保存的Epoch是過期。更新Epoch，同時clear其他服務器發送過來的選舉數據。判斷是否需要更新當前的選舉情況如果Epoch小於目前的Epoch，說明對方的epoch過期，也就意味著對方服務器的選舉輪數是過期的。這個時候，只需要將自己的信息發送給對方
2. ZAB協議
拜占庭問題: 在古代，一些拜占庭的將軍率領他們的部隊要攻佔敵人的一個城池, 每個將軍只能控制他們自己的部隊並且通過信使傳遞消息給其他的將軍(這條消息只有參與的兩個將軍知道，其他的將軍可以打聽，但是不能驗證消息的正確性)。如果這些將軍中有些是來自敵方的奸細，那麼如何使忠誠的將軍仍然可以達成行動協議而不受奸細的挑撥，就是拜占庭將軍問題
paxos協議主要就是如何保證分佈式網絡環境下,各個服務器如何達成一致，最終保證數據一致性問題
ZAB協議是基於paxos的一個改進
- ZAB協議為分佈式協調服務zookeeper專門設計的一種支持崩潰恢復的原子廣播協議
- zookeeper並沒有完全採用paxos算法，而是採用ZAB Zookeeper Atomic Broadcast
ZAB協議的工作原理
- 在zookeeper的主備模式下，通過zab協議來保證集群中各個副本數據的一致性
- zookeeper使用的是單一的主進程來接受並處理所有的事務請求，並採用zab協議把數據狀態變更以事務請求的形式廣播到其他的節點
- zab協議在主備模型的架構中，保證了同一時刻只能有一個主進程來廣播服務器的狀態變更
- 所有的事務請求必須由全局唯一的服務器來協調處理，這個服務器叫leader，其他的叫follower,leader節點主要負責把客戶端的事務請求轉化為一個事務提議（proposal)，並分發給集群中的所有follower節點，在等待所有follower節點的反饋。一旦超過半數服務器進行了正確的反饋，那麼leader就會commit這條消息
zab協議使用場景
- 什麼情況下zab協議會進入崩潰恢復模式
- 當服務器啟動時
- 當leader服務器出現網絡中斷、崩潰或者重啟的情況
- 急群眾已經不存在過半的服務器與該leader保持正常通信
- zab協議進入崩潰恢復模式會做什麼
- 當leader出現問題，zab協議進入崩潰恢復模式，並且選舉出新的leader。當新的leader選舉出來以後，如果集群中已經有過半的機器完成了leader服務器的狀態同（數據同步），退出崩潰恢復，進入消息廣播模式
- 當新的機器加入到集群中的時候，如果已經存在leader服務器，那麼新加入的服務器就會自覺進入數據恢復模式，找到leader進行數據同步
FAQ：
假設一個事務在leader服務器被提交了，並且已經有過半的follower返回了ack.在leader節把commit消息發送給follower機器之前leader服務器掛了怎麼辦
- zab協議，一定需要保證已經被leader提交的事務也能夠被所有follower提交
- zab協議需要保證在崩潰恢復過程中跳過那些已經被丟棄的事務
分享到:
