Zookeeper入门教程二（集群角色、工作原理、工作流程）

在上篇文章 Zookeeper入门教程（概述、安装和命令）中 ，初步认识了Zookeeper，本文带你循序渐进的重点了解一下Zookeeper的角色、工作原理、数据操作流程等。

1、认识 Zookeeper 角色

在Zookeeper入门教程一（概述、安装、命令）中 ，我们搭建了Zookeeper集群，如图：

这是一个由多个server组成的集群，每个server保存一份数据副本，在zookeeper集群中有3种角色：

角色	描述
Leader （领导者）	负责进行投票的发起和决议，更新系统状态
Follower (跟随者）	用于接受客户端请求并向客户端返回结果，跟随Leader指令，在选主过程中参与投票
Observer (观察者）	接受客户端的连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态

在集群中，只能有一个leader（老大嘛，肯定只能有一个），多个follower或者Observer（都是小弟），其中跟随者(Follower)和观察者(Observer)一起称为学习者（Learner）。

这里说一下Observer：

ZooKeeper默认只有 Leader 和 Follower 两种角色，没有 Observer 角色。    

Observer是权衡伸缩性和高吞吐率，保证 Zookeeper高可用和强一致性而引入的角色，但observer不参与投票，只接受客户端的连接，和follower一样，将写请求转发给leader

为了使用 Observer ，在配置文件zoo.cfg中配置：peerType=observer ，并在集群中所有的zoo.cfg中，配置成 observer 模式的 server 的那行配置追加 :observer 

2、Zookeeper 设计目的

• 顺序性：更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行

• 原子性：一次数据更新要么成功，要么失败，没有中间状态

• 最终一致性：client无论连接到哪个server，数据视图都是一致的，这是zookeeper最重要的性能

• 实时性：客户端在一个时间间隔范围内获取服务器的更新消息

3、Zookeeper 工作原理

Zookeeper 的核心是原子广播机制，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，即恢复模式和广播模式

恢复模式（选主）:

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。

广播模式（同步）：

状态同步保证了leader和server具有相同的系统状态。

在ZooKeeper中，数据节点的创建与删除、数据内容更新、客户端会话创建与失效等这些操作称为事务操作，能改变ZooKeeper服务器状态。对应每一个事务请求，ZooKeeper 都会为其分配一个全局唯一的递增的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID 对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

状态	描述
LOOKING	当前Server不知道Leader是谁，正在寻找
LEADING	当前的server就是被选举出来的Leader
FOLLOWING	Leader已经选举出来，当前server与之同步

（集群中没有老大哪能行，赶紧选举吧! ）

3.1、Zookeeper 选主流程

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。

3.1.1、选举算法–basic paxos

1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；

2 .选举线程首先向所有Server发起一次询问(包括自己)；

3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；

4.  收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；

5.  线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。

每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：

3.1.2、选举算法–fast paxos

fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：

3.2、Zookeeper 同步流程

(老大已经选出来了，小弟们赶紧出来认大哥啊！)

选完leader以后，zk就进入状态同步过程

1. leader就会开始等待server连接
2. Follower连接leader，将最大的zxid发送给leader
3. Leader根据follower的zxid确定同步点
4. 完成同步后通知follower 已经成为uptodate状态
5. Follower收到uptodate消息后，又可以重新接受client的请求进行服务了

4、Zookeeper节点数据操作流程

在leader、follower确定好以后，就可以进行数据交互了！

4.1、Leader工作流程

Leader主要有三个功能：

1 .恢复数据；

2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

消息类型	描述
PING	Learner的心跳信息
REQUEST	Follower发送的提议信息，包括写请求及同步请求
ACK	Follower的对提议的回复，超过半数的Follower通过，则commit该提议；
REVALIDATE	延长SESSION有效时间

4.2、Follower工作流程

Follower主要有四个功能：

 1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

 2 .接收Leader消息并进行处理；

 3 .接收Client的请求，如果为写请求，发送给Leader进行投票；

 4 .返回Client结果。

Follower的消息循环处理如下几种来自Leader的消息：

消息类型	描述
PING	心跳消息；
PROPOSAL	Leader发起的提案，要求Follower投票；
COMMIT	服务器端最新一次提案的信息；
UPTODATE	表明同步完成；
REVALIDATE	根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
SYNC	返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新

5、为什么zookeeper集群的数目一般为奇数个？

•Leader选举算法采用了Paxos协议；
•Paxos核心思想：当多数Server写成功，则任务数据写成功如果有3个Server，则两个写成功即可；如果有4或5个Server，则三个写成功即可。
•Server数目一般为奇数（3、5、7）如果有3个Server，则最多允许1个Server挂掉；如果有4个Server，则同样最多允许1个Server挂掉由此，

我们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。