Netty网络模型

来源:互联网 发布:矢量图标网站知乎 编辑:程序博客网 时间:2024/06/05 06:54

Netty网络模型

转载:http://www.infoq.com/cn/articles/netty-threading-model#mainLogin

网络服务器的基本功能(流程)就是:
建立连接 -> 读取请求 -> 解析请求 -> 调用处理过程 -> 编码结果 -> 发送结果

Netty是典型的Reactor模型结构。

传统多线程模型:

一个人来就餐,一个服务员去服务,然后客人会看菜单,点菜。 服务员将菜单给后厨。
二个人来就餐,二个服务员去服务……
五个人来就餐,五个服务员去服务……
(也就是每个请求对应一个线程去处理)

Reactor模式:
当客人点菜的时候,服务员就可以去招呼其他客人了,等客人点好了菜,直接招呼一声“服务员”,马上就有个服务员过去服务。这就是用单个线程来做多线程的事。
(也就是当准备好了,通知系统,启用一个线程来处理事情)

Reactor模型

无论是C++还是Java编写的网络框架,大多数都是基于Reactor模式进行设计和开发,Reactor模式基于事件驱动,特别适合处理海量的I/O事件。

1. 单线程模型

这里写图片描述
Reactor单线程模型,指的是所有的IO操作都在同一个NIO线程上面完成。

也就是说,只有一个Selector(在Reactor线程中)来接受建立连接请求,读取数据,处理请求,返回数据。

整个系统只有一个线程。

NIO线程的职责如下:

1)作为NIO服务端,接收客户端的TCP连接;

2)作为NIO客户端,向服务端发起TCP连接;

3)读取通信对端的请求或者应答消息;

4)向通信对端发送消息请求或者应答消息。

由于Reactor模式使用的是异步非阻塞IO,所有的IO操作都不会导致阻塞,理论上一个线程可以独立处理所有IO相关的操作。从架构层面看,一个NIO线程确实可以完成其承担的职责。例如,通过Acceptor类接收客户端的TCP连接请求消息,链路建立成功之后,通过Dispatch将对应的ByteBuffer派发到指定的Handler上进行消息解码。用户线程可以通过消息编码通过NIO线程将消息发送给客户端。

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

1)一个NIO线程同时处理成百上千的链路,性能上无法支撑,即便NIO线程的CPU负荷达到100%,也无法满足海量消息的编码、解码、读取和发送;

2)当NIO线程负载过重之后,处理速度将变慢,这会导致大量客户端连接超时,超时之后往往会进行重发,这更加重了NIO线程的负载,最终会导致大量消息积压和处理超时,成为系统的性能瓶颈;

3)可靠性问题:一旦NIO线程意外跑飞,或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障。

为了解决这些问题,演进出了Reactor多线程模型。

2. 多线程模型

Rector多线程模型与单线程模型最大的区别就是有一组NIO线程(线程池)处理IO操作,它的原理图如下:
这里写图片描述
采用了多线程处理I/O,虽然还是只有一个单个Selector(Reactor线程中),但是请求的处理大头交给了后边的线程池异步执行。

Reactor多线程模型的特点:

1)有专门一个NIO线程-Acceptor线程用于监听服务端,接收客户端的TCP连接请求;

2)网络IO操作-读、写等由一个NIO线程池负责,线程池可以采用标准的JDK线程池实现,它包含一个任务队列和N个可用的线程,由这些NIO线程负责消息的读取、解码、编码和发送;

3)1个NIO线程可以同时处理N条链路,但是1个链路只对应1个NIO线程,防止发生并发操作问题。

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

事实上,大部分网络程序为了更高的性能,都采用了主从Reactor多线程模型,拥有多个Selector线程,即Reactor线程组的模型,Netty也不例外,采用了多个Selector。

3. 主从多线程模型

这里写图片描述

主从Reactor线程模型的特点是:

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

利用主从NIO线程模型,可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题。

它的工作流程总结如下:

从主线程池中随机选择一个Reactor线程作为Acceptor线程,用于绑定监听端口,接收客户端连接;

Acceptor线程接收客户端连接请求之后创建新的SocketChannel,将其注册到主线程池的其它Reactor线程上,由其负责接入认证、IP黑白名单过滤、握手等操作;
步骤2完成之后,业务层的链路正式建立,将SocketChannel从Main线程池的Reactor线程的多路复用器Selector上摘除,重新注册到Sub线程池的线程上,用于处理I/O的读写操作。