zookeeper入门之角色

心已赠人 2022-05-25 11:50 165阅读 0赞

前段时间，一个同事面试被问到关于zookeeper的角色和选举问题，之前写过一篇关于LInxu环境zookeeper集群搭建的文章，今天就来看看关于zookeeper的角色。

我们知道在分布式系统中， 构成集群的每一台机器都有自己的角色，最经典的集群模式就是Master/Slave(主备模式)，我们把能够处理所有写操作的机器称之为Master,把所有通过异步复制的方式获取更新数据，然后提供读服务的机器称之为Slave。但在zookeeper中被分为Leader、Follower、Observe三种角色。

**Leader**  
zookeeper通过Leader选举过程来选取一台“Leader”的机器，Leader服务器是整个zookeeper集群工作机制中的核心。即能提供读服务也能提供写服务。主要工作有以下两个。

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

使用责任链模式来处理每一个客户端请求时Zookeeper的一大特色，如下图就是Leader服务器的请求处理链。  
![这里写图片描述][70]

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

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

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

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

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

ToBeCommitProcessor  
ToBeCommitProcessor是一个比较特别的处理器，ToBeCommitProcessor处理器中有一个toBeApplised队列，专门用来存储哪些已经被CommitProcessor处理过的可被提交的Proposal。ToBeCommitProcessor处理器将这些请求逐个交付给FinalRequestProcessor处理器进行处理，等FinalRequestProcessor处理器处理完后，再将其从队列中移除。

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

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

**Follower**  
从名字可以看出Follower服务器是zookeeper集群状态的跟随者，主要工作有以下三个：

*  处理客户端非事务请求，转发事务请求给Leader服务器
 *  参与事务请求proposal的投票
 *  参与Leader选举投票  
    ![这里写图片描述][70 1]

FollowerRequestProcessor  
FollowerRequestProcessor是Follower服务器的第一个请求处理器，只要工作就是识别出当前请求是否是事务请求。如果是就将该事务请求转发给Leader服务器处理。

SendAckRequestProcessor  
SendAckRequestProcessor处理器同样承担了事务日志记录反馈的角色，在完成日志记录后，会向Leader服务器发送ACK消息表明自身完成了事务日志的记录工作。  
**Observer**  
Observer是zookeeper从3.3.0版本开始引入的一个服务器角色，从名字可以看出该服务器充当了一个观察者的角色——观察zookeeper集群的最新状态变化并将这些状态变更同步过来。Observer服务器在工作原理上和Follower基本是一致的，对于非事务请求，都可以进行独立的处理，对于事务请求，则会转发给Leader服务器进行处理。和Follower唯一的区别在于，Observer不参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。也就是说Observer服务器只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。  
其处理请求链和Follower类似。

[70]: /images/20220525/b631325a5ce24f0886c77d0a53a17d7c.png
[70 1]: /images/20220525/cad5654542ab469cb89776f96bf7297c.png