Zookeeper选举机制

   ZooKeeper 是一个开放源码的分布式应用程序协调服务，它具有可靠的、可扩展的、分布式的、可配置的协调机制。它的核心是原子广播，这个机制保证了各个Server之间的同步。

   实现原子广播机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了，状态同步保证了leader和Server具有相同的系统状态。
每个Server在工作过程中有三种状态：
  looking：当前Server不知道leader是谁，正在搜寻
  leading：当前Server即为选举出来的leader
  following：leader已经选举出来，当前Server与之同步

1. 选主流程

   Leader选举是保证分布式数据一致性的关键所在。当Leader崩溃或者Leader失去大多数的Follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

特点：
1）半数机制：集群中半数以上机器存活，集群状态正常。所以Zookeeper适合安装奇数台服务器。

2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

Leader选主条件：
   (1) 服务器初始化启动。
   (2) 服务器运行期间无法和Leader保持连接。

1. 首先来看服务器初始化时的选主：
      若进行Leader选举，则至少需要两台机器，这里选取5台机器组成的服务器集群为例。
   (1) 每个Server发出一个投票。 每台服务器调整为looking状态，将的myid和ZXID发送到其他服务器，使用(myid, ZXID)来表示。如：server1(1,0)，server2(2,0)
   (2) 接受来自各个服务器的投票。 集群中每台服务器收到投票后会判断信息的有效性。如：检查发送来投票的服务器是否都是looking状态。
   (3) 投票PK，选出Leader 每台服务器将自己的投票和其他投票进行PK，先比较ZXID，如果ZXID再比较myid。（ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction Id, 该id称为zxid.）
   假设这个时候所有服务器的ZXID均为0； 五台服务器的myid依次为1,2,3,4,5。
      server1状态修改为looking并发出投票
      server2状态修改为looking并发出投票，然后检查server1的投票，再与server1进行PK，选出自己为Leader。
      server3状态修改为looking并发出投票，然后检查server1和server2的投票，再与server2进行PK，选出在即为Leader。
      server4状态修改为looking并发出投票，然后检查server1和server2，server3的投票，发现5个服务器中已经有3台选择server3为Leader，根据半数原则，自己也会认为server3为Leader，不再进行PK。
      server5状态修改为looking并发出投票，然后检查server1~4的投票，过程与server4一样不再进行PK，默认server3为Leader。

2. 然后再看服务器运行时期的Leader选举
   在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。但这个时候的投票PK，主要比较的ZXID而不是myid。

2. 同步流程

选完Leader以后，zk就进入状态同步过程。

   1. Leader等待其他server连接；
   2. server连接leader，将最大的zxid发送给Leader；
   3. Leader根据server的zxid确定同步点；
   4. 完成同步后Leader会通知其他server自己已经成为leading状态；
   5. server收到Leader消息后，将自己状态调整为following，并发送通知到Leader；
   6. Leader收到所有server的消息后，认为状态同步完成，告之Follower节点；
   7. Follower收到Leader的消息后，也会认为状态同步完成，并重新接受client的请求进行服务。

3. 工作流程

Leader：
1. 首先会恢复自身数据，然后与Follower之间保持心跳，接收Follower的请求并判断请求类型。(接收Follower请求的过程中Leader会一直判断自身是否与Follower之间心跳同步)
2. Follower的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，Leader会根据不同的消息类型，进行不同的处理。
  PING消息是指Follower的心跳信息；当收到PING的心跳信息不足集群服务器的一半时，会重新进入Leader选主模式选择Leader。
  REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；
  ACK消息是Follower对提议的回复，超过半数的Follower通过，则commit该提议；
  REVALIDATE消息是用来延长SESSION有效时间。

Follower：
1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2 .接收Leader消息并进行处理；
3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
4 .返回Client结果。

Follower的消息循环处理如下几种来自Leader的消息：
1 .PING消息： 心跳消息；
2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
3 .COMMIT消息：服务器端最新一次提案的信息；
4 .UPTODATE消息：表明同步完成；
5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。