【ZooKeeper】各服务器角色处理链

阳光穿透心脏的1/2处 2022-10-21 03:42 115阅读 0赞

# 1 Leader #

Leader 服务器是整个 ZooKeeper 集群工作机制中的核心，其主要工作有以下两个。

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

## 请求处理链 ##

使用责任链模式来处理每一个客户端请求是 ZooKeeper 的一大特色。在服务 器启动过程讲解中，我们已经提到，在每一个服务器启动的时候，都会进行请求处理链 的初始化， Leader服务器的请求处理链如图所示。  
![在这里插入图片描述][20210503134815295.png]

从图中可以看到，从 PrepRequestProcessor 到 FinalRequestProcessor, 前后一共 7 个请求处理器组成了 Leader 服务器的请求处理链。

**PrepRequestProcessor**

PrepRequestProcessor 是 Leader 服务器的请求预处理器，也是 Leader 服务器 的第一个请求处理器。在 ZooKeeper 中，我们将那些会改变服务器状态的请求称为 “事务请求”一通常指的就是那些创建节点、更新数据、删除节点以及创建会话 等请求, PrepRequestProcessor 能够识别出当前客户端请求是否是事务请求。 对于事务请求， PrepRequestProcessor 处理器会对其进行一系列预处理，诸 如创建请求事务头、事务体，会话检查、 ACL 检查和版本检查等。

**ProposalRequestProcessor**

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

**SyncRequestProcessor**

SyncRequestProcessor 是事务日志记录处理器，该处理器主要用来将事务请 求记录到事务日志文件中去，同时还会触发 ZooKeeper 进行数据快照。

**AckRequestProcessor**

AckRequestProcessor 处理器是 Leader 特有的处理器，其主要负责在 SyncRequest Processor处理器完成事务日志记录后，向 Proposal 的投票收集器发送 ACK 反馈，以通知投票收集器当前服务器已经完成了对该 Proposal 的事务日志记录。

**CommitProcessor**

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

**ToBeCommitProcessor**

ToBeCommitProcessor 是一个比较特别的处理器，根据其命名，相信读者也已经理 解了该处理器的作用 ToBeCommitProcessor 处理器中有一个 toBeApplied 队列， 专门用来存储那些已经被 CommitProcessor 处理过的可被提交的 Proposal 。ToBeCommitProcessor 处理器将这些请求逐个交付给 FinalRequestProcessor 处理 器进行处理 ------------- 等到FinalRequestProcessor 处理器处理完之后，再将其从ToBeApplied 队列中移除。

**FinalRequestProcessor**

FinalRequestProcessor 是最后一个请求处理器。该处理器主要用来进行客户 端请求返回之前的收尾工作，包括创建客户端请求的响应，针对事务请求，该处理 器还会负责将事务应用到内存数据库中去。

## LearnerHandler ##

为了保持整个集群内部的实时通信，同时也是为了确保可以控制所有的 Follower/Observer 服务器， Leader 服务器会与每一个 Follower/Observer 服务器都建立一个 TCP 长连接，同时也会为每个 Follower/Observer 服务器都创建一个名为 LearnerHandler 的实体。

LearnerHandler, 顾名思义，是 ZooKeeper 集群中 Learner 服务器的管理器，主要负 责Follower/Observer 服务器和 Leader 服务器之间的一系列网络通信，包括数据同步、 请求转发和 Proposal 提议的投票等。 Leader 服务器中保存了所有 Follower/Observer 对应 的LearnerHandler 。

# 2 Follower #

从角色名字上可以看出， Follower 服务器是 ZooKeeper 集群状态的跟随者，其主要工作 有以下三个。

*  处理客户端非事务请求，转发事务请求给 Leader 服务器。
 *  参与事务请求 Proposal 的投票。
 *  参与 Leader 选举投票。

和 Leader 服务器一样， Follower 也同样使用了采用责任链模式组装的请求处理链来处理 每一个客户端请求，由于不需要负责对事务请求的投票处理，因此相对来说 Follower 服务器的请求处理链会简单一些，其请求处理链如图所示。  
![在这里插入图片描述][20210503133138951.png]  
从图中可以看到，和 Leader 服务器的请求处理链最大的不同点在于， Follower 服 务器的第一个处理器换成了 FollowerRequestProcessor 处理器，同时由于不需要 处理事务请求的投票，因此也没有了 ProposalRequestProcessor 处理器。

**FollowerRequestProcessor**

FollowerRequestProcessor 是 Follower 服务器的第一个请求处理器，其主要 工作就是识别出当前请求是否是事务请求。如果是事务请求，那么 Follower 就会将 该事务请求转发给 Leader服务器， Leader 服务器在接收到这个事务请求后，就会 将其提交到请求处理链，按照正常事务请求进行处理。

