【Netty】从 BIO、NIO 聊到 Netty
为了让你更好地了解 Netty 以及它诞生的原因,先从传统的网络编程说起吧!
# 还是要从 BIO 说起
# 传统的阻塞式通信流程
早期的 Java 网络相关的 API(java.net
包) 使用 Socket(套接字)进行网络通信,不过只支持阻塞函数使用。
要通过互联网进行通信,至少需要一对套接字:
- 运行于服务器端的 Server Socket。
- 运行于客户机端的 Client Socket
Socket 网络通信过程如下图所示:
【参考】https://www.javatpoint.com/socket-programming (opens new window)
Socket 网络通信过程简单来说分为下面 4 步:
- 建立服务端并且监听客户端请求
- 客户端请求,服务端和客户端建立连接
- 两端之间可以传递数据
- 关闭资源
对应到服务端和客户端的话,是下面这样的。
服务器端:
- 创建
ServerSocket
对象并且绑定地址(ip)和端口号(port):server.bind(new InetSocketAddress(host, port))
- 通过
accept()
方法监听客户端请求 - 连接建立后,通过输入流读取客户端发送的请求信息
- 通过输出流向客户端发送响应信息
- 关闭相关资源
客户端:
- 创建
Socket
对象并且连接指定的服务器的地址(ip)和端口号(port):socket.connect(inetSocketAddress)
- 连接建立后,通过输出流向服务器端发送请求信息
- 通过输入流获取服务器响应的信息
- 关闭相关资源
# 一个简单的 demo
为了便于理解,我写了一个简单的代码帮助各位小伙伴理解。
服务端:
public class HelloServer {
private static final Logger logger = LoggerFactory.getLogger(HelloServer.class);
public void start(int port) {
//1.创建 ServerSocket 对象并且绑定一个端口
try (ServerSocket server = new ServerSocket(port);) {
Socket socket;
//2.通过 accept()方法监听客户端请求, 这个方法会一直阻塞到有一个连接建立
while ((socket = server.accept()) != null) {
logger.info("client connected");
try (ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream())) {
//3.通过输入流读取客户端发送的请求信息
Message message = (Message) objectInputStream.readObject();
logger.info("server receive message:" + message.getContent());
message.setContent("new content");
//4.通过输出流向客户端发送响应信息
objectOutputStream.writeObject(message);
objectOutputStream.flush();
} catch (IOException | ClassNotFoundException e) {
logger.error("occur exception:", e);
}
}
} catch (IOException e) {
logger.error("occur IOException:", e);
}
}
public static void main(String[] args) {
HelloServer helloServer = new HelloServer();
helloServer.start(6666);
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
ServerSocket
的 accept()
方法是阻塞方法,也就是说 ServerSocket
在调用 accept()
等待客户端的连接请求时会阻塞,直到收到客户端发送的连接请求才会继续往下执行代码,因此我们需要要为每个 Socket 连接开启一个线程(可以通过线程池来做)。
上述服务端的代码只是为了演示,并没有考虑多个客户端连接并发的情况。
客户端:
public class HelloClient {
private static final Logger logger = LoggerFactory.getLogger(HelloClient.class);
public Object send(Message message, String host, int port) {
//1. 创建Socket对象并且指定服务器的地址和端口号
try (Socket socket = new Socket(host, port)) {
ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream());
//2.通过输出流向服务器端发送请求信息
objectOutputStream.writeObject(message);
//3.通过输入流获取服务器响应的信息
ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
return objectInputStream.readObject();
} catch (IOException | ClassNotFoundException e) {
logger.error("occur exception:", e);
}
return null;
}
public static void main(String[] args) {
HelloClient helloClient = new HelloClient();
Message message =
(Message) helloClient.send(new Message("content from client"), "127.0.0.1", 6666);
System.out.println("client receive message:" + message.getContent());
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
发送的消息实体类:
@Data
@AllArgsConstructor
public class Message implements Serializable {
private String content;
}
2
3
4
5
6
首先运行服务端,然后再运行客户端,控制台输出如下:
服务端:
[main] INFO github.javaguide.socket.HelloServer - client connected
[main] INFO github.javaguide.socket.HelloServer - server receive message:content from client
2
客户端:
client receive message:new content
# 资源消耗严重的问题
很明显,我上面演示的代码片段有一个很严重的问题:只能同时处理一个客户端的连接,如果需要管理多个客户端的话,就需要为我们请求的客户端单独创建一个线程。 如下图所示:
对应的 Java 代码可能是下面这样的:
new Thread(() -> {
// 创建 socket 连接
}).start();
2
3
但是,这样会导致一个很严重的问题:资源浪费。
我们知道线程是很宝贵的资源,如果我们为每一次连接都用一个线程处理的话,就会导致线程越来越好,最好达到了极限之后,就无法再创建线程处理请求了。处理的不好的话,甚至可能直接就宕机掉了。
很多人就会问了:那有没有改进的方法呢?
# 线程池虽可以改善,但终究未从根本解决问题
当然有! 比较简单并且实际的改进方法就是使用线程池。线程池还可以让线程的创建和回收成本相对较低,并且我们可以指定线程池的可创建线程的最大数量,这样就不会导致线程创建过多,机器资源被不合理消耗。
ThreadFactory threadFactory = Executors.defaultThreadFactory();
ExecutorService threadPool = new ThreadPoolExecutor(10, 100, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<>(100), threadFactory);
threadPool.execute(() -> {
// 创建 socket 连接
});
2
3
4
5
但是,即使你再怎么优化和改变。也改变不了它的底层仍然是同步阻塞的 BIO 模型的事实,因此无法从根本上解决问题。
为了解决上述的问题,Java 1.4 中引入了 NIO ,一种同步非阻塞的 I/O 模型。
# 再看 NIO
Netty 实际上就基于 Java NIO 技术封装完善之后得到一个高性能框架,熟悉 NIO 的基本概念对于学习和更好地理解 Netty 还是很有必要的!
# 初识 NIO
NIO 是一种同步非阻塞的 I/O 模型,在 Java 1.4 中引入了 NIO 框架,对应 java.nio
包,提供了 Channel , Selector,Buffer 等抽象。
NIO 中的 N 可以理解为 Non-blocking,已经不在是 New 了(已经出来很长时间了)。
NIO 支持面向缓冲(Buffer)的,基于通道(Channel)的 I/O 操作方法。
NIO 提供了与传统 BIO 模型中的 Socket
和 ServerSocket
相对应的 SocketChannel
和 ServerSocketChannel
两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式:
- 阻塞模式 : 基本不会被使用到。使用起来就像传统的网络编程一样,比较简单,但是性能和可靠性都不好。对于低负载、低并发的应用程序,勉强可以用一下以提升开发速率和更好的维护性
- 非阻塞模式 : 与阻塞模式正好相反,非阻塞模式对于高负载、高并发的(网络)应用来说非常友好,但是编程麻烦,这个是大部分人诟病的地方。所以, 也就导致了 Netty 的诞生。
# NIO 核心组件解读
NIO 包含下面几个核心的组件:
- Channel
- Buffer
- Selector
- Selection Key
这些组件之间的关系是怎么的呢?
【参考】http://sergiomartinrubio.com/articles/java-socket-io-and-nio (opens new window)
- NIO 使用 Channel(通道)和 Buffer(缓冲区)传输数据,数据总是从缓冲区写入通道,并从通道读取到缓冲区。在面向流的 I/O 中,可以将数据直接写入或者将数据直接读到 Stream 对象中。在 NIO 库中,所有数据都是通过 Buffer(缓冲区)处理的。 Channel 可以看作是 Netty 的网络操作抽象类,对应于 JDK 底层的 Socket
- NIO 利用 Selector (选择器)来监视多个通道的对象,如数据到达,连接打开等。因此,单线程可以监视多个通道中的数据。
- 当我们将 Channel 注册到 Selector 中的时候, 会返回一个 Selection Key 对象, Selection Key 则表示了一个特定的通道对象和一个特定的选择器对象之间的注册关系。通过 Selection Key 我们可以获取哪些 IO 事件已经就绪了,并且可以通过其获取 Channel 并对其进行操作。
Selector(选择器,也可以理解为多路复用器)是 NIO(非阻塞 IO)实现的关键。它使用了事件通知相关的 API 来实现选择已经就绪也就是能够进行 I/O 相关的操作的任务的能力。
简单来说,整个过程是这样的:
- 将 Channel 注册到 Selector 中。
- 调用 Selector 的
select()
方法,这个方法会阻塞; - 到注册在 Selector 中的某个 Channel 有新的 TCP 连接或者可读写事件的话,这个 Channel 就会处于就绪状态,会被 Selector 轮询出来。
- 然后通过 SelectionKey 可以获取就绪 Channel 的集合,进行后续的 I/O 操作。
# NIO 为啥更好?
相比于传统的 BIO 模型来说, NIO 模型的最大改进是:
- 使用比较少的线程便可以管理多个客户端的连接,提高了并发量并且减少的资源消耗(减少了线程的上下文切换的开销)
- 在没有 I/O 操作相关的事情的时候,线程可以被安排在其他任务上面,以让线程资源得到充分利用。
# 使用 NIO 编写代码太难了
一个使用 NIO 编写的 Server 端如下,可以看出还是整体还是比较复杂的,并且代码读起来不是很直观,并且还可能由于 NIO 本身会存在 Bug。
很少使用 NIO,很大情况下也是因为使用 NIO 来创建正确并且安全的应用程序的开发成本和维护成本都比较大。所以,一般情况下我们都会使用 Netty 这个比较成熟的高性能框架来做(Apace Mina 与之类似,但是 Netty 使用的更多一点)。
# 重要角色 Netty 登场
简单用 3 点概括一下 Netty 吧!
- Netty 是一个基于 NIO 的 client-server(客户端服务器)框架,使用它可以快速简单地开发网络应用程序。
- 它极大地简化并简化了 TCP 和 UDP 套接字服务器等网络编程,并且性能以及安全性等很多方面甚至都要更好。
- 支持多种协议如 FTP,SMTP,HTTP 以及各种二进制和基于文本的传统协议。
用官方的总结就是:Netty 成功地找到了一种在不妥协可维护性和性能的情况下实现易于开发,性能,稳定性和灵活性的方法。
# Netty 特点
根据官网的描述,我们可以总结出下面一些特点:
- 统一的 API,支持多种传输类型,阻塞和非阻塞的。
- 简单而强大的线程模型。
- 自带编解码器解决 TCP 粘包/拆包问题。
- 自带各种协议栈。
- 真正的无连接数据包套接字支持。
- 比直接使用 Java 核心 API 有更高的吞吐量、更低的延迟、更低的资源消耗和更少的内存复制。
- 安全性不错,有完整的 SSL/TLS 以及 StartTLS 支持。
- 社区活跃
- 成熟稳定,经历了大型项目的使用和考验,而且很多开源项目都使用到了 Netty 比如我们经常接触的 Dubbo、RocketMQ 等等。
- ......
# Netty 架构总览
下面是 Netty 的模块设计部分:
Netty 提供了通用的传输 API(TCP/UDP...);
多种网络协议(HTTP/WebSocket...);
基于事件驱动的 IO 模型;
超高性能的零拷贝...
上面说的这些模块和功能只是 Netty 的一部分,具体的组件在后面的部分会有较为详细的介绍。
# 使用 Netty 能做什么?
这个应该是老铁们最关心的一个问题了,凭借自己的了解,简单说一下,理论上 NIO 可以做的事情 ,使用 Netty 都可以做并且更好。Netty 主要用来做网络通信 :
- 作为 RPC 框架的网络通信工具 : 我们在分布式系统中,不同服务节点之间经常需要相互调用,这个时候就需要 RPC 框架了。不同服务指点的通信是如何做的呢?可以使用 Netty 来做。比如我调用另外一个节点的方法的话,至少是要让对方知道我调用的是哪个类中的哪个方法以及相关参数吧!
- 实现一个自己的 HTTP 服务器 :通过 Netty 我们可以自己实现一个简单的 HTTP 服务器,这个大家应该不陌生。说到 HTTP 服务器的话,作为 Java 后端开发,我们一般使用 Tomcat 比较多。一个最基本的 HTTP 服务器可要以处理常见的 HTTP Method 的请求,比如 POST 请求、GET 请求等等。
- 实现一个即时通讯系统 : 使用 Netty 我们可以实现一个可以聊天类似微信的即时通讯系统,这方面的开源项目还蛮多的,可以自行去 Github 找一找。
- 消息推送系统 :市面上有很多消息推送系统都是基于 Netty 来做的。
- ......
# 哪些开源项目用到了 Netty?
我们平常经常接触的 Dubbo、RocketMQ、Elasticsearch、gRPC 等等都用到了 Netty。
可以说大量的开源项目都用到了 Netty,所以掌握 Netty 有助于你更好的使用这些开源项目并且让你有能力对其进行二次开发。
实际上还有很多很多优秀的项目用到了 Netty,Netty 官方也做了统计,统计结果在这里:https://netty.io/wiki/related-projects.html (opens new window) 。
# Netty 学习指南
学习 Netty,相信大部分小伙伴都会选择 《Netty in Action》 和 《Netty 4.x User Guide 》, 这里我推荐它们的通读版本,这二本书的通读版本的作者都为同一人,通读版本对《Netty in Action》做出了更为精简的概述, 所以各位小伙伴可酌情挑选阅读。
其次我认为只看书是不够的,这里我推荐一些关于 Netty 入门比较优秀的视频供各位小伙伴参考, 推荐视频观看的顺序即下列顺序,各位小伙伴不需要每个视频的每个章节都看,只需要挑选互补的内容学习即可:
最后,在学习 Netty 之前,我们需要对 IO 模型(网络 IO 模型)有一个大概的认知。
# Netty 特性
# 强大的数据容器
Netty 使用自建的 Buffer API 实现 ByteBuf,而不是使用 JDK NIO 的 ByteBuffer 来表示一个连续的字节序列。与 JDK NIO 的 ByteBuffer 相比,Netty 的 ByteBuf 有更加明显的优势,这些优势可以弥补 Java 原生 ByteBuffer 的底层缺点,并提供 更加方便的编程模型:
正常情况下,ByteBuf 比 ByteBuffer 的性能更好;
实现了 ReferenceCounted 引用计数接口,优化了内存的使用;
容量可以动态增长,如 StringBuilder 之于 String;
在读和写这两种模式切换时,无需像 ByteBuffer 一样调用 flip 方法,更易于操作;
...
# ByteBuf 的自动容量扩展
在 JDK NIO 中,一旦 ByteBuffer 被分配了内存就不能再改变大小,这可能会带来很多不便。 我们在创建字符串时可能不确定字符串的长度,这种情况下如果使用 String 可能会有多次拼接的消耗, 所以这就是 StringBuilder 的作用,同样的,ByteBuf 也是如此。
// 一种 新的动态缓冲区被创建。在内部,实际缓冲区是被“懒”创建,从而避免潜在的浪费内存空间。
ByteBuf b = Unpooled.buffer(4);
// 当第一个执行写尝试,内部指定初始容量 4 的缓冲区被创建
b.writeByte('1');
b.writeByte('2');
b.writeByte('3');
b.writeByte('4');
// 当写入的字节数超过初始容量 4 时,
//内部缓冲区自动分配具有较大的容量
b.writeByte('5');
2
3
4
5
6
7
8
9
10
11
12
13
# 通用的传输 API
传统的 Java IO 在应对不同的传输协议的时候需要使用不同的 API,比如 java.net.Socket 和 java.net.DatagramSocket。 它们分别是 TCP 和 UDP 的传输 API,因此在使用它们的时候我们就需要学习不同的编程方式。这种编程模式会使得在维护 或修改其对应的程序的时候变得繁琐和困难,简单来说就是降低了代码的可维护性。
这种情况还发生在 Java 的 NIO 和 AIO 上,由于所有的 IO API 无论是性能还是设计上都有所不同,所以注定这些 API 之间是不兼容的, 因此我们不得不在编写程序之前先选好要使用的 IO API。
在 Netty 中,有一个通用的传输 API,也是一个 IO 编程接口: Channel,这个 API 抽象了所有的 IO 模型,如果你的应用 已经使用了 Netty 的某一种传输实现,那么你的无需付出太多代价就能换成另一种传输实现。
Netty 提供了非常多的传输实现,如 nio,oio,epoll,kqueue 等等,通常切换不同的传输实现只需要对几行代码进行 修改就行了,例如选择一个不同的 ChannnelFactory (opens new window), 这也是面向接口编程的一大好处。
# 基于拦截链模式的事件模型
Netty 具有良好的 IO 事件模型,它允许我们在不破坏原有代码结构的情况下实现自己的事件类型。 很多 IO 框架 没有事件模型或者在这方面做的不够好,这也是 Netty 的优秀设计的体现之一。 关于事件模型可以看我编写的: [ChannelHandler]
# 参考
https://blog.csdn.net/agonie201218/category_10790738.html (opens new window)
- 01
- idea 热部署插件 JRebel 安装及破解,不生效问题解决04-10
- 02
- spark中代码的执行位置(Driver or Executer)12-12
- 03
- 大数据技术之 SparkStreaming12-12