系列文章目录
认识 Zookeeper -基本概念，组成和功能_小王师傅66的博客-CSDN博客
zookeeper-集群-选举机制_小王师傅66的博客-CSDN博客
前言
在前面两篇文章中，我们认识了什么是ZooKeeper，ZooKeeper有哪些功能，ZooKeeper集群，以及ZooKeeper集群中的选举机制。那么在ZooKeeper集群中，数据是如何在节点间同步的呢？数据同步过程中又会产生哪些问题又是如何解决的呢？ 在下面这篇文章中，将为大家讲解。
一、认识ZAB协议
在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性， 基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。所以，我们先来了解下ZAB协议，把ZAB协议搞明白了，上面的问题就清楚了。
ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。
1.1 ZAB协议主备模型架构需要实现的3个功能
1、支持大量的并发事务请求
在很多时候，ZK被用来解决客户端大量并发事务请求的一致性问题。ZAB协议要求集群中只能够有一个主进程来广播服务器的状态变更，来支持大量的并发事务请求。
2、保证事务请求顺序执行
在分布式环境中，顺序执行的一些状态变更其前后会存在一定的依赖关系，有些状态变更必须依赖于比它早生成的那些状态变更，例如变更C需要依赖变更A和变更B。因此，ZAB协议必须能够保证一个全局的变更序列被顺序应用，也就是说，ZAB协议需要保证如果一个状态变更已经被处理了，那么所有其依赖的状态变更都应该已经被提前处理了。
3、主进程出现崩溃退出或重启等异常情况后，集群依然能正常工作
为了支持大量的并发事务请求，ZAB协议使用一个单一的主进程来接收并处理客户端的所有事务请求，主进程在集群中起着至关重要的作用。为了保证集群的高可用，ZAB要求主进程出现异常情况后，集群仍能正常工作。
1.2 ZAB协议的核心
ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事务请求的处理方式，即：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower 服务器。
二阶段提交：1、锁定资源，创建事务Proposal，广播事务Proposal；2、收到过半ack，广播事务commit；
Leader 服务器负责将一个客户端事务请求转换成一个事务Proposal (提议)，并将该Proposal 分发给集群中所有的Follower服务器。之后Leader 服务器需要等待所有Follower 服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
ZooKeeper只允许唯一的一个Leader 服务器来进行事务请求的处理。Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给
Leader服务器。这里需要注意的一点是， 由于Observer 服务器并未参加之前的提议投票，因此Observer服务器尚未保存任何关于该提议的信息，所以在广播COMMIT消息的时候，需要区别对待，Leader会向其发送一种被称为“INFORM的消息，该消息体中包含了当前提议的内容。而对于Follower 服务器，由于已经保存了所有关于该提议的信息，因此Leader服务器只需要向其发送ZXID即可。
而对于非事务请求，集群中的每个节点都可以处理。
1.3 ZAB的两种模式
ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播。
1、当整个服务框架在启动过程中，或是当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader 服务器。
2、当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，整个服务框架进入消息广播模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
3、当一台同样遵守ZAB协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
4、当Leader服务器出现崩溃退出或机器重启，亦或是集群中已经不存在过半的服务器与该Leader 服务器保持正常通信时，那么在重新开始新一轮的原子广播事务操作之前，所有进程首先会使用崩溃恢复协议来使彼此达到一个一致的状态，于是整个ZAB流程就会从消息广播模式进人到崩溃恢复模式。
二、崩溃恢复过程中可能产生的问题
1.在Leader服务器上事务Proposal提交成功，将commit消息发送给所有Follower机器之前，Leader服务器挂了，导致集群中其他服务器没收到事务提交的通知；
2.Leader 服务器在提出了一个事务Proposal之后就崩溃退出了，导致集群中的其他服务器都没有收到这个事务Proposal；
结合上面提到的这两个崩溃恢复过程中需要处理的特殊情况，决定了ZAB协议必须设计这样一个Leader选举算法：
能够确保Follower提交已经被Leader提交的事务Proposal；丢弃已经被跳过的事务Proposal。
针对这个要求，Leader选举算法能保证新选举出来的Leader服务器拥有集群中所有机器最高编号（即ZXID最大）的事务Proposal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的Proposal。更为重要的是，如果让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步操作了。我们来完成的看下ZXID的设置。
ZXID是一个64位的数字，其中低32位可以看作是一个简单的单调递增的计数器，针对客户端的每一个事务请求，Leader 服务器在产生一个新的事务Proposal的时候，都会对该计数器进行加1操作；而高32位则代表了Leader 周期epoch的编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出对应的epoch值，然后再对其进行加1操作，之后就会以此编号作为新的epoch，并将低32位置0来开始生成新的ZXID。
ZAB协议中的这一通过epoch编号来区分Leader周期变化的策略，能够有效地避免不同的Leader服务器错误地使用相同的ZXID编号提出不一样的事务Proposal的异常情况，这对于识别在Leader崩溃恢复前后生成的Proposal非常有帮助，大大简化和提升了数据恢复流程。
基于这样的策略，当一个包含了上一个Leader周期中尚未提交过的事务Proposal 的服务器启动时，其肯定无法成为Leader，原因很简单，因为当前集群中一定包含一个Quorum集合，该集合中的机器一定包含 了更高epoch的事务Proposal, 因此这台机器的事务Proposal 肯定不是最高，也就无法成为Leader了。当这台机器加入到集群中，以Follower角色连接上Leader服务器之后，Leader服务器会根据自己服务器上最后被提交的Proposal来和Follower 服务器的Proposal 进行比对，比对的结果当然是Leader会要求Follower进行一个回退操作：回退到一个确实已经被集群中过半机器提交的最新的事务Proposal。
三、总结
通过前面的学习，总结下来3点：
1、ZAB协议是为分布式协调服务ZooKeeper专门设计的支持崩溃回复的原子广播协议，ZooKeeper是ZAB协议的实现；
2、ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事务请求的处理方式，即：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower 服务器。
3、ZooKeeper通过“二阶段”提交，将事务请求提交并同步到集群节点上；
4、ZAB协议设计ZXID记录Leader周期和生成事务Proposal的次数，帮助集群选主，识别Leader崩溃恢复前后生成的Proposal，提升数据恢复流程。
