netty 源码分析之（六）事件驱动模式ChannelEvent

在ESB服务分发中，

发送端动作为：把任务Task封装到一个基类Event，使用MQ  发送者发送publish.send(ObjectMessage);

接收端动作为：使用MQ接收到ObjectMessage，转换成基类Event，把Event传送到处理链Handlers。可以使用Map<event.class，List<Handler> handlers> 保存事件与Handlers的对应关系。所以，先根据event.class取出 List<Handler> handlers，逐一进行处理。

另，可以在初始化时把handler注册到Map<event.class，List<Handler> handlers>上。

 

Netty提供了全面而又丰富的网络事件类型，其将java中的网络事件分为了两种类型Upstream和Downstream。一般来说，Upstream类型的事件主要是由网络底层反馈给Netty的，比如messageReceived,channelConnected等事件，而Downstream类型的事件是由框架自己发起的，比如bind,write,connect,close等事件。

Netty的Upstream和Downstream网络事件类型特性也使一个Handler分为了3种类型，专门处理Upstream,专门处理Downstream,同时处理Upstream,Downstream。实现方式是某个具体Handler通过继承ChannelUpstreamHandler和ChannelDownstreamHandler类来进行区分。PipeLine在Downstream或者Upstream类型的网络事件发生时，会调用匹配事件类型的Handler响应这种调用。ChannelPipeline维持有所有handler有序链表，并且由handler自身控制是否继续流转到下一个handler(ctx.sendDownstream(e),这样设计有个好处就是随时终止流转，业务目的达到无需继续流转到下一个handler)。下面的代码是取得下一个处理Downstream事件的处理器。

DefaultChannelHandlerContext realCtx = ctx;

while (!realCtx.canHandleUpstream()) {

    realCtx = realCtx.next;

    if (realCtx == null) {

        return null;

    }

}

return realCtx;

 

 

Netty使用了异步的事件驱动模型，来触发网络I/O的各种操作，其在socket层上面封装一层异步事件驱动模型，使得业务代码不需要关心网络底层，就可以编写异步的无网络I/O阻塞的代码。

Netty的异步事件驱动模型主要涉及到下面几个核心的概念：

 

•   Channel：表示一个与socket关联的通道
•  ChannelPipeline：管道，一个Channel拥有一个ChannelPipeline，ChannelPipeline维护着一个处理链（严格的说是两个：upstream、downstream），处理链是由很多处理句柄ChannelHandler所构成，每个ChannelHandler处理完以后会传递给链中的下一个处理句柄继续处理。
•   ChannelHandler：处理句柄，用户可以定义自己的处理句柄来处理每个请求，或发出请求前进行预处理，典型的有编码/解码器：decoder、encoder。
•  ChannelEvent：事件，是整个模型的处理对象，当产生或触发（fire）一个事件时，该事件会沿着ChannelPipeline处理链依次被处理。
•  ChannelFuture：异步结果，这个是异步事件处理的关键，当一个事件被处理时，可以直接以ChannelFuture的形式直接返回，不用在当前操作中被阻塞。可以通过ChannelFuture得到最终的执行结果，具体的做法是在ChannelFuture添加监听器listener，当操作最终被执行完后，listener会被触发，我们可以在listener的回调函数中预定义我们的业务代码。

 

 

模型的结构图如下：

 

ChannelPipeline实际上维持了两个处理链：upstream、downstream。Upstream一般处理来自Channel的读事件，而downstream一般处理向Channel的写事件。需要注意的是，这两个处理链是相互独立的，在upstream链中传递到最后一个ChannelHandler处理后，不会再传递到downstream链中继续处理。

在downstream链的末端会有个ChannelSink处理，用户可以自定义这个ChannelSink的实现，系统也有个默认的实现，当downstream链中最后一个ChannelHandler处理完后会被传递给这个ChannelSink进行最后的处理。