**SendAckRequestProcessor**

SendAckRequestProcessor 是 Follower 服务器上另外一个和 Leader 服务器有差异 的请求处理器。我们讲到过 Leader 服务器上有一个叫 AckRequestProcessor 的请求处理器，其主要负责在 SyncRequestProcessor 处 理器完成事务日志记录后，向 Proposal 的投票收集器进行反馈。而在 Follower 服务器上，SendAckRequestProcessor 处理器同样承担了事务日志记录反馈的角色，在完成事 务日志记录后，会向 Leader 服务器发送 ACK 消息以表明自身完成了事务日志的记录工 作。

两者的唯一区别在于， AckRequestProcessor 处理器和 Leader 服务器在同一个 服务器上，因此它的ACK 反馈仅仅是一个本地操作；而 SendAckRequestProcessor 处理器由于在 Follower 服务器上，因此需要通过以 ACK 消息的形式来向 Leader 服务器 进行反馈。

# 3 Observer #

Observer 是 ZooKeeper 自 3.3.0 版本开始引入的一个全新的服务器角色。从字面意思看， 该服务器充当了一个观察者的角色一一其观察 ZooKeeper 集群的最新状态变化并将这些 状态变更同步过来。 Observer 服务器在工作原理上和 Follower 基本是一致的，对于非事 务请求，都可以进行独立的处理，而对于事务请求，则会转发给 Leader 服务器进行处理。 和 Follower 唯一的区别在于，Observer 不参与任何形式的投票，包括事务请求 Proposal 的投票和 Leader 选举投票。简单地讲，Observer 服务器只提供非事务服务，通常用于在 不影响集群事务处理能力的前提下提升集群的非事务处理能力。

另外， Observer 的请求处理链路和 Follower 服务器也非常相近，如图所示。  
![在这里插入图片描述][20210503133201407.png]  
另 外 需 要 注 意 的 一 点 是 ， 虽 然 在 图 7-38 中 ， Observer 服 务 器 在 初 始 化 阶 段 会 将 SyncRequestProcessor 处理器也组装上去，但是在实际运行过程中 ,Leader 服务器 不会将事务请求的投票发送给 Observer 服务器。

# 4 集群间消息通信 #

我们讲到过，在整个 ZooKeeper 集群工作过程中，都是由 Leader 服务器来 负责进行各服务器之间的协调，同时，各服务器之间的网络通信，都是通过不同类型的 消息传递来实现的。在本节中，我们将围绕 ZooKeeper 集群间的消息通信来讲解 ZooKeeper 集群各服务器之间是如何进行协调的。

ZooKeeper 的消息类型大体上可以分为四类，分别是：数据同步型、服务器初始化型、 请求处理型和会话管理型

**数据同步型**

数据同步型消息是指在 Learner 和 Leader 服务器进行数据同步的时候，网络通信所用到 的消息，通常有 .DIFF, TRLTNC. SNAP 和 UPTODATE 四种。  
![在这里插入图片描述][20210503150836187.png]

**服务器初始化型**

服务器初始化型消息是指在整个集群或是某些新机器初始化的时候， Leader 和 Learner 之间相互通信所使用的消息类型，常见的有 OBSERVERINFO 、 FOLLOWERINFO, LEADERINFO,ACKEPOCH 和 NEWLEADER 五种。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]

**请求处理型**

请求处理型消息是指在进行请求处理的过程中， Leader 和 Learner 服务器之间互相通信 所使用的消息，常见的有 REQUEST, PROPOSAL, ACK, COMMIT, INFORM 和 SYNC 六种。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]

**会话管理型**  
会话管理型消息是指 ZooKeeper 在进行会话管理的过程中，和 Learner 服务器之间互相 通信所使用的消息，常见的有 PING 和 REVALIDATE 两种。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]

[20210503134815295.png]: /images/20221021/c5ca5663ff5c42c29944509b2b072fa4.png
[20210503133138951.png]: /images/20221021/d86f8cf721494d4ba6c33c63a0830c4d.png
[20210503133201407.png]: /images/20221021/c59f503e61c74251b62c1e4097de188a.png
[20210503150836187.png]: /images/20221021/4202e31f54d24df9bf2447e1212f2498.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/d9d3bd4284854f5fa63a0c96769b2ecd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/d7ac68699be245299f0ef738af969c19.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]: /images/20221021/607d00e2b51c4f5cbcaff9a0a7887fad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]: /images/20221021/952340fc56f44392982569eadc40dce1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]: /images/20221021/8bb02c100c6a49d28b3d38b5168f71e9.png