zookeeper工作原理、服务器角色、工作状态？

本是古典何须时尚 2022-09-04 05:45 275阅读 0赞

# ZK工作原理 #

Zookeeper 的核心是**原子广播**，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做**Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。**

**恢复模式**：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，当领导者被选举出来，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。

**广播模式：**一旦Leader已经和多数的Follower进行了状态同步之后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步，等待同步结束，它也参与消息广播。ZoKeeper的广播状态一直到Leader崩溃了或者Leader失去大部分Followers的支持。

**ZK如何保证事务的一致性？**

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（**zxid**）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。Zookeeper下每个Server在工作过程中有三种状态，LEADING：当前Server即为选举出来的leader。

# 服务器角色 #

<table style="width:684px;"> 
 <tbody> 
  <tr> 
   <td colspan="2" style="text-align:center;width:211px;">角色</td> 
   <td style="text-align:center;width:471px;">描述</td> 
  </tr> 
  <tr> 
   <td colspan="2" style="width:211px;">领导者(leader)</td> 
   <td style="text-align:center;width:471px;">负责进行投票的发起和决议，更新系统状态</td> 
  </tr> 
  <tr> 
   <td colspan="1" style="width:118px;"> <p style="text-align:center;">学习者</p> <p style="text-align:center;">(learner)</p> </td> 
   <td style="width:93px;"> <p style="text-align:center;">跟随者</p> <p style="text-align:center;">(follower)</p> </td> 
   <td style="text-align:center;width:471px;">接收客户端请求并向客户端返回处理结果，参与选主过程中的投票</td> 
  </tr> 
  <tr> 
   <td style="width:93px;"> <p style="text-align:center;">观察者</p> <p style="text-align:center;">(obServer)</p> </td> 
   <td style="text-align:center;width:471px;">obServer可独立处理非事务请求，事务请求要转发给leader处理，不参与任何投票，只同步leader状态</td> 
  </tr> 
  <tr> 
   <td colspan="2" style="text-align:center;width:211px;">客户端(client)</td> 
   <td style="text-align:center;width:471px;">请求的发起方</td> 
  </tr> 
 </tbody> 
</table>

**事务请求**：指能够改变Zookeeper服务器状态的操作，一般包括节点创建与删除，数据节点内容更新和客户端会话创建与失效。这些请求只能由leader来处理。

**系统模型：**

## ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70][]角色分析 ##

### leader ###

Leader服务器是Zookeeper集群工作的核心，其主要工作如下

> (1) 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
> 
> (2) 集群内部各服务器的调度者。

**请求处理链**

使用责任链来处理每个客户端的请求时Zookeeper的特色，Leader服务器的请求处理链如下

![img][]

(1) PrepRequestProcessor--请求预处理器。在Zookeeper中，那些会改变服务器状态的请求称为**事务请求**（创建节点、更新数据、删除节点、创建会话等），PrepRequestProcessor**能够识别出**当前客户端请求**是否是事务请求**。对于事务请求，PrepRequestProcessor处理器会对其进行一系列预处理，如创建请求事务头、事务体、会话检查、ACL检查和版本检查等。

(2) ProposalRequestProcessor--事务投票处理器。Leader服务器事务处理流程的发起者，对于非事务性请求，ProposalRequestProcessor会直接将请求转发到CommitProcessor处理器，不再做任何处理，而对于事务性请求，处理将请求转发到CommitProcessor外，还会根据请求类型创建对应的Proposal提议，并发送给所有的Follower服务器来发起一次集群内的事务投票。同时，ProposalRequestProcessor还会将事务请求交付给SyncRequestProcessor进行事务日志的记录。

(2) SyncRequestProcessor。事务日志记录处理器。用来将事务请求记录到事务日志文件中，同时会触发Zookeeper进行数据快照。

(3) AckRequestProcessor。负责在SyncRequestProcessor完成事务日志记录后，向Proposal的投票收集器发送ACK反馈，以通知投票收集器当前服务器已经完成了对该Proposal的事务日志记录。

(4) CommitProcessor。事务提交处理器。对于非事务请求，该处理器会直接将其交付给下一级处理器处理；对于事务请求，其会等待集群内针对Proposal的投票直到该Proposal可被提交，利用CommitProcessor，每个服务器都可以很好地控制对事务请求的顺序处理。

(5) ToBeCommitProcessor。该处理器有一个toBeApplied队列，用来存储那些已经被CommitProcessor处理过的可被提交的Proposal。其会将这些请求交付给FinalRequestProcessor处理器处理，待其处理完后，再将其从toBeApplied队列中移除。

(6) FinalRequestProcessor。用来进行客户端请求返回之前的操作，包括创建客户端请求的响应，针对事务请求，该处理还会负责将事务应用到内存数据库中去。

### LearnerHandler(Follower与**Observer**) ###

> 为了保证整个集群内部的实时通信，同时为了确保可以控制所有的Follower/Observer服务器，Leader服务器会与每个Follower/Observer服务器建立一个TCP长连接。同时也会为每个Follower/Observer服务器创建一个名为LearnerHandler的实体。LearnerHandler是Learner服务器的管理者，主要负责Follower/Observer服务器和Leader服务器之间的一系列网络通信，包括数据同步、请求转发和Proposal提议的投票等。Leader服务器中保存了所有Follower/Observer对应的LearnerHandler。

**Follower**

Follower是Zookeeper集群的跟随者，其主要工作如下

> (1) 处理客户端**非事务性请求**（读取数据），转发**事务请求**给Leader服务器。
> 
> (2) 参与事务请求Proposal的投票。
> 
> (3) 参与Leader选举投票。

Follower也采用了责任链模式组装的请求处理链来处理每一个客户端请求，由于不需要对事务请求的投票处理，因此Follower的请求处理链会相对简单，其处理链如下

![img][img 1]

(1) FollowerRequestProcessor。其用作识别当前请求是否是事务请求，若是，那么Follower就会将该请求转发给Leader服务器，Leader服务器是在接收到这个事务请求后，就会将其提交到请求处理链，按照正常事务请求进行处理。

(2) SendAckRequestProcessor。其承担了事务日志记录反馈的角色，在完成事务日志记录后，会向Leader服务器发送ACK消息以表明自身完成了事务日志的记录工作。

**Observer**

Observer充当观察者角色，观察Zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器进行处理。Observer不会参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。其处理链如下

![img][img 2]

## zookeeper服务器工作状态 ##

服务器具有四种状态，分别是 **LOOKING**、**FOLLOWING**、**LEADING**、**OBSERVING**。

> （1）LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
> 
> （2）FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
> 
> （3）LEADING：领导者状态。表明当前服务器角色是 Leader。
> 
> （4）OBSERVING：观察者状态。表明当前服务器角色是 Observer。  
>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDQ0NDE5_size_16_color_FFFFFF_t_70]: /images/20220829/c55514748f074db299c603ec31351dcf.png
[img]: /images/20220829/ea2784a0138548f88ecd9642f2c9e23a.png
[img 1]: /images/20220829/7b43e2196019497fbadfe1a4a4f25b79.png
[img 2]: /images/20220829/4032f90489084a20b2bcef974deb7142.png