Master选举，是分布式系统中常见的应用场景。在分布式系统中，Master往往用来协调集群中的其他系统单元，具有对分布式系统状态变更的决定权。
比如，在读写分离应用中，客户端的写请求往往是由Master来处理（比如MySQL分布式集群），在另一些场景中，master往往处理一些复杂的逻辑，并将处理结果同步给集群中其他系统单元（比如redis，一主三从）。
Master选举是zookeeper种最典型的应用场景。在zookeeper集群中，分别有leader/follower /observer三种类型的服务器角色，Master选举就是选举出主要Leader的过程。
集群角色介绍：
Leader：
是整个zookeeper集群工作机制中的核心，
主要工作：
事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
集群内部各服务器的调度者。
Follower:
是zookeeper集群状态的跟随者
主要工作：
处理客户端非事务请求，转发事务请求给Leader服务器
参与事务请求Proposal的投票
参与Leader选举投票
Observer：
是3.3.0版本后引入的一个全新的服务器角色。
观察zookeeper集群的最新状态变化并将这些状态变更同步进来。
对于非事务请求可以处理，对于事务请求，转发给Leader服务器进行处理
不参与任何形式的投票
Leader选举步骤：
1、初始化Leader选举
首先，每个服务器都会给自己投票
然后，根据zoo.cfg中的配置，创建相应leader选举算法。默认提供三种： LeaderElection/AuthFastLeaderElection/FastLeaderElection
但是3.4.0之后，只有一个算法：FastLeaderElection
同时创建选举所需的网络I/O层，同时启动leader选举端口的监听。
2、注册JMX服务
3、检测当前服务器状态
正常情况下：zookeeper服务器状态在LOOKING、LEADING和FOLLOWING/OBSERVING之间的切换。
在LOOKING状态下才可以选举
- LOOKING:寻找Leader状态。
- FOLLOWING:跟随者状态，代表该服务器角色是Follower
- LEADING:领导者状态，代表该服务器角色是Leader
- OBSERVING:观察者状态，代表该服务器角色是Observer
4、Leader选举
简而言之，就是哪个机器处理的数据越新，就越可能成为Leader。
SID：服务器ID，也就是myid
ZXID：事务ID，用来唯一标识一次服务器状态的变更。
epoch：当前服务器的currentEpoch
如果集群中所有的机器处理的ZXID一致，那么SID最大的服务器成为Leader。
应用时期
注：1台机器是无法完成选举的，至少有两台才行
服务器启动时期的Leader选举
1、每个server会发出一个投票
每次投票包含的最基本的元素包括：myid和ZXID。
一开始每台服务器都给自己投一票：（1，0）；（2,0）
2、接收来自各个服务器的投票
3、处理投票
针对每个投票，服务器都要将别人的投票和自己的PK：
- 优先检查ZXID，ZXID比较大的服务器优先作为Leader。
- 如果ZXID相同，就比较myid，myid大的作为Leader服务器。
4、统计投票
5、确定leader之后，就改变自己服务器的状态。
服务器运行期间的Leader选举
1、变更状态
变成LOOKING状态
2、每个Server会发出一个投票
生成各自的投票信息（myid,ZXID）
3、接收来自各个服务器的投票
4、处理投票
5、统计投票
6、改变服务器状态
Leader 选举是zookeeper中最重要的技术之一，也是保证分布式数据一致性的关键。