关于netty:这可能是目前最透彻的Netty原理架构解析

本文基于 Netty 4.1 开展介绍相干实践模型，应用场景，根本组件、整体架构，知其然且知其所以然，心愿给大家在理论开发实际、学习开源我的项目方面提供参考。

Netty 是一个异步事件驱动的网络应用程序框架，用于疾速开发可保护的高性能协定服务器和客户端。

JDK 原生 NIO 程序的问题

JDK 原生也有一套网络应用程序 API，然而存在一系列问题，次要如下：

• NIO 的类库和 API 繁冗，应用麻烦。你须要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
• 须要具备其余的额定技能做铺垫。例如相熟 Java 多线程编程，因为 NIO 编程波及到 Reactor 模式，你必须对多线程和网路编程十分相熟，能力编写出高质量的 NIO 程序。
• 可靠性能力不齐，开发工作量和难度都十分大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异样码流的解决等等。NIO 编程的特点是性能开发绝对容易，然而可靠性能力补齐工作量和难度都十分大。
• JDK NIO 的 Bug。例如臭名远扬的 Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%。官网宣称在 JDK 1.6 版本的 update 18 修复了该问题，然而直到 JDK 1.7 版本该问题仍旧存在，只不过该 Bug 产生概率升高了一些而已，它并没有被基本解决。

Netty 的特点

Netty 对 JDK 自带的 NIO 的 API 进行封装，解决上述问题，次要特点有：

• 设计优雅，实用于各种传输类型的对立 API 阻塞和非阻塞 Socket；基于灵便且可扩大的事件模型，能够清晰地拆散关注点；高度可定制的线程模型 – 单线程，一个或多个线程池；真正的无连贯数据报套接字反对（自 3.1 起）。
• 使用方便，具体记录的 Javadoc，用户指南和示例；没有其余依赖项，JDK 5（Netty 3.x）或 6（Netty 4.x）就足够了。
• 高性能，吞吐量更高，提早更低；缩小资源耗费；最小化不必要的内存复制。
• 平安，残缺的 SSL/TLS 和 StartTLS 反对。
• 社区沉闷，不断更新，社区沉闷，版本迭代周期短，发现的 Bug 能够被及时修复，同时，更多的新性能会被退出。

Netty 常见应用场景

Netty 常见的应用场景如下：

• 互联网行业。在分布式系统中，各个节点之间须要近程服务调用，高性能的 RPC 框架必不可少，Netty 作为一步高性能的通信框架，往往作为根底通信组件被这些 RPC 框架应用。典型的利用有：阿里分布式服务框架 Dubbo 的 RPC 框架应用 Dubbo 协定进行节点间通信，Dubbo 协定默认应用 Netty 作为根底通信组件，用于实现各过程节点之间的外部通信。
• 游戏行业。无论是手游服务端还是大型的网络游戏，Java 语言失去了越来越宽泛的利用。Netty 作为高性能的根底通信组件，它自身提供了 TCP/UDP 和 HTTP 协定栈。十分不便定制和开发公有协定栈，账号登录服务器，地图服务器之间能够不便的通过 Netty 进行高性能的通信。
• 大数据畛域。经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架，默认采纳 Netty 进行跨界点通信，它的 Netty Service 基于 Netty 框架二次封装实现。

有趣味的读者能够理解一下目前有哪些开源我的项目应用了 Netty：Related Projects。

Netty 高性能设计

Netty 作为异步事件驱动的网络，高性能之处次要来自于其 I/O 模型和线程解决模型，前者决定如何收发数据，后者决定如何解决数据。

I/O 模型

用什么样的通道将数据发送给对方，BIO、NIO 或者 AIO，I/O 模型在很大水平上决定了框架的性能。

阻塞 I/O

传统阻塞型 I/O(BIO)能够用下图示意：

Blocking I/O

特点如下：

