ZooKeeper是一个分布式协调系统，应用广泛，其功能有：
服务发现
配置管理
分布式锁
分布式领导选举
zookeeper是一个树形结构，类似Linux的文件系统，对每个节点提供监控和通知的机制。
zookeeper集群是基于主从复制的，每个服务器可能有三种角色之一：
Leader
Follower
Observer
一个集群在同一时间，只能有一个实际工作的Leader，它会发起和维护与各Follower和Observer之间的心跳。
所有的写操作必须通过Leader完成，再由Leader将写操作广播给其他服务器。只要有超过半数节点（不包含observer节点）写入成功，该写请求就会被提交。（类似2PC协议）
一个zookeeper可能存在多个follower，它会响应Leader的心跳。follower可以直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时，对请求进行投票。
角色与follower类似，但是无权发起投票。zookeeper需要保证高可用行和强一致性，为了支持更多的客户端，需要很多server，但是server多了以后，投票阶段的延迟增大，会影响性能，基于这种考虑才会引入observer这种角色。Observers可以接受客户端的连接，并将写请求转发给Leader节点，这样就提高了伸缩性，但不会降低吞吐率。
zookeeper的核心是原子广播（Atomic Broadcast），这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议，这个协议有两种模式：恢复模式和广播模式。
当服务启动或者Leader崩溃后，Zab就会进入恢复模式，当Leader被选举出来，且Leader完成和大多数server的状态同步之后，恢复模式就会结束。这个时候，Zab就会进入广播模式。
如果一个新的server加入到zookeeper中，它会在回复模式下启动，发现Leader，并和Leader进行状态同步，然后也会参加消息广播。
zookeeper服务会一直维持在broadcast状态，知道Leader崩溃或者失去大多数followers的支持。
广播模式下，要保证所有提议（proposal）要按照顺序处理，所以所有proposal都在被提出的时候加上了事务id（zxid），且zxid是递增的。
zxid是一个64位的数字，高32位表示纪元（epoch），当选举出一个新的Leader时，epoch会加1，低32位清零。低32位是一个递增的计数器。
具体问题：Leader是怎样被选举出来的？
