彻底搞懂 Netty 线程模型 _Netty

文章插图

本文作者：何建辉（公众号：org_yijiaoqian）

点赞再看，养成习惯，微信搜一搜【一角钱技术】关注更多原创技术文章。本文 GitHub org_hejianhui/JAVAStudy 已收录，有我的系列文章。

基本概念IO 模型

BIO：同步阻塞模型；
NIO：基于IO多路复用技术的“非阻塞同步”IO模型。简单来说，内核将可读可写事件通知应用，由应用主动发起读写事件；
AIO：非阻塞异步IO模型。简单来说，内核将读完成事件通知应用，读操作由内核完成，应用只需要操作数据即可；应用做异步写操作时立即返回，内核会进行写操作排队并执行写操作。

NIO 和 AIO 不同之处在于应用是否进行真正的读写操作。

reactor 和 proactor 模型

reactor：基于NIO技术，可读可写时通知应用；
proactor：基于AIO技术，读完成时通知应用，写操作应用通知内核。

Netty认识Netty是Java领域有名的开源网络库，特点是高性能和高扩展性，因此很多流行的框架都是基于它来构建的，比如我们熟知的Dubbo、Rocketmq、Hadoop等。
通过前面 NIO 的学习可以看到，NIO 的类库和API 繁杂，例如 Selector、 ServerSocketChannel、 SocketChannel、 ByteBuffer等这些对于从事应用层的程序员来说，使用起来开发工作量和难度都非常大。另外客户端面临断连重连、网络闪断、心跳处理、半包读写、网络拥塞和异常流的处理等等。
Netty 对 JDK 自带的 NIO 的 API 进行了良好的封装，解决了上述问题。且Netty拥有高性能、吞吐量更高，延迟更低，减少资源消耗，最小化不必要的内存复制等优点。

Netty 现在都在用的是4.x，5.x版本已经废弃，Netty 4.x 需要JDK 6以上版本支持。

在了解Netty使用场景后，本节将从IO模型的演进角度来分析Netty线程模型，通过并发编程之父Doug Lea所写《Scalable IO in Java》中涉及的一些IO处理模式，一步一步深入理解Netty线程模型的“进化历史” 。

《Scalable IO in Java》：
http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

Netty使用场景

互联网行业：在分布式系统中，各个节点之间需要远程服务调用，高性能的 RPC 框架必不可少，Netty 作为异步高性能的通信框架，往往作为基础通信组件被这些 RPC 框架使用。典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 使用 Dubbo 协议进行通信，Dubbo 协议默认使用 Netty 作为基础通信组件，用于实现各进程节点之间的内部通信；消息中间件Rocketmq底层也是用的Netty作为基础通信组件。
游戏行业：无论是手游服务端还是大型的网络游戏,Java 语言都得到了越来越广泛的应用。Netty 作为高性能的基础通信组件,它本身提供了 TCP/UDP 和 HTTP 协议栈。
大数据领域：经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架,默认采用 Netty 进行跨节点通信,它的 Netty Service 是基于 Netty 框架二次封装实现。

Netty相关开源项目：
https://netty.io/wiki/related-projects.html

IO处理模式演进基本上所有的网络处理程序都遵循以下基本的处理（handler）流程:

Read request （接收二进制数据）
Decode request （解码为可读数据）
Process service （对数据进行处理产生结果）
Encode reply （将结果编码为二进制数据）
Send reply （返回结果）

传统网络服务器会为每一个连接的处理开启一个新的线程，即我们前面所说的BIO模型（多线程模式），我们可以看下大致的示意图：

文章插图

上图为 BIO版本

BIO模型对于每一个请求都分发给一个线程（可以理解为一个handler），每个handler中都独自处理上面1-5流程。这种模型的适用场景和瓶颈可以查看《BIO 、NIO 、AIO 总结》。
改进：采用基于事件驱动的设计，当有事件触发时，才会调用处理器进行数据处理（非阻塞）。这就是对应的NIO线程模型。