zookeeper基础（最简单的ZAB协议入门）【1】

ZAB协议简介

ZAB，Zookeeper Atomic Broadcast，zk原子消息广播协议，是专门为Zookeeper设计的一种支持崩溃恢复的原子广播协议，在zk中，主要依赖ZAB 协议来实现分布式数据一致性。

zk使用一个单一主进程来接收闭关处理客户端的所有事务请求，即写请求。当服务器数据状态发生变更后，集群采用ZAB原子广播协议，以事务提案Proposal 的形式广播所有副本进程上。ZAB协议能够保证一个全局的变更序列，即可以为每一个事务分配一个全局的递增编号xid。

当zk客户端连接到zk集群的一个节点后，若客户端提交的是读请求，那么当前节点直接根据自己保存的数据对其进行响应；如果是写请求且当前节点不是Leader，那么该节点就会将该请求转发给Leader，Leader会以提案的方式广播该写操作，只要超过半数节点同意该写操作，则该写操作请求就会被提交。然后Leader会再次广播给所有订阅者，即Learner，通知它们同步数据。（Learner：学习者、同步者）。

ZAB与Paxos的关系

ZAB协议是Paxos 算法的一种工业实现算法。但是两者的设计目标不一样。ZAB协议主要用于构建一个高可用的分布式数据主从系统，即Follower 是Leader的从机，Leader宕机，马上选举出新的Leader，但平时它们都对外提供服务。而Fast Paxos算法则是用于构建一个分布式一致性状态机系统，确保系统中各个节点的状态都是一致的。
另外，ZAB还使用Google 的Chubby 算法作为分布式锁的实现，而Google的Chubby也是Paxos算法的应用。
zk集群对于事务请求的处理是Fast Paxos算法的体现，即只允许Leader 提出提案。其属于3PC提交。（不知道3PC的可以看我zookeeper系列此篇文章上一篇《2pc和3pc算法的入门》）
但Leader 选举是Paxos算法的体现，因为Leader宕机后，所有Follower均可提交提案，它们在最初都是“我选我”。其属于2PC提交。

重要术语

三类角色

为了避免zk的单点问题，zk也是以集群的形式出现的。zk集群中的主要角色主要有以下三类：

• Leader： zk集群中事务请求的唯一处理者；其也可以处理读请求。
• Follower：处理读请求；将事务请求转发给Leader；对Leader发起的提案进行表决；同步Leader的事务处理结果；在Leader的选举过程中具有选举权与被选举权。
• Observer：不具有表决权，且在Leader选举过程中没有选举权与被选举权的Follower（地位挺低的=.=）。
  Learner = Follower + Observer

三个数据

在ZAB中有三个很重要的数据：

• zxid：64位长度的Long类型，其高32位为epoch，低32位为xid。
• epoch：每一个新的Leader都会有一个新的epoch
• xid：其为一个流水号

三种模式

ZAB 协议中对zkServer 的状态描述有三种模式。这三种模式并没有十分明显的界限，它们是相互交融的。

• 恢复模式：其包含两个重要阶段：Leader选举、与初始化同步；
• 广播模式：其可分为两类：初始化广播，与更新广播；
• 同步模式：其可以分为两类：初始化同步，与更新同步。

四种状态

zk集群中的每一台主机，在不同的阶段会处于不同的状态。每一台主机具有四种状态。

• LOOKING：选举状态
• FOLLOWING： Follower 的正常工作状态
• OBSERVING： Observer的正常工作状态
• LEADING： Leader的正常工作状态