ZooKeeper是一個分布式協(xié)調(diào)系統(tǒng)，應用廣泛捏鱼，其功能有：
服務發(fā)現(xiàn)
配置管理
分布式鎖
分布式領(lǐng)導選舉
zookeeper是一個樹形結(jié)構(gòu)蒙畴，類似Linux的文件系統(tǒng)，對每個節(jié)點提供監(jiān)控和通知的機制榴啸。
zookeeper集群是基于主從復制的孽惰，每個服務器可能有三種角色之一：
Leader
Follower
Observer
一個集群在同一時間，只能有一個實際工作的Leader鸥印，它會發(fā)起和維護與各Follower和Observer之間的心跳勋功。
所有的寫操作必須通過Leader完成，再由Leader將寫操作廣播給其他服務器库说。只要有超過半數(shù)節(jié)點（不包含observer節(jié)點）寫入成功狂鞋，該寫請求就會被提交。（類似2PC協(xié)議）
一個zookeeper可能存在多個follower潜的，它會響應Leader的心跳骚揍。follower可以直接處理并返回客戶端的讀請求，同時會將寫請求轉(zhuǎn)發(fā)給Leader處理夏块，并且負責在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é)議有兩種模式：恢復模式和廣播模式没咙。
當服務啟動或者Leader崩潰后猩谊，Zab就會進入恢復模式，當Leader被選舉出來祭刚，且Leader完成和大多數(shù)server的狀態(tài)同步之后牌捷，恢復模式就會結(jié)束。這個時候涡驮，Zab就會進入廣播模式暗甥。
如果一個新的server加入到zookeeper中，它會在回復模式下啟動捉捅，發(fā)現(xiàn)Leader淋袖，并和Leader進行狀態(tài)同步，然后也會參加消息廣播锯梁。
zookeeper服務會一直維持在broadcast狀態(tài)，知道Leader崩潰或者失去大多數(shù)followers的支持焰情。
廣播模式下陌凳，要保證所有提議（proposal）要按照順序處理，所以所有proposal都在被提出的時候加上了事務id（zxid）内舟，且zxid是遞增的合敦。
zxid是一個64位的數(shù)字，高32位表示紀元（epoch）验游，當選舉出一個新的Leader時充岛，epoch會加1，低32位清零耕蝉。低32位是一個遞增的計數(shù)器崔梗。
具體問題：Leader是怎樣被選舉出來的？
