1、zookeeper原理
zookeeper基于ZAB协议实现分布式数据一致性，ZAB协议包含两种模式：
1、崩溃恢复，即leader挂掉之后选举新的leader
2、原子广播，即leader和其他节点间的数据同步
zookeeper中有三类节点：
leader：可以处理事务和非事务请求，负责向follower节点广播消息
follower：只能处理非事务请求，要同步leader节点数据，能参与选举和投票
observer：与follower一样，但是不能参与选举和投票
2、消息广播的原理
ZAB协议的数据同步是一个简化版的2pc（二阶段提交）：
（1）leader接收到消息请求后，将消息赋予一个全局唯一的64位自增id，叫zxid
（2）leader将带有zxid的消息作为一个提案（proposal）放入一个FIFO队列（保证全局有序），然后分发给所有的follower
（3）当follower收到proposal，先把proposal写到磁盘，写入成功后向leader回复一个ACK
（4）leader接收到超过半数节点的ACK后，会向这些follower发送commit命令，同时在本地执行该消息
（5）follower收到commit命令后，会提交该消息
所以ZAB协议和2pc的不同则在于过半提交，虽然在某一时刻follower和leader节点的状态会不一致，但却提升了集群的整体性能。
3、leader选举的原理
三个重要参数决定leader选举结果：
（1）myid，服务器编号，编号越大在选择算法中的权重越大
（2）zxid，事务id，高32位是epoch编号，每经过一次leader选举产生一个新的leader，新的leader会将epoch编号加1；低32位是消息计数器，每收到一条事务消息就会加1，新leader被选出后会将这个值重置为0。所以zxid越大，表示数据越新，在选举算法中权重越大。
（3）逻辑时钟（epoch-logicalclock），也叫投票次数，同一轮投票过程中的逻辑时钟是相同的，每投完一次票这个数就加1。
选举过程如下：
（1）每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID、epoch，使用(myid, ZXID,epoch)来表示， 此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
（2）接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自 LOOKING状态的服务器。
（3）处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下
i. 优先比较epoch
ii. 其次检查ZXID。ZXID比较大的服务器优先作为Leader
iii. 如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为 Leader服务器。 对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)， 首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为(2, 0)，然后重新投票，对于 Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
（4）统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
（5） 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader， 就变更为LEADING