【Netty】特性分析及核心组件介绍

NIO 的类库和 API 繁杂， 使用麻烦，需要熟练掌握 Selector、 ServerSocketChannel、 SocketChannel、 ByteBuffer等。 并且开发工作量和难度都非常大，例如客户端面临断连重连、 网络闪断、心跳处理、半包读写、 网络拥塞和异常流的处理等等。Netty 对 JDK 自带的 NIO 的 API 进行了良好的封装，解决了上述问题。

按照定义来说，Netty 是一个异步、事件驱动的用来做高性能、高可靠性的网络应用框架。主要的优点有：

1. 框架设计优雅，底层模型随意切换适应不同的网络协议要求。
2. 提供很多标准的协议、安全、编码解码的支持。
3. 解决了很多NIO 不易用的问题。
4. 社区更为活跃，在很多开源框架中使用，如Dubbo、RocketMQ、Spark等。

并且 Netty 拥有高性能、 吞吐量更高，延迟更低，减少资源消耗，最小化不必要的内存复制等优点。

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

Netty采用NIO而非AIO的理由

1. Netty 不看重Windows 上的使用，在Linux 系统上，AIO 的底层实现仍使用EPOLL，没有很好实现AIO，因此在性能上没有明显的优势，而且被JDK 封装了一层不容易深度优化
2. Netty整体架构是reactor模型, 而AIO是proactor模型, 混合在一起会非常混乱,把AIO也改造成reactor模型看起来是把epoll 绕个弯又绕回来
3. AIO还有个缺点是接收数据需要预先分配缓存, 而不是NIO那种需要接收时才需要分配缓存, 所以对连接数量非常大但流量小的情况, 内存浪费很多
4. Linux 上 AIO 不够成熟，处理回调结果速度跟不到处理需求，比如外卖员太少，顾客太多，供不应求，造成处理速度有瓶颈（待验证）

Netty的使用场景

1）互联网行业

在分布式系统中，各个节点之间需要远程服务调用，高性能的 RPC 框架必不可少， Netty 作为异步高性能的通信框架，往往作为基础通信组件被这些 RPC 框架使用。

典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信，Dubbo 协议默认使用 Netty 作为基础通信组件，用于实现。各进程节点之间的内部通信。Rocketmq底层也是用的Netty作 为基础通信组件。

2）游戏行业

无论是手游服务端还是大型的网络游戏，Java 语言得到了越来越广泛的应用。Netty 作为高性能的基础通信组件，它本身提供了 TCP/UDP 和 HTTP 协议栈。

3）大数据领域

经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架，默认采用 Netty 进行跨界点通信，它的 Netty Service 基于 Netty 框架二次封装实现。

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

Netty线程模型

可以先理解下《Scalable IO in Java》这篇文章里说的一些IO处理模式，Netty的线程模型如下图所示：

1）Netty 抽象出两组线程池 BossGroup 和 WorkerGroup，BossGroup 专门负责接收客户端的连接, WorkerGroup 专门负责网络的读写

2）BossGroup 和 WorkerGroup 类型都是 NioEventLoopGroup

3）NioEventLoopGroup 相当于一个事件循环线程组，这个组中含有多个事件循环线程，每一个事件循环线程是 NioEventLoop

4）每个 NioEventLoop 都有一个 selector , 用于监听注册在其上的 socketChannel 的网络通讯

5）每个 Boss NioEventLoop 线程内部循环执行的步骤有 3 步：

1. 处理 accept 事件 , 与 client 建立连接 , 生成 NioSocketChannel
2. 将 NioSocketChannel 注册到某个 worker NIOEventLoop 上的 selector
3. 处理任务队列的任务， 即 runAllTasks

6）每个 worker NIOEventLoop 线程循环执行的步骤：

1. 轮询注册到自己 selector上的所有 NioSocketChannel 的 read, write 事件
2. 处理 I/O 事件， 即 read , write 事件， 在对应 NioSocketChannel 处理业务
3. runAllTasks 处理任务队列 TaskQueue 的任务，一些耗时的业务处理一般可以放入 TaskQueue 中慢慢处理，这样不影响数据在 pipeline 中的流动处理

7）每个 worker NIOEventLoop 处理 NioSocketChannel 业务时，会使用 pipeline (管道)，管道中维护了很多 handler 处理器用来处理 channel 中的数据

