Netty4线程模型

我不是女神ヾ 2022-04-18 00:14 272阅读 0赞

# Reactor模型 #

## 单线程模型 ##

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

1）作为NIO服务端，接收客户端的TCP连接；  
2）作为NIO客户端，向服务端发起TCP连接；  
3）读取通信对端的请求或者应答消息；  
4）向通信对端发送消息请求或者应答消息。

Reactor单线程模型示意图如下所示：

![在这里插入图片描述][20181108210443712.png]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70]

对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发的应用场景却不合适，主要原因如下：

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

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

## Rector多线程模型 ##

Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理IO操作，它的原理图如下：  
![在这里插入图片描述][20181108210458640.png]

Reactor多线程模型的特点：

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

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

## 主从Reactor线程模型 ##

服务端用于**接收客户端连接**的不再是个1个单独的NIO线程，而是**一个独立的NIO线程**池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。

![在这里插入图片描述][20181108210512766.png]

它的工作流程总结如下：

从主线程池中**随机选择**一个Reactor线程作为Acceptor线程，用于绑定监听端口，接收客户端连接；  
Acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作；  
步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，用于处理I/O的读写操作。

# Netty4线程模型 #

## 服务端线程模型 ##

一种比较流行的做法是服务端监听线程和IO线程分离，类似于Reactor的多线程模型，它的工作原理图如下：  
![在这里插入图片描述][20181105210859130.png]

和Reactor模式中的角色对比：

### Selector ###

JAVA NIO提供的SelectableChannel多路复用器，它内部维护着三个SelectionKey集合，负责配合select操作将就绪的IO事件分离出来，落地为SelectionKey。  
在Netty线程模型中，我认为Selector充当着demultiplexer的角色，而对于SelectionKey我们可以将它看成Reactor模式中的资源。

### EventLoopGroup/EventLoop ###

EventLoopGroup是一组EventLoop的抽象，由于Netty对Reactor模式进行了变种，实际上为更好的利用多核CPU资源，Netty实例中一般会有多个EventLoop同时工作，**每个EventLoop维护着一个Selector实例**

在Netty服务器编程中我们需要BossEventLoopGroup和WorkerEventLoopGroup两个EventLoopGroup来进行工作。**通常一个服务端口即一个ServerSocketChannel对应一个Selector和一个EventLoop线程，也就是我们建议BossEventLoopGroup的线程数参数这是为1。**  
BossEventLoop负责接收客户端的连接并将SocketChannel交给WorkerEventLoopGroup来进行IO处理。下面是他们的工作示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 1]

如上图，BossEventLoopGroup通常是一个单线程的EventLoop，EventLoop维护着一个注册了ServerSocketChannel的Selector实例，BossEventLoop不断轮询Selector将连接事件分离出来，通常是**OP\_ACCEPT事件**  
然后**将accept得到的SocketChannel**交给**WorkerEventLoopGroup**，WorkerEventLoopGroup会由**next**选择其中一个EventLoopGroup来将这个SocketChannel注册到其维护的Selector并对其后续的IO事件进行处理。

### ChannelPipeline ###

在Netty中ChannelPipeline维护着一个ChannelHandler的链表队列  
每个SocketChannel都有一个维护着一个ChannelPipeline实例  
ChannelPipeline其实是担任着Reactor模式中的**请求处理器**这个角色

ChannelPipeline的默认实现是DefaultChannelPipeline，DefaultChannelPipeline本身维护着一个用户不可见的tail和head的ChannelHandler，他们分别位于链表队列的头部和尾部。tail在更上从的部分，而head在靠近网络层的方向。

在Netty中关于ChannelHandler有两个重要的接口，  
1）ChannelInBoundHandler  
inbound可以理解为网络数据从外部流向系统内部  
2）ChannelOutBoundHandler。  
outbound可以理解为网络数据从系统内部流向系统外部

用户实现的ChannelHandler可以根据需要实现其中一个或多个接口，将其放入Pipeline中的链表队列中，ChannelPipeline会**根据不同的IO事件类型**来找到相应的Handler来处理，同时链表队列是责任链模式的一种变种

### Netty EventLoop ###

Netty的单线程模型图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 2]

在Netty的EventLoop线程中，这个线程主要需要处理IO事件和其他两种任务，分别为  
定时任务  
和一般任务

这些个任务都是什么呢？

Netty提供可一个参数ioRatio用于用户调整单线程对于IO处理时间和任务处理时间的分配的比率。这样根据实际应用场景用户可以对这个值进行调整，默认值是50，也就是这个线程会将处理IO的时间和处理任务的时间控制为1：1。

final long ioStartTime = System.nanoTime();
        processSelectedKeys();//处理IO事件
        final long ioTime = System.nanoTime() - ioStartTime;//处理IO事件的时间
        runAllTasks(ioTime * (100 - ioRatio) / ioRatio);//计算用于处理任务的时间

一个EventLoop会关联多个Channel，这些Channel在单个线程下并不会出现并发问题，同时对于异步任务的处理也一样，Netty这样设计即免去了**并发问题的烦恼**，有减少了**多线程上下文切换带来的性能损耗**，同时基于EventLoopGroup实现的有限的线程数能够充分利用CPU处理能力。

轮询方法io.netty.channel.nio.NioEventLoop\#run

Netty是个异步高性能的NIO框架，它并不是个业务运行容器，因此**它不需要也不应该提供业务容器和业务线程**。合理的设计模式是**Netty只负责提供和管理NIO线程**，其它的业务层线程模型由用户自己集成，Netty不应该提供此类功能，只要将分层划分清楚，就会更有利于用户集成和扩展。

## Netty线程开发最佳实践 ##

1）时间可控的简单业务直接在IO线程上处理  
2）复杂和时间不可控业务建议投递到后端业务线程池统一处理

对于此类业务，不建议直接在业务ChannelHandler中启动线程或者线程池处理，建议将不同的业务统一封装成Task，统一投递到后端的业务线程池中进行处理。

3）业务线程避免直接操作ChannelHandler

参考：  
[http://www.infoq.com/cn/articles/netty-threading-model?utm\_source=infoq&utm\_medium=popular\_links\_homepage][http_www.infoq.com_cn_articles_netty-threading-model_utm_source_infoq_utm_medium_popular_links_homepage]  
[https://my.oschina.net/andylucc/blog/618179][https_my.oschina.net_andylucc_blog_618179]

[20181108210443712.png]: /images/20220418/f2e499d54b2d4d6194a37821d8758e61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70]: /images/20220418/d91cae8e049c418db85270166552d36f.png
[20181108210458640.png]: /images/20220418/172e5a492db14c5aa17ea840183b262d.png
[20181108210512766.png]: /images/20220418/6a517aa73cbc42159c29947b8b30f89c.png
[20181105210859130.png]: /images/20220418/110ab08165ef4c62b23412ceac47de8a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 1]: /images/20220418/dbb7997a38004ae6b0788c6314494c70.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 2]: /images/20220418/c648929416634e23902eb446f08bb7ca.png
[http_www.infoq.com_cn_articles_netty-threading-model_utm_source_infoq_utm_medium_popular_links_homepage]: http://www.infoq.com/cn/articles/netty-threading-model?utm_source=infoq&utm_medium=popular_links_homepage
[https_my.oschina.net_andylucc_blog_618179]: https://my.oschina.net/andylucc/blog/618179