Netty的线程模型

1、Netty的线程模型

当我们讨论 Netty线程模型的时候,一般首先会想到的是经典的 Reactor线程模型,尽管不同的NIO框架对于 Reactor模式的实现存在差异,但本质上还是遵循了 Reactor的基础线程模型。
下面让我们一起回顾经典的 Reactor线程模型。

1.1、Reactor单线程模型

Reactor单线程模型,是指所有的IO操作都在同一个NIO线程上面完成。NIO线程的职责如下。

• 作为NIO服务端,接收客户端的TCP连接;
• 作为NIO客户端,向服务端发起TCP连接;
• 读取通信对端的请求或者应答消息;
• 向通信对端发送消息请求或者应答消息

Reactor单线程模型如图18-1所示。

由于 Reactor模式使用的是异步非阻塞IO,所有的IO操作都不会导致阻塞,理论上一个线程可以独立处理所有IO相关的操作。从架构层面看,一个NIO线程确实可以完成其承担的职责。例如,通过 Acceptor类接收客户端的TCP连接请求消息,当链路建立成功之后,通过 Dispatch将对应的 ByteBuffer派发到指定的 Handler上,进行消息解码。用户线程消息编码后通过NIO线程将消息发送给客户端。
在一些小容量应用场景下,可以使用单线程模型。但是这对于高负载、大并发的应用场景却不合适,主要原因如下。

• 一个NIO线程同时处理成百上千的链路,性能上无法支撑,即便NIO线程的CPU负荷达到100%,也无法满足海量消息的编码、解码、读取和发送。
• 当NIO线程负载过重之后,处理速度将变慢,这会导致大量客户端连接超时,超时之后往往会进行重发,这更加重了NIO线程的负载,最终会导致大量消息积压和处理超时,成为系统的性能瓶颈
• 可靠性问题:一旦NIO线程意外跑飞,或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障。

为了解决这些问题,演进出了 Reactor多线程模型。下面我们一起学习下 Reactor多线程模型。

1.2、Reactor多线程模型

Rector多线程模型与单线程模型最大的区别就是有一组NIO线程来处理IO操作,它的原理如图18-2所示。

Reactor多线程模型的特点如下

• 有专门一个NIO线程— Acceptor线程用于监听服务端,接收客户端的TCP连接请求。
• 网络IO操作——读、写等由一个NIO线程池负责,线程池可以采用标准的JDK线程池实现,它包含一个任务队列和N个可用的线程,由这些NIO线程负责消息的读取、解码、编码和发送。
• 一个NIO线程可以同时处理N条链路,但是一个链路只对应一个NIO线程,防止发生并发操作问题。

在绝大多数场景下, Reactor多线程模型可以满足性能需求。但是,在个别特殊场景中,一个NIO线程负责监听和处理所有的客户端连接可能会存在性能问题。例如并发百万客户端连接,或者服务端需要对客户端握手进行安全认证,但是认证本身非常损耗性能在这类场景下,单独一个 Acceptor线程可能会存在性能不足的问题,为了解决性能问题,产生了第三种 Reactor线程模型——主从 Reactor多线程模型。

1.3、主从 Reactor多线程模型

主从 Reactor线程模型的特点是:服务端用于接收客户端连接的不再是一个单独的NIO线程,而是一个独立的NIO线程池。 Acceptor接收到客户端TCP连接请求并处理完成后(可能包含接入认证等),将新创建的 SocketChannel注册到IO线程池(sub reactor线程池)的某个IO线程上,由它负责 SocketChannel的读写和编解码工作。 Acceptor线程池仅仅用于客户端的登录、握手和安全认证,一旦链路建立成功,就将链路注册到后端 sub reactor线程池的IO线程上,由IO线程负责后续的O操作。
它的线程模型如图18-3所示。

利用主从NIO线程模型,可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。因此,在Netty的官方Demo中,推荐使用该线程模型。

1.4、Netty的线程模型

Netty的线程模型并不是一成不变的,它实际取决于用户的启动参数配置。通过设置不同的启动参数,Netty可以同时支持 Reactor单线程模型、多线程模型和主从 Reactor多线层模型。
下面让我们通过一张原理图(图18-4)来快速了解Netty的线程模型。

可以通过如图18-5所示的Netty服务端启动代码来了解它的线程模型。

服务端启动的时候,创建了两个 NioEventLoopGroup,它们实际是两个独立的 Reactor线程池。一个用于接收客户端的TCP连接,另一个用于处理IO相关的读写操作,或者执行系统Task、定时任务Task等。
Netty用于接收客户端请求的线程池职责如下。
(1)接收客户端TCP连接,初始化 Channel参数;
(2)将链路状态变更事件通知给 ChannelPipeline。
Netty处理IO操作的 Reactor线程池职责如下。
(1)异步读取通信对端的数据报,发送读事件到 ChannelPipeline;
(2)异步发送消息到通信对端,调用 ChannelPipeline的消息发送接口;
(3)执行系统调用Task;
(4)执行定时任务Task,例如链路空闲状态监测定时任务。
通过调整线程池的线程个数、是否共享线程池等方式,Netty的 Reactor线程模型可以在单线程、多线程和主从多线程间切换,这种灵活的配置方式可以最大程度地满足不同用户的个性化定制。
为了尽可能地提升性能, Netty在很多地方进行了无锁化的设计,例如在IO线程内部进行串行操作,避免多线程竞争导致的性能下降问题。表面上看,串行化设计似乎CPU利用率不高,并发程度不够。但是,通过调整NIO线程池的线程参数,可以同时启动多个串行化的线程并行运行,这种局部无锁化的串行线程设计相比一个队列一多个工作线程的模型性能更优。
它的设计原理如图18-6所示

Netty的 NioEventLoop读取到消息之后,直接调用 ChannelPipeline的fireChannelRead(Object msg)。只要用户不主动切换线程,一直都是由 NioEventLoop调用用户的 Handler,期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争,从性能角度看是最优的。

1.5、最佳实践

Netty的多线程编程最佳实践如下
(1)创建两个 NioEventLoopGroup,用于逻辑隔离 NIO Acceptor和 NIO I/O线程。
(2)尽量不要在 ChannelHandler中启动用户线程(解码后用于将POJO消息派发到后端业务线程的除外)。
(3)解码要放在NIO线程调用的解码 Handler中进行,不要切换到用户线程中完成消息的解码。
(4)如果业务逻辑操作非常简单,没有复杂的业务逻辑计算,没有可能会导致线程被阻塞的磁盘操作、数据库操作、网路操作等,可以直接在NIO线程上完成业务逻辑编排,不需要切换到用户线程。
5)如果业务逻辑处理复杂,不要在NIO线程上完成,建议将解码后的POJO消息封装成Task,派发到业务线程池中由业务线程执行,以保证NIO线程尽快被释放,处理其他的IO操作。
推荐的线程数量计算公式有以下两种
◎公式一:线程数量=(线程总时间/瓶颈资源时间)×瓶颈资源的线程并行数
◎公式二:QPS=1000/线程总时间×线程数
由于用户场景的不同,对于一些复杂的系统,实际上很难计算出最优线程配置,只能是根据测试数据和用户场景,结合公式给出一个相对合理的范围,然后对范围内的数据进行性能测试,选择相对最优值。

 

原文：

【Netty权威指南】14-NioEventLoop和NioEventLoopGroup_通往神秘的道路的专栏-CSDN博客_nioeventloopgroup