• 每个申请都须要独立的线程实现数据 Read，业务解决，数据 Write 的残缺操作问题。
• 当并发数较大时，须要创立大量线程来解决连贯，系统资源占用较大。
• 连贯建设后，如果以后线程临时没有数据可读，则线程就阻塞在 Read 操作上，造成线程资源节约。

I/O 复用模型

在 I/O 复用模型中，会用到 Select，这个函数也会使过程阻塞，然而和阻塞 I/O 所不同的是这两个函数能够同时阻塞多个 I/O 操作。

而且能够同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。

Netty 的非阻塞 I/O 的实现要害是基于 I/O 复用模型，这里用 Selector 对象示意：

Nonblocking I/O

Netty 的 IO 线程 NioEventLoop 因为聚合了多路复用器 Selector，能够同时并发解决成千盈百个客户端连贯。

当线程从某客户端 Socket 通道进行读写数据时，若没有数据可用时，该线程能够进行其余工作。

线程通常将非阻塞 IO 的闲暇工夫用于在其余通道上执行 IO 操作，所以独自的线程能够治理多个输出和输入通道。

因为读写操作都是非阻塞的，这就能够充沛晋升 IO 线程的运行效率，防止因为频繁 I/O 阻塞导致的线程挂起。

一个 I/O 线程能够并发解决 N 个客户端连贯和读写操作，这从根本上解决了传统同步阻塞 I/O 一连贯一线程模型，架构的性能、弹性伸缩能力和可靠性都失去了极大的晋升。

基于 Buffer

传统的 I/O 是面向字节流或字符流的，以流式的形式程序地从一个 Stream 中读取一个或多个字节, 因而也就不能随便扭转读取指针的地位。

在 NIO 中，摈弃了传统的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，只能从 Channel 中读取数据到 Buffer 中或将数据从 Buffer 中写入到 Channel。

基于 Buffer 操作不像传统 IO 的程序操作，NIO 中能够随便地读取任意地位的数据。

线程模型

数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的音讯如何派发，线程模型的不同，对性能的影响也十分大。

事件驱动模型

通常，咱们设计一个事件处理模型的程序有两种思路：

• 轮询形式，线程一直轮询拜访相干事件发生源有没有产生事件，有产生事件就调用事件处理逻辑。
• 事件驱动形式，产生事件，主线程把事件放入事件队列，在另外线程一直循环生产事件列表中的事件，调用事件对应的解决逻辑处理事件。事件驱动形式也被称为音讯告诉形式，其实是设计模式中观察者模式的思路。

以 GUI 的逻辑解决为例，阐明两种逻辑的不同：

• 轮询形式，线程一直轮询是否产生按钮点击事件，如果产生，调用解决逻辑。
• 事件驱动形式，产生点击事件把事件放入事件队列，在另外线程生产的事件列表中的事件，依据事件类型调用相干事件处理逻辑。

这里借用 O’Reilly 大神对于事件驱动模型解释图：

事件驱动模型

次要包含 4 个根本组件：

• 事件队列（event queue）：接管事件的入口，存储待处理事件。
• 散发器（event mediator）：将不同的事件散发到不同的业务逻辑单元。
• 事件通道（event channel）：散发器与处理器之间的分割渠道。
• 事件处理器（event processor）：实现业务逻辑，解决实现后会收回事件，触发下一步操作。

能够看出，绝对传统轮询模式，事件驱动有如下长处：

• 可扩展性好，分布式的异步架构，事件处理器之间高度解耦，能够不便扩大事件处理逻辑。
• 高性能，基于队列暂存事件，能不便并行异步处理事件。

Reactor 线程模型

Reactor 是反应堆的意思，Reactor 模型是指通过一个或多个输出同时传递给服务处理器的服务申请的事件驱动解决模式。

服务端程序处理传入多路申请，并将它们同步分派给申请对应的解决线程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了复用对立监听事件，收到事件后散发(Dispatch 给某过程)，是编写高性能网络服务器的必备技术之一。

