zookeeper-非常重要的zab协议

myid：用户在配置文件中自己配置，每个节点都要配置的一个唯一值，从1开始往后累加。

zxid：zxid有64位，分成两部分：

高32位是Leader的epoch：选举时钟，每次选出新的Leader，epoch累加1

低32位是在这轮epoch内的事务id：对于用户的每一次更新操作集群都会累加1。

注意：zk把epoch和事务id合在一起，每次epoch变化，都将低32位的序号重置，这样做是为了方便对比出最新的数据，保证了zxid的全局递增性。（其实这样也会存在问题，虽然概率小，这里就先不说了后面的文章会详细讲）。

关于发送选票

第一轮投给自己，之后每个服把上述所有信息发送给其他所有服，票箱中只会记录每一投票者的最后一票

关于接收投票

服务器会尝试从其它服务器获取投票，并记入自己的投票箱内。如果无法获取任何外部投票，则会确认自己是否与集群中其它服务器保持着有效连接。如果是，则再次发送自己的投票；如果否，则马上与之建立连接。

关于选举轮次

由于所有有效的投票都必须在同一轮次中。每开始新一轮投票自身的logicClock自增1。

接收到的logicClock大于自己的。说明自己落后了，更新logicClock后正常。 接收到的logicClock小于自己的。忽略该票。 接收到的logickClock与自己的相等，正常判断。 关于选票判断

对比自身的和接收到的(myid,zxid)

首先对比zxid高32位的选举时钟epoch 一致则对比zxid低32的事务id 仍然一致则对比用户自己配置的myid 

选完后广播选出的(myid,zxid)

关于选举结束

过半服务器选了同一个，则投票结束，根据投票结果更新自身状态为leader或者follower

还有两个问题

上面说过zookeeper是一个原子广播协议，在这个崩溃恢复的过程就体现了它的原子性，zookeeper在选主过程保证了两个问题：

     commit过的数据不丢失