Zookeeper自动选主

zookeeper，一个致力于分布式应用程序协调服务的框架。
使用场景包括：
1、配置中心
2、命名服务（RPC的使用场景，Eureka也是个不错的选择）
3、通知协调（基于zk的发布订阅功能）
4、心跳检测
5、Master选举（抢占式，类似redis的setnx，只能创建一个，创建成功的抢占成功）
6、锁
上面很多场景都是基于zk的watcher监听机制，当监听的节点发生变更会通知所有监听该节点的客户端，而通知则是基于zk的原子广播（基于Zab协议）。
而ZAB协议有两种模式：
1、广播模式，zk大部分时间处于广播模式。主要处理客户端请求和leader与Follow之间的状态同步。
1、恢复模式，当系统启动或者leader节点down掉或者失去大部分Follow的时候进入恢复模式，进行选主流程。

自动选主
了解这个过程，分四个步骤
1、系统角色

角色	描述
Leader	领导者，负责进行投票的发起和决议，更新系统状态
Follower	跟随者（学习者），用于接受客户端请求并发挥结果，在选中过程中参与投票
ObServer	观察者（学习者），要手动修改配置指定一个Server为观察者，可以接受请求，但是转发给leader处理，不参与投票，只同步状态，接受投票结果

2、交互事件（选举过程中跟随者节点之间持续发生的事件）
（1）发送消息给其他节点
（2）接受其他节点发送过来的信息
（3）处理其他节点发送过来的信息

3、消息内容
（1）myid：来源节点想要推举的leaderid，和zxid用（myid，zxid表示）
（2）id：来源节点的id（可以等于leaderid，即自己推举自己当leader）
（3）zxid：来源节点当前数据版本，值越大则数据越新，这是成为leader最重要的条件
（4）epoch：当前选举轮次标识（逻辑时钟），值越大则轮次越新，成为leader的首要条件。

4、选主过程
（1）集群启动
（2）集群每个服务节点都没有数据，数据版本都相等，即为默认值。
（3）此时没有leader，每个节点都推举自己当leader，即id=myid，将以上四个信息广播给其他所有节点（包括自己）
（4）接受到其他节点发送的信息的节点，先要判断来源节点状体，如果对方处于Looking，且自己处于Following或者leading则直接回复消息通知来源节点，leading已产生，请尽快同步。如果自己也处于looking状态，则对来源信息和自己的信息进行对比。1.对比epoch，采用值较大者的信息。2.如果epoch一样则对比zxid，采用值较大者的信息。3.如果zxid也一样，则比较节点id，采用值较大者的信息。如果采用的是来源节点的信息，则更新自己的节点信息，并且广播给其他节点。否则直接将自己的信息直接广播给其他节点。
（5）直到某轮选举已经选出被绝大多数节点承认的leader，其他节点同步新leader的状态。