ZooKeeper是一個分布式協(xié)調(diào)系統(tǒng)，應(yīng)用廣泛，其功能有：
服務(wù)發(fā)現(xiàn)
配置管理
分布式鎖
分布式領(lǐng)導(dǎo)選舉
zookeeper是一個樹形結(jié)構(gòu)，類似Linux的文件系統(tǒng)，對每個節(jié)點提供監(jiān)控和通知的機制。

zookeeper集群是基于主從復(fù)制的，每個服務(wù)器可能有三種角色之一：
Leader
Follower
Observer
一個集群在同一時間，只能有一個實際工作的Leader，它會發(fā)起和維護與各Follower和Observer之間的心跳。

所有的寫操作必須通過Leader完成，再由Leader將寫操作廣播給其他服務(wù)器。只要有超過半數(shù)節(jié)點（不包含observer節(jié)點）寫入成功，該寫請求就會被提交。（類似2PC協(xié)議）

一個zookeeper可能存在多個follower，它會響應(yīng)Leader的心跳。follower可以直接處理并返回客戶端的讀請求，同時會將寫請求轉(zhuǎn)發(fā)給Leader處理，并且負責(zé)在Leader處理寫請求時，對請求進行投票。

角色與follower類似，但是無權(quán)發(fā)起投票。zookeeper需要保證高可用行和強一致性，為了支持更多的客戶端，需要很多server，但是server多了以后，投票階段的延遲增大，會影響性能，基于這種考慮才會引入observer這種角色。Observers可以接受客戶端的連接，并將寫請求轉(zhuǎn)發(fā)給Leader節(jié)點，這樣就提高了伸縮性，但不會降低吞吐率。

zookeeper的核心是原子廣播（Atomic Broadcast），這個機制保證了各個server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議，這個協(xié)議有兩種模式：恢復(fù)模式和廣播模式。

當(dāng)服務(wù)啟動或者Leader崩潰后，Zab就會進入恢復(fù)模式，當(dāng)Leader被選舉出來，且Leader完成和大多數(shù)server的狀態(tài)同步之后，恢復(fù)模式就會結(jié)束。這個時候，Zab就會進入廣播模式。

如果一個新的server加入到zookeeper中，它會在回復(fù)模式下啟動，發(fā)現(xiàn)Leader，并和Leader進行狀態(tài)同步，然后也會參加消息廣播。

zookeeper服務(wù)會一直維持在broadcast狀態(tài)，知道Leader崩潰或者失去大多數(shù)followers的支持。

廣播模式下，要保證所有提議（proposal）要按照順序處理，所以所有proposal都在被提出的時候加上了事務(wù)id（zxid），且zxid是遞增的。

zxid是一個64位的數(shù)字，高32位表示紀(jì)元（epoch），當(dāng)選舉出一個新的Leader時，epoch會加1，低32位清零。低32位是一個遞增的計數(shù)器。

具體問題：Leader是怎樣被選舉出來的？