Netty模块组件

【Bootstrap、ServerBootstrap】

Bootstrap 意思是引导，一个 Netty 应用通常由一个 Bootstrap 开始，主要作用是配置整个 Netty 程序，串联各个组件，Netty 中 Bootstrap 类是客户端程序的启动引导类，ServerBootstrap 是服务端启动引导类。

【Future、ChannelFuture】

正如前面介绍，在 Netty 中所有的 IO 操作都是异步的，不能立刻得知消息是否被正确处理。 但是可以过一会等它执行完成或者直接注册一个监听，具体的实现就是通过 Future 和 ChannelFutures，他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件。

【Channel】

Netty 网络通信的组件，能够用于执行网络 I/O 操作。Channel 为用户提供：

1. 当前网络连接的通道的状态（例如是否打开？是否已连接？）
2. 网络连接的配置参数 （例如接收缓冲区大小）
3. 提供异步的网络 I/O 操作(如建立连接，读写，绑定端口)，异步调用意味着任何 I/O 调用都将立即 返回，并且不保证在调用结束时所请求的 I/O 操作已完成
4. 调用立即返回一个 ChannelFuture 实例，通过注册监听器到 ChannelFuture 上，可以 I/O 操作成 功、失败或取消时回调通知调用方
5. 支持关联 I/O 操作与对应的处理程序

不同协议、不同的阻塞类型的连接都有不同的 Channel 类型与之对应。 下面是一些常用的 Channel 类型：

NioSocketChannel --异步的客户端 TCP Socket 连接
NioServerSocketChannel --异步的服务器端 TCP Socket 连接
NioDatagramChannel --异步的 UDP 连接
NioSctpChannel --异步的客户端 Sctp 连接 
NioSctpServerChannel --异步的 Sctp 服务器端连接，

这些通道涵盖了 UDP 和 TCP 网络 IO 以及文 件 IO

【Selector】

Netty 基于 Selector 对象实现 I/O 多路复用，通过 Selector 一个线程可以监听多个连接的 Channel 事件。

当向一个 Selector 中注册 Channel 后，Selector 内部的机制就可以自动不断地查询(Select) 这些注册的 Channel 是否有已就绪的 I/O 事件（例如可读，可写，网络连接完成等），这样程序就可以很简单地使用一个线程高效地管理多个 Channel 。

【NioEventLoop】

NioEventLoop 中维护了一个线程和任务队列，支持异步提交执行任务，线程启动时会调用 NioEventLoop 的 run 方法，执行 I/O 任务和非 I/O 任务：

• I/O 任务，即 selectionKey 中 ready 的事件，如 accept、connect、read、write 等，由 processSelectedKeys 方法触发。
• 非 IO 任务，添加到 taskQueue 中的任务，如 register0、bind0 等任务，由 runAllTasks 方法触发。

【NioEventLoopGroup】

NioEventLoopGroup，主要管理 eventLoop 的生命周期，可以理解为一个线程池，内部维护了一组线程，每个线程(NioEventLoop)负责处理多个 Channel 上的事件，而一个 Channel 只对应于一个线程。

【ChannelHandler】

ChannelHandler 是一个接口，处理 I/O 事件或拦截 I/O 操作，并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。

ChannelHandler 本身并没有提供很多方法，因为这个接口有许多的方法需要实现，方便使用期间， 可以继承它的子类

ChannelInboundHandler --用于处理入站 I/O 事件
ChannelOutboundHandler --用于处理出站 I/O 操作

或者使用以下适配器类：

ChannelInboundHandlerAdapter --用于处理入站 I/O 事件
ChannelOutboundHandlerAdapter --用于处理出站 I/O 操作

【ChannelHandlerContext】

保存 Channel 相关的所有上下文信息，同时关联一个 ChannelHandler 对象。

【ChannelPipline】

保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站操作。 ChannelPipeline 实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互。

在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应，它们的组成关系如下：

一个 Channel 包含了一个 ChannelPipeline，而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler。

read事件(入站事件)和write事件(出站事件)在一个双向链表中，入站事件会从链表 head 往后传递到最 后一个入站的 handler，出站事件会从链表 tail 往前传递到最前一个出站的 handler，两种类型的 handler 互不干扰。