ZooKeeper集群中的跟随者对客户端请求的处理流程解读(二)

jopen 5年前

前篇简要回顾:在ZooKeeper集群选举完成之后,各个集群节点各就各位,领导者开始领导、跟随者开始跟随,我们已经看到跟随者建立和领导者的连接,并接受领导者的命令开始恢复,恢复完成之后领导者给了跟随者一个UPTODATE命令,跟随者开始进入接客状态。。。


那么这里出现了两条线,跟随者一方面开始接客(接收并处理客户端的读写请求,为ZK客户端服务),另一方面跟随者保持和领导者的密切连接,通过连接做一些事情,这个会在后面讲到,我们先看看跟随者是如何接客的,这也是和文章的标题相呼应。


跟随者为客户端服务的入口在这里我们通过NettyServerCnxnFactory这个类介绍,这个类是ZK通过Netty(NIO框架)来处理网络层业务的实现,我的之前一篇文章(http://jvmplus.duapp.com /blog/view/B143299758)有介绍Netty在ZooKeeper中的应用,其中介绍了NettyServerCnxnFactory 是如何基于Netty建立网络连接、获取连接通道、接收和发送网络数据的,关于这部分读者可以直接简要阅读下那篇文章,这里我么你直接往下走,看ZK是如 何和客户端进行互动的。

看下NettyServerCnxnFactory的 processMessage方法,这个方法主要是用来处理通道数据的,这里ZK对客户端的连接通道主要消息类型有两种,分别是 ResumeMessageEvent(回复通道事件)和Netty从通道拿到数据并封装的原始类型,即非ResumeMessageEvent类型。 ResumeMessageEvent类型消息是ZK通过实现Netty的MessageEvent接口实现的一种消息事件类型,主要是用来区别是原始网 络通道读取的客户端消息事件,还是ZK通过Netty的ChannelPipeline类的sendUpstream方法向通道上传的消息事件类型数据, 后面processMessage方法会针对这两种不同类型的消息事件类型做不同的事情。


当从通道中读取ResumeMessageEvent类型的消息事件类型的时候,ZK做的事情主要是回复通道,将通道设置为可读(OP_READ)模式。


这里主要是看下ZK对非 ResumeMessageEvent类型的消息事件类型的处理,ZK为了防止通道的数据量太大,发生拥堵现象,ZK给 NettyServerCnxn(代表ZK和客户端连接的抽象)设置了一个字段throttled,它用来标识当前通道的数据是不是可以直接拿来处理,也 就是当处理的速度跟不上IO的速度额度时候,ZK会将throttled这个值设置为true,如果是throttled状态,则ZK将读取的消息放入内 存等待处理队列里面;如果当前通道处于非throttled状态,ZK首先看看等待队列是不是有数据在等待,如果有,ZK将读取的数据写入等待队列里面, 然后开始处理队列数据。如果队列为空,则ZK直接处理通道的数据,然后看看是否还有剩余,如果通道有剩余数据则将剩余数据写入等待队列。下面用图简单表示 一下ZK在这里对客户端端口网络消息的处理流程:



接 下来就是NettyServerCnxn的receiveMessage方法是如何对通道拿到的消息进行处理的,ZK这里会首先判断是否有可读消息,并且 再次判断throttled的状态,如果不满足可读的条件则关闭和客户端的连接,通常正常状态的ZK和客户端的连接应该是长连接,这里为什么为断开?这里 应该是发生了异常,也就是通道接收到了消息事件,但是又是不可读,则ZK会关闭和客户端的连接。


这 里ZK会判断连接的状态,如果是未初始化状态则ZK会把这个请求是当做连接请求,否则会会交给processPacket来处理。 processPacket会首先解析客户端请求包的类型,包括auth、sasl和普通类型三种,前两种类型是认证和授权相关的,后面有机会再介绍,这 里主要介绍普通类型包的处理过程,于是到了ZooKeeperServer的submitRequest这个方法,总算快要开始ZK对客户端请求处理流程 的核心部分了。


下篇文章进入ZooKeeper对客户端请求处理流程的核心部分。


来自:http://jvmplus.duapp.com/blog/view/B143719118