ZAB协议详解

ZAB协议详解

一. ZAB协议概述

1. ZAB：Zookeeper Atomic Broadcast，Zookeeper原子消息广播协议，是为Zookeeper所专门设计的一种支持崩溃恢复的原子广播协议。ZAB协议并不像Paxos算法那样是一种通用的分布式一致性算法，而是专为Zookeeper所设计的。
2. Zookeeper主要依赖ZAB协议来实现分布式数据的一致性。基于该协议，Zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间的数据一致性。
3. Zookeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并通过ZAB协议，将服务器数据的状态变更以事务Proposal的形式广播到所有副本进程上去。ZAB协议的这个主备架构模型保证了同一时刻集群中只能有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端的并发请求。
4. ZAB协议通过一个全局递增的事务id，来保证状态变更的顺序性。也就是说，ZAB保证了一个状态变更的请求如果已经被处理，那么所有该变更所依赖的状态变更都已经被处理过了。
5. 考虑到主进程在任何时刻都可能出现宕机的情况，ZAB协议还保证了即使主进程出现异常，只要集群中有半数以上节点存活，就仍然可以正常提供服务。

二. ZAB协议的核心

ZAB协议的核心是，定义了如何处理那些会改变Zookeeper服务器数据状态的事务请求。即：

所有的事务请求(会改变服务器数据状态的请求，如修改节点数据、删除节点等)必须由一个全局唯一的服务器来协调处理，该服务器被称为Leader，而剩余的其他服务器被称为Follower。Leader负责将一个客户端的事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中的所有Follower。然后Leader等待所有Follower的反馈结果，一旦有超过半数的Follower做出了正确的反馈后，Leader就会向所有的Follower再次发送Commit消息，要求将前一个Proposal提交。

三. ZAB协议详解

1. ZAB协议的两种模式：
   1. 崩溃恢复 当Zookeeper集群初始化时，或Leader故障宕机时，ZAB协议就会进入崩溃恢复模式，并选举出新的Leader。当新的Leader选举出来后，并且集群中已经有过半的节点与Leader完成了数据同步，ZAB协议就会退出崩溃恢复模式，转而进入消息广播模式。一个节点要想成为Leader，必须获得集群中过半节点的支持。
   2. 消息广播 ZAB的正常工作模式，如前文所说，Zookeeper设计成只允许唯一的一个Leader节点负责处理客户端的事务请求，当Leader接收到事务请求后，会生成相应的事务Proposal并发起一轮消息广播。如果集群中的非Leader节点(Follower或Observer)接收到了事务请求，会将请求转发给Leader处理。 当Leader宕机，或者是集群中已经不存在超过半数的节点与Leader保持正常通信，那么集群就会进入崩溃恢复模式。
2. 消息广播模式 ZAB协议的消息广播模式采用的是原子消息广播，类似于一个两阶段提交，Leader接收客户端的事务请求，为其生成对应的Proposal，并广播给集群中所有其他的服务器，然后分别收集每个服务器的选票，最后进行事务提交。ZAB消息广播模式的示意图如下：

在这里插入图片描述

在整个消息广播的过程中，Leader会为每个事务请求生成Proposal并进行广播。此外，在广播Proposal之前，Leader会首先为这个Proposal生成全局单调递增的唯一ID，称为事务ID，也即ZXID。ZAB协议会严格按照ZXID的顺序处理每个Proposal，保证了消息的顺序性。 在消息广播过程中，Leader会在Leader侧为每个Follower都各自分配一个单独的队列，然后将需要广播的Proposal依次放入这些队列中，按照FIFO的原则进行发送。Follower在接收到Proposal后，会首先将其以事务日志的形式写入磁盘中，写入成功后给Leader响应ACK。当Leader收到超过半数的Follower的ACK后，会广播一个Commit消息通知所有Follower进行事务提交，同时Leader自身也会提交事务。Follower在收到Commit消息后，就会完成对事务的提交。

1. 崩溃恢复模式 如前文所述，在正常情况下ZAB处于消息广播模式运行良好。但是在Leader发生故障宕机，或者由于网络原因导致Leader与过半的Follower通信失败，则会进入崩溃恢复模式。只要集群中有超过半数的节点正常运行，ZAB协议就能重新选举中一个新的Leader，并且通知集群中的所有机器新Leader的产生。
2. ZAB协议的基本特性 ZAB算法设计为新被选举出来的Leader拥有集群中ZXID最大的事务Proposal，这样就可以保证新的Leader一定具有所有已经提交的Proposal。更为重要的是，如果让ZXID最大的节点成为Leader，就可以省去Leader节点检查Proposal的提交和丢弃的工作了。

四. 深入ZAB算法

1. ZAB协议的三个阶段 如前文所述，ZAB协议有崩溃恢复和消息广播两种模式，而具体可细分为三个阶段：
   1. 阶段一 发现：主要就是Leader选举过程，用于在多个分布式进程中选举出主进程。
   2. 阶段二 同步：当发现阶段完成后，表明已经选举出了Leader，下面就会进入同步阶段，Follower开始与Leader进行数据的同步。
   3. 阶段三 广播：当同步阶段完成后，ZAB协议就进入广播阶段，开始正式接收客户端发送的事务请求，并进行消息广播。

   在正常运行的情况下，ZAB协议会一直处于阶段三来反复地进行消息广播流程。如果出现Leader崩溃或者其他原因导致Leader缺失，ZAB协议就会再次进入阶段一，重新选举新的Leader。

2. 进程的三种状态 在ZAB协议运行过程中，每个进程都会处于下面三种状态之一：
   1. Looking：Leader选举状态
   2. Following：Follower进程与Leader进程保持同步状态
   3. Leading：Leader主进程处于领导状态

   当ZAB协议的进程刚开始启动时，所有进程都处于Looking的初始化状态，此时集群中并不存在Leader。接下来，所有处于Looking状态的进程都会试图去选举出一个Leader。如果某个进程发现已经选举出了Leader，那么它会马上切换到Following，开始和Leader保存同步。此时，我们将处于Following状态的进程称为Follower，处于Leading状态的进程称为Leader。考虑到Leader进程随时可能挂掉，当检测出Leader已经崩溃或放弃领导地位时，其余的Following状态的进程就会重新进入Looking状态，并开始进行新一轮的Leader选举。因此在ZAB协议中，每个进程的状态都在Looking、Following和Leading之间不断转换。 在进程完成Leader选举和数据同步之后，ZAB协议就进入了广播阶段。在这个阶段中，Leader会为每一个与自己保持同步的Follower创建一个操作队列。同一时刻，一个Follower只能与一个Leader保持同步。Leader进程与所有的Follower进程之间通过心跳检测机制来感知彼此的状态。如果Leader能在超时时间内收到Follower的心跳，则Follower就会一直与Leader保持同步。而一旦在超时时间内Leader无法收到过半的Follower的心跳信息，或者TCP连接本身断开了，那么Leader就会停止对当前周期的领导，并转换到Looking状态。同时，所有Follower也会放弃这个Leader，进入Looking状态。之后，所有进程就会开启新一轮的Leader选举。