[netty]--Reactor线程模型以及在netty中的应用

红太狼 2022-07-12 08:52 305阅读 0赞

> 说道netty的线程模型，我们第一反应就是经典的Reactor线程模型，下面我们就来一起探讨一下三种经典的Reactor线程模型：
> 
> 这里我们需要理解的一点是Reactor线程模型是基于同步非阻塞IO实现的。对于异步非阻塞IO的实现是Proactor模型。
> 
> 本文主要包括  
> （1）Reactor单线程模型
> 
> （2）Reactor多线程模型
> 
> （3）主从Reactor多线程模型
> 
> （4）netty的多线程模型

# 1.Reactor单线程模型  #

Reactor单线程模型就是指所有的IO操作都在同一个NIO线程上面完成的，也就是IO处理线程是单线程的。NIO线程的职责是：  
（1）作为NIO服务端，接收客户端的TCP连接；

（2）作为NIO客户端，向服务端发起TCP连接；

（3）读取通信对端的请求或则应答消息；

（4）向通信对端发送消息请求或则应答消息。

Reactor单线程模型图如下所示：  
![单线程Reactor][Reactor]

Reactor模式使用的是同步非阻塞IO(NIO)，所有的IO操作都不会导致阻塞，理论上一个线程可以独立的处理所有的IO操作(selector会主动去轮询哪些IO操作就绪)。从架构层次看，一个NIO线程确实可以完成其承担的职责，比如上图的Acceptor类接收客户端的TCP请求消息，当链路建立成功之后，通过Dispatch将对应的ByteBuffer转发到指定的handler上，进行消息的处理。

对于一些小容量的应用场景下，可以使用单线程模型，但是对于高负载、大并发的应用场景却不适合，主要原因如下：  
（1）一个NIO线程处理成千上万的链路，性能无法支撑，即使CPU的负荷达到100%；

（2）当NIO线程负载过重，处理性能就会变慢，导致大量客户端连接超时然后重发请求，导致更多堆积未处理的请求，成为性能瓶颈。

（3）可靠性低，只有一个NIO线程，万一线程假死或则进入死循环，就完全不可用了，这是不能接受的。

基于上诉问题，提出了Reactor的多线程模型：

# 2.Reactor多线程模型  #

Reactor多线程模型与单线程模型最大的区别在于，IO处理线程不再是一个线程，而是一组NIO处理线程。原理如下图所示：  
![这里写图片描述][SouthEast]

Reactor多线程模型的特点如下：  
（1）有一个专门的NIO线程—-Acceptor线程用于监听服务端，接收客户端的TCP连接请求。

（2）网络IO操作—-读写等操作由一个专门的线程池负责，线程池可以使用JDK标准的线程池实现，包含一个任务队列和N个可用的线程，这些NIO线程就负责读取、解码、编码、发送。

（3）一个NIO线程可以同时处理N个链路，但是一个链路只对应一个NIO线程。

Reactor多线程模型可以满足绝大多数的场景，除了一些个别的特殊场景：比如一个NIO线程负责处理客户所有的连接请求，但是如果连接请求中包含认证的需求（安全认证），在百万级别的场景下，就存在性能问题了，因为认证本身就要消耗CPU，为了解决这种情景下的性能问题，产生了第三种线程模型：Reactor主从线程模型。

# 3.主从Reactor多线程模型  #

主从Reactor线程模型的特点是：服务端用于接收客户端连接的不再是一个单独的NIO线程，而是一个独立的NIO的线程池。Acceptor接收到客户端TCP连接请求并处理完成后（可能包含接入认证），再将新创建的SocketChannel注册到IO线程池（sub reactor）的某个IO处理线程上并处理编解码和读写工作。Acceptor线程池仅负责客户端的连接与认证，一旦链路连接成功，就将链路注册到后端的sub Reactor的IO线程池中。 线程模型图如下：  
![这里写图片描述][SouthEast 1]

利用主从Reactor模型可以解决服务端监听线程无法有效处理所有客户连接的性能不足问题，这也是netty推荐使用的线程模型。

# 4. netty的线程模型  #

netty的线程模型是可以通过设置启动类的参数来配置的，设置不同的启动参数，netty支持Reactor单线程模型、多线程模型和主从Reactor多线程模型。  
![这里写图片描述][SouthEast 2]

服务端启动时创建了两个NioEventLoopGroup，一个是boss，一个是worker。实际上他们是两个独立的Reactor线程池，一个用于接收客户端的TCP连接，另一个用于处理Io相关的读写操作，或则执行系统的Task，定时Task。

Boss线程池职责如下：  
（1）接收客户端的连接，初始化Channel参数  
（2）将链路状态变更时间通知给ChannelPipeline

worker线程池作用是：  
（1）异步读取通信对端的数据报，发送读事件到ChannelPipeline  
（2）异步发送消息到通信对端，调用ChannelPipeline的消息发送接口  
（3）执行系统调用Task;  
（4）执行定时任务Task；

通过配置boss和worker线程池的线程个数以及是否共享线程池等方式，netty的线程模型可以在单线程、多线程、主从线程之间切换。

为了提升性能，netty在很多地方都进行了无锁设计。比如在IO线程内部进行串行操作，避免多线程竞争造成的性能问题。表面上似乎串行化设计似乎CPU利用率不高，但是通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁串行线程设计性能更优。  
  
nettyd的NioEventLoop读取到消息之后，直接调用ChannelPipeline的fireChannelRead(Object msg)，只要用户不主动切换线程，一直都是由NioEventLoop调用用用户的Handler，期间不进行线程切换，这种串行化设计避免了多线程操作导致的锁竞争，性能角度看是最优的。

# 5. netty的线程模型 设置最佳实践 #

（1）创建两个NioEventLoopGroup，隔离NIO Acceptor和NIO的IO线程。

（2）尽量不要在ChannelHandler中启动用户线程（解码之后，将POJO消息派发到后端的业务线程池除外）。

（3）解码要放在NIO线程调用的Handler中，不要放在用户线程中解码。

（4）如果IO操作非常简单，不涉及复杂的业务逻辑计算，没有可能导致阻塞的磁盘操作、数据库操作、网络操作等，可以再NIO线程调用的Handler中完成业务逻辑，不要切换到用户线程。  
  
（5）如果IO业务操作比较复杂，就不要在NIO线程上完成，因为阻塞可能会导致NIO线程假死，严重降低性能。这时候可以把POJO封装成Task，派发到业务线程池中由业务线程处理，以保证NIO，线程被尽快的释放，处理其余的IO操作。

[Reactor]: /images/20220710/a25a67687dc747d1a211f320986b1756.png
[SouthEast]: /images/20220710/273ea06bb03740b48cd5f5054831a193.png
[SouthEast 1]: /images/20220710/57cc2f8e362641b190f50327d0a34bbc.png
[SouthEast 2]: /images/20220710/87451525d58e4fe2b11952718905a836.png