zookeeper原理

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

 参考文章：https://baijiahao.baidu.com/s?id=1770867597838699663&wfr=spider&for=pc