zookeeper zab protocol

1. ZAB 协议概述:

   1.ZAB(ZooKeeper Atomic Broadcast,原子消息广播协议)协议是为分布式协调服务ZooKeeper专门设计的一种支持漰溃恢复的原子广播协议
   2.ZAB在Paxos算法基础上进行了扩展改进而来,支持崩溃恢复
   3.ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性
     具体，ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求,并采用ZAB的原子广播协议,将服务器的状态变更以事务Proposal的形式广播到所有的副本进程上去.ZAB协议的这个主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更,因此能够很好地处理客户端大量并发请求
     所有事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器称为Leader服务器,而余下的其他服务器则成为Follower服务器.Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议),并将该Proposal分发给集群中所有的Follower服务器.之后Leader服务器需要等待所有Follower服务器的反馈,一旦超过半数(>=N/2+1)的Follower服务器进行了正确反馈后,那么Leader就会再次向所有的Follower服务器分发Commit消息,要求其将前一个Proposal进行提交.

2. ZAB 协议

   ZAB协议的两种基本模式: 崩溃恢复模式和消息广播模式
   1.崩溃恢复模式
     ZAB协议会让ZK集群进入崩溃恢复模式的情况:
       1.当服务框架在启动过程中
       2.当Leader服务器出现网络中断,崩溃退出与重启等异常情况
       3.当集群中已经不存在过半的服务器与Leader服务器保持正常通信
   
     ZAB协议进入恢复崩溃模式会做什么事情?
       1.当Leader出现问题,则进入恢复模式并选举出新的Leader服务器.当选举出新的Leader服务器,同时集群中已经有过半的机器与该Leader服务器完成状态同步(数据同步),退出崩溃恢复模式.进入消息广播模式
       2.当新加入一台机器到集群中,如果此时集群已经存在一个Leader服务器在负责进行消息广播,那么新加入的服务器就会自觉地进入数据恢复模式.找到Leader服务器,并与其进行数据同步,然后进入消息广播模式,一起参与到消息广播流程中去
   
   2.消息广播模式
     针对客户端事务请求,Leader服务器会为其生成对应的事务proposal,并将其发送给集群中其余所有的机器,然后分别收集各自的选票,最后进行事务提交
   
     1.ZAB协议消息广播使用的是一个原子广播协议,类似于二阶段提交协议.与二阶段提交协议不同的是,ZAB在提交过程中移除了中断逻辑
     2.ZAB协议在有过半的Follower服务器已经反馈Ack之后就开始提交Proposal了,而不需要等待集群中所有Follower服务器都反馈响应
     3.关于ZAB在Leader出现单点宕机如何保证事务提交,保证数据一致性,则引入崩溃恢复模式来解决这个问题
     4.ZAB的消息广播协议是基于具有FIFO(先进先出)特性的TCP协议来进行网络通信,保证消息广播过程中消息的接收与发送的顺序性
   
     在整个消息广播过程中,Leader服务器会为每一个事务请求处理,步骤如下:
       1.Leader服务器会为事务请求生成一个全局的的递增事务ID(即ZXID),保证每个消息的因果关系的顺序
       2.Leader服务器会为该事务生成对应的Proposal,进行广播
       3.Leader服务器会为每一个Follower服务器都各自分配一个单独的队列,让将需要广播的事务Proposal依次放入这些队列中去,并根据FIFO策略进行消息发送
       4.每一个Follower服务器在接收到这个事务Proposal之后,首先以日志形式写入本地磁盘,并且成功写入后反馈给Leader服务器一个Ack响应
       5.当Leader服务器接收超过半数的Follower的Ack响应,Leader自身也会完成对事务的提交.同时就会广播一个Commit消息给所有的Follower服务器以通知进行事务提交.每一个Follower服务器在接收到Commit消息后,也会完成对事务的提交

3. ZAB的崩溃恢复

   基本特性,确保当Leader出现单点问题,在新选举出Leader后,保证数据一致性
     1.ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交
     2.ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务

4. ZAB的Leader选举算法

   1.旧Leader宕机后,选举新Leader中,旧的Leader重启后不可能再次成为这次选举的新Leader
   2.旧Leader宕机后,在剩下的Follower服务器选取新Leader的标准,一定是事务ID最大的那个Follower成为新Leader(即数据同步最新的那台Follower服务器)
   3.事务ID(ZXID)是64位的数字.其中低32位可以看作是一个简单的单调递增的计数器,高32位则代表一个Leader从生到死的epoch编号
   4.新Leader选举出来,从事务proposal中分析出旧Leader的epoch编号,并递增1,作为新的事务ID的高32位,然后新事务ID的低32位从0位重新开始计数
   5.新Leader通过事务ID和所有的Follower机器上的事务ID进行对比,确保数据同步.保证数据在所有的Follower上与之达成同步.旧Leader上新被提交的事务被抛弃.当数据达到同步,才将Follower服务器加入可用的Follower服务器列表.然后开始消息广播

5. ZAB协议和Paxos算法两者关系

   1.两者都存在一个类似于Leader进程都角色,由其负责协调多个Follower进程运行
   2.Leader进程都会等待超过半数都Follower做出正确都反馈后,才会将以更提案进行提交
   3.在ZAB协议中,每个Proposal中都包含一个epoch值,用来代表当前leader周期;在Paxos算法中,同样存在这样一个标识ballot
   
   在paxos算法中,一个新选举产生都主进程会进行两个阶段都工作:
   第一个阶段被称为读阶段,在这个阶段中,这个新的主进程会通过和所有其他进程进行通信都方式来收集上一个主进程提出的提案,并将他们提交.
   第二个阶段被称为写阶段,在这个阶段中,当前主进程开始提出它自己都提案.
   在paxos算法设计都基础上，ZAB协议额外添加了一个同步阶段,在同步阶段中,新都leader会确保存在过半都Follower已经提交了之前leader周期中都所有事务proposal.这一同步阶段都引入,能够有效地保证leader在新都周期中提出事务proposal之前,所有都进程都已经完成了对之前所有事务的提交.一旦完成同步阶段后,那么ZAB就会执行和paxos算法类似的写阶段
   
   总之,ZAB协议和Paxos算法本质区别在于,两者的设计目标不太一样:
   ZAB协议主要用于构建一个高可用的分布式数据主备系统
   Paxos算法主要用于构建一个分布式一致性状态机系统