Reactor 模型中有 2 个要害组成：

• Reactor，Reactor 在一个独自的线程中运行，负责监听和散发事件，分发给适当的处理程序来对 IO 事件做出反馈。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人。
• Handlers，处理程序执行 I/O 事件要实现的理论事件，相似于客户想要与之交谈的公司中的理论官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

Reactor 模型

取决于 Reactor 的数量和 Hanndler 线程数量的不同，Reactor 模型有 3 个变种：

• 单 Reactor 单线程。
• 单 Reactor 多线程。
• 主从 Reactor 多线程。

能够这样立刻，Reactor 就是一个执行 while (true) {selector.select(); …} 循环的线程，会源源不断的产生新的事件，称作反应堆很贴切。

篇幅关系，这里不再具体开展 Reactor 个性、优缺点比拟，有趣味的读者能够参考我之前另外一篇文章：《了解高性能网络模型》。

Netty 线程模型

Netty 次要基于主从 Reactors 多线程模型（如下图）做了肯定的批改，其中主从 Reactor 多线程模型有多个 Reactor：

• MainReactor 负责客户端的连贯申请，并将申请转交给 SubReactor。
• SubReactor 负责相应通道的 IO 读写申请。
• 非 IO 申请（具体逻辑解决）的工作则会间接写入队列，期待 worker threads 进行解决。

这里援用 Doug Lee 大神的 Reactor 介绍：Scalable IO in Java 外面对于主从 Reactor 多线程模型的图：

主从 Rreactor 多线程模型

特地阐明的是：尽管 Netty 的线程模型基于主从 Reactor 多线程，借用了 MainReactor 和 SubReactor 的构造。然而理论实现上 SubReactor 和 Worker 线程在同一个线程池中：

EventLoopGroup bossGroup = newNioEventLoopGroup();

EventLoopGroup workerGroup = newNioEventLoopGroup();

ServerBootstrap server= newServerBootstrap();

server.group(bossGroup, workerGroup)

.channel(NioServerSocketChannel. class)

下面代码中的 bossGroup 和 workerGroup 是 Bootstrap 构造方法中传入的两个对象，这两个 group 均是线程池：

• bossGroup 线程池则只是在 Bind 某个端口后，取得其中一个线程作为 MainReactor，专门解决端口的 Accept 事件，每个端口对应一个 Boss 线程。
• workerGroup 线程池会被各个 SubReactor 和 Worker 线程充分利用。

异步解决

异步的概念和同步绝对。当一个异步过程调用收回后，调用者不能立即失去后果。理论解决这个调用的部件在实现后，通过状态、告诉和回调来告诉调用者。

Netty 中的 I/O 操作是异步的，包含 Bind、Write、Connect 等操作会简略的返回一个 ChannelFuture。

调用者并不能立即取得后果，而是通过 Future-Listener 机制，用户能够不便的被动获取或者通过告诉机制取得 IO 操作后果。

当 Future 对象刚刚创立时，处于非实现状态，调用者能够通过返回的 ChannelFuture 来获取操作执行的状态，注册监听函数来执行实现后的操作。

常见有如下操作：

• 通过 isDone 办法来判断以后操作是否实现。
• 通过 isSuccess 办法来判断已实现的以后操作是否胜利。
• 通过 getCause 办法来获取已实现的以后操作失败的起因。
• 通过 isCancelled 办法来判断已实现的以后操作是否被勾销。
• 通过 addListener 办法来注册监听器，当操作已实现(isDone 办法返回实现)，将会告诉指定的监听器；如果 Future 对象已实现，则了解告诉指定的监听器。

例如上面的代码中绑定端口是异步操作，当绑定操作解决完，将会调用相应的监听器解决逻辑。

serverBootstrap.bind(port).addListener(future -> {

if(future.isSuccess()) {

System.out. println(newDate() + “: 端口 [“+ port + “] 绑定胜利!”);

} else{

System.err. println(“ 端口 [“+ port + “] 绑定失败!”);

}

});

