ZAB协议

　　介绍

　　1、zab协议是为分布式协调服务zookpeer专门设计的一种支持崩溃恢复的原子广播协议

　　2、在zookeeper中主要依赖ZAB协议来实现数据一致性，基于该协议zk实现了一种主备模式的系统架构来保证集群中各个副本之间数据的一致性。具体就是zk使用一个单一的主进程来接收并处理客户端的事务请求（就是写请求），并采用ZAB的原子广播协议，将服务器数据的状态变更以事务proposal的形式广播到所有的副本进程上去。

　　事务请求的处理方式

　　所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则是Follow服务器。Leader负责将一个事务请求转换成一个事务proposal，并将该proposal分发给集群中所有的Follow，之后Leader需要等待所有的Follow的反馈，一单超过半数Follow进行了正确的反馈后，那么Leader就会再次向所有的Follow发送commit消息，要求其将前一个proposal进行提交

　　注意：如果集群中非Leader服务器接收到事务请求，这些非Leader服务器会将事务请求转发给Leader服务器，只有Leader才能处理事务请求。

　　协议具体内容

　　ZAB协议包括两种基本模式：分别是崩溃恢复和消息广播

　　当整个集群启动过程中或者当Leader服务器出现网络中断，崩溃退出或重启等异常时，ZAB协议j就会进入恢复模式并选举产生新的Leader，当选举产生了新的Leader，同时集群中有过半的机器与该Leader服务器完成了状态同步（即数据同步）之后，ZAB协议就会退出崩溃恢复模式，进入消息广播模式。这时如果有一台遵守ZAB协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么新加入的服务器自觉的进入恢复模式：找到Leader服务器并与之完成数据同步然后一起参与到消息广播流程中去。

　　当Leader出现崩溃退出或者机器重启，亦或是集群中已经不存在过半的服务器与Leader保持正常的通信，ZAB就会重新发一轮Leader选举并实现数据同步，最后又进入消息广播模式，接收事务请求

　　消息必须是有顺序的

　　在整个消息广播过程中，Leader会将每个事务请求转换成对应的proposal来进行广播，并且在广播事务proposal之前，Leader服务器会首先为这个事务proposal分配一个全局的单调递增的唯一ID，称之为事务ID（即ZXID），由于ZAB需要保证每一个消息严格的因果关系，因此必须将每一个proposal按照其ZXID的先后顺序来进行排序与处理。

　　消息广播

　　ZAB协议的消息广播使用的是一个原子广播协议，类似于二阶段提交，Leader接收事务请求，并转换成proposal广播给其他的Follow，然后过半的Follow ack消息，最后再给广播commit消息完成事务提交。

　　具体的，在消息广播过程中，Leader为每个Follow服务器分配一个单独的队列，然后将需要广播的proposal依次放到队列中去，并且根据FIFO策略进行消息发送。每一个Follow接收到proposal后，都会首先将其以事务日志的形式写入本地磁盘中，并且写入成功后反馈Leader一个ACK响应。当Leader接收到超过半数的ACK响应后，就会广播一个commit消息给Follow已通知他们完成事务提交，同时Leader自身也会完成事务的提交。

　　崩溃恢复

　　Leader挂了之后，ZAB协议就自动进入崩溃恢复模式，选举出新的Leader，并完成数据同步，然后退出崩溃恢复模式进入消息广播模式

　　ZAB协议如何保证数据一致性

　　异常情况：

　　1、假设一个事务在Leader上提交了，并且过半Follow都响应ACK了，但是Leader将commit消息发出后就挂了

　　2、假设一个事务在Leader提交了之后，Leader就挂掉了。

　　要保证如果发生上述2种情况，数据还能保持一致性，那么ZAB协议选举算法必须确保已经提交的proposal（发送过commit消息），在Follow上也必须完成提交；并且丢弃已经被跳过的事务proposal。

通过ZAB协议选举算法选举出来的Leader必须是拥有集群中最高编号（ZXID）proposal的机器，拥有最高编号说明新Leader一定具有所有已提交的提案。更为重要的是，如果让具有最高编号的事务proposal的机器成为Leader，就可以省去Leader服务器检查proposal的提交和丢弃工作的这一步操作了。

　　ZAB是如何数据同步？

　　完成Leader选举后（新Leader具有最高编号），在正式开始工作之前（接收事务请求，然后提出新的proposal）,Leader服务器会首先确认事务日志中的所有的Proposal是否都已经被集群中过半的提交了。

　　Leader服务器需要确保所有的Follow服务器能够接收到每一条事务proposal, 并且能将所有已经提交的事务proposal应用到内存数据库中去。等到Follow将所有尚未同步的事务proposal都从Leader服务器上同步过来并应用到内存数据库中去，Leader才会把该Follow加入到真正可用的Follow列表中。

　　ZAB是如何处理需要丢弃的Proposal？

　　在ZAB协议的事务编号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的服务器启动时，当这台机器加入集群中，以Follow角色连接上Leader服务器后，Leader服务器会根据自己服务器上最后提交的proposal来和Follow服务器的proposal进行比对，比对的结果肯定是Leader要求Follow进行一个回退操作，回退到一个确实已经被集群中过半机器提交的最新proposal。

　　ZAB协议特性：

　　1、ZAB协议需要确保那些已经在Leader服务器上提交（commit）的事务最终被所有的服务器提交

　　2、ZAB协议需要确保丢弃那些只在Leader上被提出的事务(只是被提出还没有被提交)