处理业务:事件是如何在 pipeline 中传播的

Posted binarylei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了处理业务:事件是如何在 pipeline 中传播的相关的知识,希望对你有一定的参考价值。

处理业务:事件是如何在 pipeline 中传播的

Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html)

在上一节 接收数据:自适应缓冲区和连接读是为了解决什么问题 中,我们知道 NioEventLoop 不断的轮询,接收 OP_READ 事件;然后将读取到的数据通过 pipeline.fireChannelRead(byteBuf) 传播出去。所以业务的处理实际上是在 pipeline 的 channelRead() 上处理的,本小节也主要关注事件是在 pipeline 中传播行为。

事件在 pipeline 中的传播,需要关注事件的传播行为和执行线程:

  1. 传播行为:事件执行到某个 Handler 后,如果不手动触发 ctx.fireChannelRead,则传播中断。
  2. 执行线程:业务线程默认是在 NioEventLoop 中执行。如果业务处理有阻塞,需要考虑另起线程执行。

1. 主线分析

1.1 主线

主线其实在上一节已经讲了,在读取数据时会触发 pipeline.fireChannelRead(byteBuf) 把读取到的数据传播出去。我们现在重点分析事件是如何在 pipeline 中传播的。

技术图片

Handler 执行资格:

  • 实现 ChannelInboundHandler
  • 实现方法 channelRead 不能加注解 @Skip
  • Handler 执行链是可以被中断的。如果不主动触发 ctx.fireChannelRead 方法,则不会再继续往下执行。

1.2 知识点

(1)处理业务本质

数据在 pipeline 中所有的 ChannelInboundHandler 的 channelRead() 执行。并且执行可以被中断。

(2)业务处理线程

默认处理线程是 Channel 绑定的 NioEventLoop 线程,也可以设置其他线程:

pipeline.addLast(new UnorderedThreadPoolEventExecutor(10), serverHandler);

2. 源码分析

2.1 fireChannelRead 在 pipeline 中的传播

@Override
public final ChannelPipeline fireChannelRead(Object msg) {
    AbstractChannelHandlerContext.invokeChannelRead(head, msg);
    return this;
}

说明: 可以看到 fireChannelRead 是从 head -> tail 一直身后传播。

2.1 传播行为

pipeline 中一旦被中间某个 Handler 执行,则传播行为中断。如果需要继续执行下去,则需要主动调用 ctx.fireChannelRead。

// AbstractChannelHandlerContext
@Override
public ChannelHandlerContext fireChannelRead(final Object msg) {
    invokeChannelRead(findContextInbound(MASK_CHANNEL_READ), msg);
    return this;
}

private void invokeChannelRead(Object msg) {
    if (invokeHandler()) {
        try {
            ((ChannelInboundHandler) handler()).channelRead(this, msg);
        } catch (Throwable t) {
            notifyHandlerException(t);
        }
    } else {
        fireChannelRead(msg);
    }
}

说明: 可以看到要么执行 channelRead 方法,要么执行 fireChannelRead 方法直到找到一个对应的 Handler 为止。如果不主要调用 ctx.fireChannelRead,则传播行为会中断。

可能会奇怪,通过 findContextInbound() 不是找到对应的 Handler 了,为什么还需要通过 invokeHandler() 再判断一次?其实,findContextInbound 方法是查找有 channelRead 的 Handler,而 invokeHandler 方法则是判断这个 Handler 是否被删除了。

2.3 执行线程

每个 Handler 都是在自己对应的 executor 中执行,默认为 NioEventLoop 线程。当然也可以自己指定其它线程。

// AbstractChannelHandlerContext
static void invokeChannelRead(final AbstractChannelHandlerContext next, Object msg) {
    final Object m = next.pipeline.touch(ObjectUtil.checkNotNull(msg, "msg"), next);
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        next.invokeChannelRead(m);
    } else {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                next.invokeChannelRead(m);
            }
        });
    }
}

说明: 我们需要重点关注业务的执行线程,因为如果业务占用时间过长,会影响 Netty IO 的吞吐率。

2.4 ChannelPipeline vs ChannelHandlerContext

Netty 将每个 Handler 都包装成 ChannelHandlerContext 添加到 ChannelPipeline 中。虽然说 ChannelPipeline 也就调用 ChannelHandlerContext 中的方法,但 pipeline 会从 head 或 tail 开始遍历,而 ctx 只会从当前 hander 开始遍历。

我们还是拿以下四个 read 对比:channel.read()、pipeline.read()、ctx.read()、unsafe.read()

  • channel.read():直接调用 pipeline.read()。
  • pipeline.read():调用 tail.read(),从 head 或 tail 经历全部的 Handler。实际上,最后的 head.read() 调用 unsafe.beginRead(),这个方法会注册 OP_ACCEPT 或 OP_READ 事件从而激活 Channel。
  • ctx.read():从当前 ctx 开始之后的全部的 Handler。如果发送数据,需要使用 ctx.write 而不是 ctx.channel().write。
  • unsafe.read():最底层的 API。和 unsafe.beginRead() 不同,unsafe#read 会真正从 socket revbuf 读取数据。

2.5 HeadContext vs TailContext

  • HeadContext:
    • inbound 由事件触发,从 head -> tail,所以需要调用 ctx.firexxx 将事件传播下去。
    • outbound 由用户触发,从 tail -> head,通常会直接调用到 head。如果中间某个 Handler 重新自定义实现该方法,则不会再向下调,见 AbstractChannelHandlerContext#invokeWrite0。
  • TailContext:基本上没什么功能,一直向下传播事件即可。
HeadContext 功能
方法 执行顺序 功能说明
bind outbound unsafe.bind
connect outbound unsafe.connect
disconnect outbound unsafe.disconnect
close outbound unsafe.close
deregister outbound unsafe.deregister
read outbound unsafe.beginRead:注册感兴趣事件
write outbound unsafe.write
flush outbound unsafe.flush
exceptionCaught inbound ctx.fireExceptionCaught
channelRegistered inbound callHandlerAddedForAllHandlers
ctx.fireChannelRegistered
channelUnregistered inbound ctx.fireChannelUnregistered
destroy
channelActive inbound ctx.fireChannelActive
readIfIsAutoRead:调用unsafe.beginRead
channelInactive inbound ctx.fireChannelInactive()
channelRead inbound ctx.fireChannelRead
channelReadComplete inbound ctx.fireChannelReadComplete
readIfIsAutoRead
userEventTriggered inbound ctx.fireUserEventTriggered
channelWritabilityChanged inbound ctx.fireChannelWritabilityChanged
TailContext?功能
方法 执行顺序 功能说明
channelRead inbound ReferenceCountUtil.release(msg)

每天用心记录一点点。内容也许不重要,但习惯很重要!

以上是关于处理业务:事件是如何在 pipeline 中传播的的主要内容,如果未能解决你的问题,请参考以下文章

Netty事件传播详解

如何防止点击事件传播

5. Netty源码分析之ChannelPipeline 和 ChannelHanler

redis通过pipeline提升吞吐量

redis通过pipeline提升吞吐量

祖先的事件处理程序可以停止其子元素事件之一的传播吗?