相比传统阻塞 I/O，执行 I/O 操作后线程会被阻塞住, 直到操作实现；异步解决的益处是不会造成线程阻塞，线程在 I/O 操作期间能够执行别的程序，在高并发情景下会更稳固和更高的吞吐量。

Netty 架构设计

后面介绍完 Netty 相干一些实践，上面从性能个性、模块组件、运作过程来介绍 Netty 的架构设计。

性能个性

Netty 性能个性如下：

• 传输服务，反对 BIO 和 NIO。
• 容器集成，反对 OSGI、JBossMC、Spring、Guice 容器。
• 协定反对，HTTP、Protobuf、二进制、文本、WebSocket 等一系列常见协定都反对。还反对通过履行编码解码逻辑来实现自定义协定。
• Core 外围，可扩大事件模型、通用通信 API、反对零拷贝的 ByteBuf 缓冲对象。

模块组件

Bootstrap、ServerBootstrap

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

Future、ChannelFuture

正如后面介绍，在 Netty 中所有的 IO 操作都是异步的，不能立即得悉音讯是否被正确处理。

然而能够过一会等它执行实现或者间接注册一个监听，具体的实现就是通过 Future 和 ChannelFutures，他们能够注册一个监听，当操作执行胜利或失败时监听会主动触发注册的监听事件。

Channel

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

• 以后网络连接的通道的状态（例如是否关上？是否已连贯？）
• 网络连接的配置参数（例如接收缓冲区大小）
• 提供异步的网络 I/O 操作(如建设连贯，读写，绑定端口)，异步调用意味着任何 I/O 调用都将立刻返回，并且不保障在调用完结时所申请的 I/O 操作已实现。调用立刻返回一个 ChannelFuture 实例，通过注册监听器到 ChannelFuture 上，能够 I/O 操作胜利、失败或勾销时回调告诉调用方。
• 反对关联 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 办法触发。

两种工作的执行工夫必有变量 ioRatio 管制，默认为 50，则示意容许非 IO 工作执行的工夫与 IO 工作的执行工夫相等。

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 操作。
• ChannelDuplexHandler 用于解决入站和出站事件。

ChannelHandlerContext

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

ChannelPipline

保留 ChannelHandler 的 List，用于解决或拦挡 Channel 的入站事件和出站操作。

ChannelPipeline 实现了一种高级模式的拦挡过滤器模式，使用户能够齐全管制事件的解决形式，以及 Channel 中各个的 ChannelHandler 如何互相交互。

下图援用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的阐明，形容了 ChannelPipeline 中 ChannelHandler 通常如何解决 I/O 事件。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 解决，并通过调用 ChannelHandlerContext 中定义的事件流传办法。

例如 ChannelHandlerContext.fireChannelRead（Object）和 ChannelOutboundInvoker.write（Object）转发到其最近的处理程序。

入站事件由自下而上方向的入站处理程序解决，如图左侧所示。入站 Handler 处理程序通常解决右图底部的 I/O 线程生成的入站数据。

通常通过理论输出操作（例如 SocketChannel.read（ByteBuffer））从近程读取入站数据。

出站事件由高低方向解决，如图右侧所示。出站 Handler 处理程序通常会生成或转换出站传输，例如 write 申请。

I/O 线程通常执行理论的输入操作，例如 SocketChannel.write（ByteBuffer）。

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

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

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

Netty 工作原理架构

初始化并启动 Netty 服务端过程如下：

