在Zookeeper的工作流程当中，各个节点当中，主要涉及到三个角色和四种状态，这也是构成Zookeeper体系架构的重要组成部分。
ZooKeeper角色和状态
角色：Leader，Follower，Observer。
状态：Leading，Following，Observing，Looking。
Looking：当前Server不知道Leader是谁，正在搜寻。
Leading：当前Server即为选举出来的Leader。
Following：Leader已经选举出来，当前Server与之同步。
Observing：Observer的行为在大多数情况下与Follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。
Zookeeper工作流程
Leader Election
当Leader崩溃或者Leader失去大多数的Follower，这时候ZK进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个正确的状态。
Zk的选举算法有两种：一种是基于Basic paxos实现的，另外一种是基于Fast paxos算法实现的。
系统默认的选举算法为Fast paxos。
Fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为Leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。
Leader工作流程
Leader主要有三个功能：
恢复数据；
维持与Follower的心跳，接收Follower请求并判断Follower的请求消息类型；
Follower的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
Follower主要有四个功能：
向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
接收Leader消息并进行处理；
接收Client的请求，如果为写请求，发送给Leader进行投票；
返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
PING消息：心跳消息
PROPOSAL消息：Leader发起的提案，要求Follower投票
COMMIT消息：服务器端最新一次提案的信息
UPTODATE消息：表明同步完成
REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息
SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
Zab协议（ZooKeeper Atomic Broadcast protocol）
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。
实现中zxid是一个64位的数字，它高32位是epoch用来标识Leader关系是否改变，每次一个Leader被选出来，它都会有一个新的epoch，标识当前属于那个Leader的统治时期。低32位用于递增计数。
