直观理解：Zookeeper分布式一致性协议ZAB
ZAB是Zookeeper使用的分布式一致性协议，英文全称是：Zookeeper Atomic Broadcast，因此ZAB也称之为Zookeeper原子广播协议。在解决分布式一致性方面，Zookeeper并没有使用Paxos，而是采用了ZAB协议。基于ZAB协议，Zookeeper实现一种主备模式的系统架构来保持集群中主备副本之间数据的一致性。ZAB协议包括两种基本模式：消息广播（Message Broadcasting）和崩溃恢复（Leader Activation）。下面来详细介绍这两种基本模式的实现过程。
消息广播是Zookeeper用来保证写入事务一致性的方法，在Zookeeper集群中，存在以下三种角色的节点：
Leader： Zookeeper集群的核心角色，在集群启动或崩溃恢复中通过Follower参与选举产生，为客户端提供读写服务，并对事务请求进行处理。
Follower： Zookeeper集群的核心角色，在集群启动或崩溃恢复中参加选举，没有被选上就是这个角色，为客户端提供读取服务，也就是处理非事务请求，Follower不能处理事务请求，对于收到的事务请求会转发给Leader。
Observer： 观察者角色，不参加选举，为客户端提供读取服务，处理非事务请求，对于收到的事务请求会转发给Leader。使用Observer的目的是为了扩展系统，提高读取性能。
下面通过几张图对ZAB的消息广播过程进行简单的介绍。
Zookeeper的消息广播过程类似 2PC（Two Phase Commit），ZAB仅需要超过一半以上的Follower返回 Ack 信息就可以执行提交，大大减小了同步阻塞，提高了可用性。
在Zookeeper集群启动、运行过程中，如果Leader出现崩溃、网络断开、服务停止或重启等异常情况，或集群中有新服务器加入时，ZAB会让当前集群快速进入崩溃恢复模式并选举出新的Leader节点，在此期间整个集群不对外提供任何读取服务。当产生了新的Leader后并集群中过半Follower完成了与Leader的状态同步，那么ZAB协议就会让Zookeeper集群从崩溃恢复模式转换成消息广播模式。崩溃恢复的目的就是保证当前Zookeeper集群快速选举出一个新的Leader并完成与其他Follower的状态同步，以便尽快进入消息广播模式对外提供服务。
Zookeeper崩溃恢复的主要任务就是选举Leader（Leader Election），Leader选举分两个场景：一个是Zookeeper服务器启动时Leader选举，另一个是Zookeeper集群运行过程中Leader崩溃后的Leader选举。在详细介绍Leader选举过程之前，需要先介绍几个参数：
另外在选举的过程中，每个节点的当前状态会在以下几种状态之中进行转变。
假设现在存在一个由5个Zookeeper服务器组成的集群Sever1，Sever2，Sever3，Sever4和Sever5，集群的myid分别为：1， 2，3，4，5。依次按照myid递增的顺序进行启动。由于刚启动时zxid和epoch都为0，因此Leader选举的关键因素成了myid。
在Zookeeper集群刚启动的时候，zxid和epoch并不参与群首选举。但是如果Zookeeper集群在运行了一段时间之后崩溃了，那么epoch和zxid在Leader选举中的重要性将大于myid。重要性的排序为：epoch zxid myid。当某一个Follower与Leader失去通信的时候，就会进入Leader选举，此时Follower会跟集群中的其他节点进行通信，但此时会存在两种情况：
这种崩溃后的Leader选举机制也很好理解，如果Leader挂了，优先选择集群中最后做过（epoch）Leader的节点为新的Leader节点，其次选取有最新事务提交的节点（zxid）为Leader，最后才按默认的最大机器编号（myid）进行投票。
Jtti
2024-02-02 广告
