zookeeper選舉機制
不對的地方歡迎指出！
zk作爲一個分佈式調用的系統，它具有分佈式管理的特點，我們在學習線程的時候是有個並行的概念，多個線程並行處理一段程序，而分佈式主要應用在多臺服務器共同處理一些模塊的服務，他已經不是單獨小塊代碼，而是一個功能，可以想象一下，淘寶這個app時時刻刻都會有很多人進行下單退單，逛淘寶等等操作，那麼他背後是勢必依賴十分多的機器去跑這個程序才能讓用戶正常使用這個APP的，這就是我對分佈式的一個粗淺理解。
一、zk集羣的角色與作用
三種角色：不同角色在zk集羣裏的作用就不一樣
1. leader
(1)只有這個角色擁有寫數據的功能；
(2)發起決議，當他有接收到讀寫請求的時候，會發起投票和決議誰去處理這個請求，當然寫只能他寫；
(3)恢復更新系統狀態（數據），一般實在選舉成爲leader的之後。
2. follower
(1)接收客戶端請求，若是爲寫請求則提交給leader；
(2)返回客戶端處理結果；
(3)接收來自leader的信息並處理，參與leader投票；
(4)向leader發送請求。
3. observer
爲了提高讀取性能而存在的（集羣的讀請求負載過高，多到垮機層）；
協助follower處理讀請求，但是與follower不同，它不參與投票；
不會因爲自己的宕機影響整個集羣。
二、zk集羣選舉核心概念與選舉狀態
myid:zk集羣服務器的唯一標識
zxid：long類型，共64位，高32位是epoch，低32是xid，每個leader都有一個epoch，表示這是它的統治時代。xid，則表示zk事務id，每一個寫操作都是一個事務，都有一個xid，每個寫操作都需要由一個leader發起提議，由所有follower表決是否通過本次的寫操作。
選舉狀態
looking：選舉狀態，查找leader
leading：領導者
following：隨從
observing：觀察
三、zk集羣發生時機與選舉算法
時機：服務器啓動或者leader宕機
參與人員：follower，所以我們一般會需要奇數臺服務器，leader宕機，observe不參與，還是剩下奇數臺服務器進行投票
選舉算法
1.啓動的時候
（1）每個serve發出投票：每個服務器的狀態都是looking，然後第一臺投自己，（myid，Zxid）-（1，0）
（2）接收來自其他服務器的投票：第二臺接收到來自第一臺服務器的投票，並投自己（2，0）併發布自己的投票結果；
（3）處理投票信息：第一臺得到結果就去比較zxid，一樣，比較myid，發現對方的比較大，則更新自己的投票爲（1,0）-（2,0），重新投票
規則
優先檢查ZXID。ZXID比較大的服務器優先作爲Leader。
如果ZXID相同，那麼就比較myid。myid較大的服務器作爲Leader服務器。
（4）統計投票：每次投票之後，服務器都會統計投票信息，若是超過半數的服務器都投了一個，那就產生leader。
（5）改變服務器的狀態：原本是looking的大家就改爲leading或者following
2.leader宕機
當follower連接不上自己的leader的時候，就會將自己的狀態改爲looking，然後不再處理新的客戶端請求，直到新的leader產生。
選舉過程：
（1）變更狀態，follower將自己的狀態改爲looking，開始選舉
（2）每個server會發出一個投票（myid,zxid）
（3）接收來自其他服務器的投票，與啓動過程一樣
（4）處理投票
（5）統計投票
（6）改變服務器狀態
四、zk集羣三種模式
- 恢復模式
當服務啓動或者leader宕機之後，ZAB就進入了恢復模式，選舉新leader，更新系統狀態； - 同步模式
新leader選舉出來後進入同步模式；
各個follow會同步新leader數據，zkserver數據同步之後，恢復結束 - 廣播模式
保證zk數據同步一致，利用的是ZAB協議
ZAB協議的消息廣播過程使用的是一個原子廣播協議，類似於一個2PC提交過程，針對每個客戶端的事務請求，leader服務器會爲其生成對應的事務Proposal，並將其發送給集羣中其餘所有的機器，然後再分別收集各自的選票，最後進行事務提交。
廣播模式需要保證proposal被按順序處理，因此zk採用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。