Zookeeper-Lead选举2

5 终极判断，判断recvset中投同一个leader的选票有没有过半

  选票过半，再从队列中尝试获取选票，若能获取到更新的选票则还需要继续循环，

  未获取到更新选票，就再次说明投票有效，直接返回投票，并设置当前服务器的状态（如果选的是当前服务器则设为LEADING，否则FOLLOWING）

  投票未过半，继续循环，从队列中获取选票，回到while循环，继续从队列中获取选票

case:LEADING/FOLLOWING

说明投票已经结束，获取投票结果，设置当前服务器的状态（如果选的是当前服务器则设为LEADING，否则FOLLOWING）

典型示例：

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。

服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。

服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。

服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。

服务器5启动，后面的逻辑同服务器4成为小弟。

ZAB协议

协议四个阶段：http://blog.xiaohansong.com/2016/08/25/zab/

选举，发现，同步，广播

协议的Java版本实现：

实际的实现将发现和同步合并为 Recovery Phase（恢复阶段），所以实际实现，有三个阶段：

Leader Election Leader选举，Recovery 崩溃恢复，Broadcast广播

Recovery 崩溃恢复

这一阶段 follower 发送它们的 lastZixd 给 leader，leader 根据 lastZixd 决定如何同步数据。

然后，follower执行同步leader数据

Broadcast广播

所有的写请求都由 leader 来处理。

值得注意的是，ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，只需要得到 quorum （超过半数的节点）的 ACK 就可以了。

ZAB协议的二阶段提交过程中，移除了中断逻辑（事务回滚），

所有follower服务器要么正常反馈leader提出的事务proposal，要么就抛弃leader服务器。

follower收到proposal后的处理很简单，将该proposal写入到事务日志，然后立马反馈ACK给leader。

leader收到过半follower的ACK后，会广播commit消息给所有learner，并将事务应用到内存；learner收到commit消息后会将事务应用到内存。