publicstaticvoidmain(String[] args) {

// 创立 mainReactor

NioEventLoopGroup boosGroup = newNioEventLoopGroup();

// 创立工作线程组

NioEventLoopGroup workerGroup = newNioEventLoopGroup();

final ServerBootstrap serverBootstrap = newServerBootstrap();

serverBootstrap

// 组装 NioEventLoopGroup

. group(boosGroup, workerGroup)

// 设置 channel 类型为 NIO 类型

.channel(NioServerSocketChannel.class)

// 设置连贯配置参数

.option(ChannelOption.SO_BACKLOG, 1024)

.childOption(ChannelOption.SO_KEEPALIVE, true)

.childOption(ChannelOption.TCP_NODELAY, true)

// 配置入站、出站事件 handler

.childHandler(newChannelInitializer<NioSocketChannel>() {

@ Override

protectedvoidinitChannel(NioSocketChannel ch) {

// 配置入站、出站事件 channel

ch.pipeline().addLast(…);

ch.pipeline().addLast(…);

}

});

// 绑定端口

intport = 8080;

serverBootstrap.bind(port).addListener(future -> {

if(future.isSuccess()) {

System. out.println(newDate() + “: 端口 [“+ port + “] 绑定胜利!”);

} else{

System.err.println(“ 端口 [“+ port + “] 绑定失败!”);

}

});

}

根本过程如下：

• 初始化创立 2 个 NioEventLoopGroup，其中 boosGroup 用于 Accetpt 连贯建设事件并散发申请，workerGroup 用于解决 I/O 读写事件和业务逻辑。
• 基于 ServerBootstrap(服务端启动疏导类)，配置 EventLoopGroup、Channel 类型，连贯参数、配置入站、出站事件 handler。
• 绑定端口，开始工作。

联合下面介绍的 Netty Reactor 模型，介绍服务端 Netty 的工作架构图：

服务端 Netty Reactor 工作架构图

Server 端蕴含 1 个 Boss NioEventLoopGroup 和 1 个 Worker NioEventLoopGroup。

NioEventLoopGroup 相当于 1 个事件循环组，这个组里蕴含多个事件循环 NioEventLoop，每个 NioEventLoop 蕴含 1 个 Selector 和 1 个事件循环线程。

每个 Boss NioEventLoop 循环执行的工作蕴含 3 步：

• 轮询 Accept 事件。
• 解决 Accept I/O 事件，与 Client 建设连贯，生成 NioSocketChannel，并将 NioSocketChannel 注册到某个 Worker NioEventLoop 的 Selector 上。
• 解决工作队列中的工作，runAllTasks。工作队列中的工作包含用户调用 eventloop.execute 或 schedule 执行的工作，或者其余线程提交到该 eventloop 的工作。

每个 Worker NioEventLoop 循环执行的工作蕴含 3 步：

• 轮询 Read、Write 事件。
• 解决 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可读、可写事件产生时进行解决。
• 解决工作队列中的工作，runAllTasks。

其中工作队列中的 Task 有 3 种典型应用场景。

①用户程序自定义的一般工作

ctx.channel().eventLoop().execute(newRunnable() {

@Override

publicvoidrun(){

//…

}

});

②非以后 Reactor 线程调用 Channel 的各种办法

例如在推送零碎的业务线程外面，依据用户的标识，找到对应的 Channel 援用，而后调用 Write 类办法向该用户推送音讯，就会进入到这种场景。最终的 Write 会提交到工作队列中后被异步生产。

③用户自定义定时工作

ctx.channel().eventLoop().schedule(newRunnable() {

@Override

publicvoidrun(){

}

}, 60, TimeUnit.SECONDS);

总结

当初稳固举荐应用的支流版本还是 Netty4，Netty5 中应用了 ForkJoinPool，减少了代码的复杂度，然而对性能的改善却不显著，所以这个版本不举荐应用，官网也没有提供下载链接。

Netty 入门门槛绝对较高，是因为这方面的材料较少，并不是因为它有多难，大家其实都能够像搞透 Spring 一样搞透 Netty。

在学习之前，倡议先了解透整个框架原理构造，运行过程，能够少走很多弯路。
如果感觉本文对你有帮忙能够点赞关注我反对一下