netty ChannelPipeline的事件传输机制
2023/8/16 2:22:15
本文主要是介绍netty ChannelPipeline的事件传输机制,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
一、Netty的事件类型
从ChannelPipeline的传输的事件类型角度,Netty的事件可以分为Inbound和Outbound事件。
Inbound事件是一个通知事件,当某件事已经发生了,然后通过Inbound事件进行通知,Inbound通常发生在Channel的状态的改变或IO事件就绪
Outbound事件都是请求事件, 请求某件事情的发生, 然后通过Outbound事件进行通知。
1、入站事件传播方法
1.1、ChannelHandlerContext#fireChannelRegistered()
作用:触发事件告知Inbound ChannelHandler:ChannelHandlerContext的Channel注册于其EventLoop,调用ChannelInboundHandler的channelRegistered
1.2、ChannelHandlerContext#fireChannelActive()
作用:触发事件告知Inbound ChannelHandler:ChannelHandlerContext的Channel现在处于活动状态,调用ChannelInboundHandler的channelActive
1.3、ChannelHandlerContext#fireChannelRead(Object)
作用:触发事件告知Inbound ChannelHandler:当前Channel正在从对等方读取消息,调用ChannelInboundHandler的channelRead。
1.4、ChannelHandlerContext#fireChannelReadComplete()
作用:触发事件告知Inbound ChannelHandler:当前读操作读取的最后一条消息被channelRead(ChannelHandlerContext, Object)}使用,调用ChannelInboundHandler的channelReadComplete。
1.5、ChannelHandlerContext#fireExceptionCaught(Throwable)
作用:触发事件告知Inbound ChannelHandler:抛出Throwable异常,调用ChannelInboundHandler的exceptionCaught。
1.6、ChannelHandlerContext#fireUserEventTriggered(Object)
作用:触发事件告知Inbound ChannelHandler:用户事件正在触发,调用ChannelInboundHandler的userEventTriggered。
1.7、ChannelHandlerContext#fireChannelWritabilityChanged()
作用:触发事件告知Inbound ChannelHandler:Channel的可写状态发生更改,调用ChannelInboundHandler的channelWritabilityChanged。
1.8、ChannelHandlerContext#fireChannelInactive()
作用:触发事件告知Inbound ChannelHandler:ChannelHandlerContext的Channel现在是不活动的,并已达到其生命周期的结束,调用ChannelInboundHandler的channelInactive
1.9、ChannelHandlerContext#fireChannelUnregistered()
作用:触发事件告知Inbound ChannelHandler:ChannelHandlerContext的Channel从其EventLoop注销,调用ChannelInboundHandler的channelUnregistered
2、出站事件传播方法:
2.1、ChannelHandlerContext#bind(SocketAddress, ChannelPromise)
作用:请求绑定到给定的SocketAddress,并在操作完成后通知ChannelFuture,原因可能是操作成功,也可能是错误,调用ChannelOutboundHandler的bind
2.2、ChannelHandlerContext#connect(SocketAddress, SocketAddress, ChannelPromise)
作用:请求连接到给定的SocketAddress,并在操作完成后通知ChannelFuture,原因可能是操作成功,也可能是错误,调用ChannelOutboundHandler的connect
2.3、ChannelHandlerContext#write(Object, ChannelPromise)
作用:请求通过这个ChannelHandlerContext通过ChannelPipeline写入消息。此方法不会请求实际刷新,因此请确保在希望请求将所有挂起数据刷新到实际传输时调用flush()。
2.4、ChannelHandlerContext#flush()
作用:请求通过此ChannelOutboundInvoker刷新所有挂起的消息。
2.5、ChannelHandlerContext#read()
作用:请求从Channel读取数据到第一个入站缓冲区,如果读取数据,则触发ChannelInboundHandler#channelRead(ChannelHandlerContext, Object)事件,并触发ChannelInboundHandler#channelReadComplete(ChannelHandlerContext) channelReadComplete事件,以便处理程序可以决定继续读取。如果已经有一个挂起的读操作,这个方法什么也不做。
2.6、ChannelHandlerContext#disconnect(ChannelPromise)
作用:请求断开与远程对等点的连接,并在操作完成后通知ChannelFuture,原因可能是操作成功,也可能是错误,调用ChannelOutboundHandler的disconnect
2.7、ChannelHandlerContext#close(ChannelPromise)
作用:请求关闭Channel,并在操作完成后通知ChannelFuture,原因可能是操作成功,也可能是错误,调用ChannelOutboundHandler的close。关闭后,就不可能再重用它了。
2.8、ChannelHandlerContext#deregister(ChannelPromise)
作用:请求从之前分配的EventExecutor取消注册,并在操作完成后通知ChannelFuture,原因可能是操作成功,也可能是错误,调用ChannelOutboundHandler的deregister。
3、下图描述了在ChannelPipeline中ChannelHandlers如何处理I/O事件
这个图是源码io.netty.channel.ChannelPipeline接口的备注部分提供的。
二、ChannelPipeline的结构
ChannelPipeline的数据结构是双向链表。
三、HeadContext的作用
Outbound事件最后都是通过HeadContext完成(HeadContext最后调用NioSocketChannelUnsafe响应的方法完成),Inbound事件是从HeadContext开始。
四、TailContext的作用
一个处理字节和消息的特殊的捕获全部事件的处理程序,Outbound事件是从tailContext开始,Inbound事件是在tailContext结束。
五、Inbound事件流
在Channel中调用DefaultChannelPipeline.fireChannelActive,接下来在Channel交给自己的DefaultChannelPipeline执行了,因为是Inbound事件,所以从HeadContext->TailContext。DefaultChannelPipeline中Inbound事件传递过程:
Context.fireChannelActive -> Connect.findContextInbound -> Connect.invokeChannelActive(final AbstractChannelHandlerContext next)-> next.invokeChannelActive -> nextHandler.channelActive -> nextContext.fireChannelActive
六、Outbound 事件流
6.1、Outbound事件流过程
以 Bootstrap.connect 的事件流为例,大致如下:
Bootstrap.connect -> Bootstrap.doResolveAndConnect-> Bootstrap.doResolveAndConnect0-> Bootstrap.doConnect-> AbstractChannel.connect->DefaultChannelPipeline.connect->NioSocketChannelUnsafe.connect->NioSocketChannel.doConnect->SocketChannel.connect
最后都是到了Channel,然后Channel交给自己的DefaultChannelPipeline执行,因为是 Outbound 事件,所以从TailContext ->HeadContext,HeadContext最后调用NioSocketChannelUnsafe响应的方法完成,事件流的NioSocketChannelUnsafe.connect->NioSocketChannel.doConnect->SocketChannel.connect部分就是在HeadContext里面执行的。
6.2、DefaultChannelPipeline中事件传递过程
Context.connect -> Context.findContextOutbound -> next.invokeConnect -> handler.connect -> Context.connect
一致循环从TailContext 将事件传递到HeadContext。
作者:静夜明灯
链接:https://www.jianshu.com/p/7de2ae969daa
这篇关于netty ChannelPipeline的事件传输机制的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-11-16轻巧的Kubernetes与WebAssembly的完美搭档
- 2024-11-16基于AWS的Java应用持续集成与持续部署全流程指南:从构建到部署在Amazon EKS上运行
- 2024-11-15为什么我在Kubernetes集群里需要一个API网关?
- 2024-11-15亚马逊EKS的未来发展趋势
- 2024-11-15使用Kubernetes简化分布式Spring Boot应用中的定时任务管理
- 2024-11-15教你轻松几步升级Hetzner上超划算的Kubernetes集群
- 2024-11-15动手排查Kubernetes网络故障之旅
- 2024-11-15Kubernetes监控:最佳实践指南
- 2024-11-15两年使用Kubernetes运行Airflow后我们学到的经验教训
- 2024-11-15如何用三条配置行解决我们在Kubernetes中遇到的gRPC扩展问题