【二】zookeeper集群中各个角色介绍、集群间消息通信、某个节点处理客户端请求的流程

本文为书籍《从Paxos到Zookeeper  分布式一致性原理与实践》倪超著_北京:电子工业出版社的读书笔记,这本书还是蛮值得推荐的。

ZK中有三种角色,Leader、Follower、Observer

一、Leader

Leader服务器是整个ZK集群工作机制中的核心,它最主要的工作是

1.事务请求的的唯一调度和处理者,保证集群事务处理的顺序性

2.集群内部各服务器的调度者

1.请求处理链

使用责任链模式来处理每一个客户端请求。每一个服务器在启动的时候都会进行请求处理链的初始化。

Leader服务器的请求处理链如图:

1.1.1 PrepRequestProcessor

PrepRequestProcessor是leader服务器的请求预处理器,也是leader服务器的第一个请求处理器。

在ZK中我们将那些会改变服务器状态的请求称为“事务请求”----通常指的就是那些创建节点、更新数据、删除节点以及创建会话等请求,PrepRequestProcessor能够识别当前客户端请求是否是事务请求。

对于事务请求PrepRequestProcessor会进行一些预处理,如创建请求事务头、事务体、会话检查、ACL检查和版本检查等

1.1.2 ProposalRequestProcessor

ProposalRequestProcessor处理器是leader服务器的事务投票处理器,也是Leader服务器事务处理流程的发起者。

对于非事务请求,ProposalRequestProcessor会直接将请求流转到CommitProcessor处理器。

对于事务请求,除了提交给CommitProcessor处理器以外,还会根据请求类型创建对应的prosoal提案,并发送给所有的Follower服务器,来发起一次集群内的事务投票。同时,ProposalRequestProcessor还会将事务请求交付给SyncRequestProcessor进行事务日志记录。

1.1.3 SyncRequestProcessor

SyncRequestProcessor是事务记录处理器,主要作用是将事务请求记录到事务日志文件中,还会触发ZK进行数据快照。

1.1.4  AckRequestProcessor

AckRequestProcessor处理器是leader特有的处理器,主要作用是:在SyncRequestProcessor处理器完成事务日志记录后,向proposal的投票收集器发送ACK反馈,通知投票收集器当前服务器已经完成了对该prosoal的事务日志记录。

1.1.5 CommitProcessor

CommitProcessor是事务提交处理器。

对于非事务请求,该处理器会直接将其交给下一级处理器。

对于事务请求,CommitProcessor处理器会等待集群内针对proposal提案的投票直到该prosoal可被提交。利用CommitProcessor处理器,每个服务器都可以很好的控制对事务请求的顺序处理。

1.1.6 ToBeCommitProcessor

ToBeCommitProcessor是一个比较特殊的处理器。

它里面有一个ToBeApplied队列,专门用来存储那些已经被CommitProcessor处理过的可被提交的proposal。

ToBeCommitProcessor处理器将这些请求逐个交付给FinalRequestProcessor处理器进行处理----等到FinalRequestProcessor处理器处理完成后,再将其从ToBeApplied队列中移除

1.1.7 FinalRequestProcessor

FinalRequestProcessor是最后一个请求处理器。

主要作用:

1.进行客户端请求返回之前的收尾工作,包括创建客户端请求响应。

2.对于事务请求,该处理器还会负责将事务应用到内存数据库中去。

2.LearnerHandler

Leader服务器会与每一个Follow/Observer服务器都建议一个TCP长连接,同时也会为每个Follow/Observer服务器都创建一个名为LearnerHandler的实体。

LearnerHandler是ZK集群中leader服务器的管理器,主要负责Follow/Observer服务器和leader服务器之间的一系列网络通信,包括数据同步、请求转发、Proposal提议的投票等。

leader服务器保存了所有Follow/Observer对应的LearnerHanler

 二、Follower

它的主要工作是:

1.处理客户端非事务请求,转发事务请求给leader服务器

2.参与事务请求Proposal的投票

3.参与Leader选举投票

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

 1 .PING消息: 心跳消息;

 2 .PROPOSAL消息:Leader发起的提案,要求Follower投票;

 3 .COMMIT消息:服务器端最新一次提案的信息;

 4 .UPTODATE消息:表明同步完成;

 5 .REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息;

 6 .SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。

1.请求处理链

也采用了责任链模式组装的请求处理链来处理每一个客户端请求。

Follower服务器的请求处理链如图:

 2.1.1 FollowerRequestProcessor

FollowerRequestProcessor是Follower服务器的第一个请求处理器。

主要工作:识别出当前请求是否为事务请求。

对于事务请求,Follower会将当前转发到leader服务器,leader服务器在接收到这个事务请求后就会将其提交到自己的事务处理链按照正常事务请求进行处理。

2.1.2 SendAckRequestProcessor

主要作用:事务日志记录和反馈,在完成事务日记记录后,会向leader服务器发送ACK消息以表明自身完成了事务日志的记录工作。

三、Observer

主要作用:

1.处理客户端非事务请求,转发事务请求给leader服务器

即,Observer与Follower的区别就是Observer不参与任何形式的投票

也采用责任链模式组装了一些列的处理器

四、某个节点处理客户端请求的流程
preview

图片来自:https://zhuanlan.zhihu.com/p/270644841 

流程解释

1.Client向Follwer发出一个写的请求

2.Follwer把请求发送给Leader

3.Leader接收到以后开始发起投票并通知Follwer进行投票

4.Follwer把投票结果发送给Leader

5.Leader将结果汇总后如果需要写入,则开始写入同时把写入操作通知给Follower,然后commit;

6.Follwer把请求结果返回给Client

五、集群间消息通信

ZK的消息类型大致上可以分为4类:

1.数据同步型

2.服务器初始化型

3.请求处理型

4.会话管理型

1.数据同步型

这是指的在learner和leader服务器进行数据同步的时候,网络通信所用到的消息,通常有DIFF TRUNC SNAP  UPTODATE四种

2.服务器初始化型

这是指在整个集群或是某些新机器初始化的时候,Leader和Learner之间相互通信所使用的消息类型

3.请求处理型

这是指在请求处理的过程中,Leader和Learner之间相互通信所使用的消息

4.会话管理型

这是指ZK在进行会话管理的过程中,Leader和Learner之间相互通信所使用的消息

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值