[TOC]
Netty
1、Netty的介绍以及应用场景
1、Netty的基本介绍
Netty 是由 JBOSS 提供的一个 Java 开源框架,现为 Github上的独立项目。
Netty 是一个==异步的==、==基于事件驱动==的==网络应用框架==,用以快速开发高性能、高可靠性的网络 IO 程序。
Netty主要针对在==TCP协议==下,==面向Clients端==的高并发应用,或者==Peer-to-Peer场景==下的大量数据持续传输的应用。
Netty本质是一个==NIO框架==,适用于服务器通讯相关的多种应用场景
要透彻理解Netty , 需要先学习 NIO , 这样我们才能阅读 Netty 的源码。
2、Netty的应用场景
1、互联网行业
互联网行业:在分布式系统中,各个节点之间需要远程服务调用,高性能的 RPC 框架必不可少,Netty 作为异步高性能的通信框架,往往作为基础通信组件被这些 RPC 框架使用。
典型的应用有:阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信,Dubbo 协议默认使用 Netty 作为基础通信组件,用于实现各进程节点之间的内部通信
2、游戏行业
- 无论是手游服务端还是大型的网络游戏,Java 语言得到了越来越广泛的应用
- Netty 作为高性能的基础通信组件,提供了 TCP/UDP 和 HTTP 协议栈,方便定制和开发私有协议栈,账号登录服务器
- 地图服务器之间可以方便的通过 Netty 进行高性能的通信
3、大数据领域
经典的 Hadoop 的高性能通信和序列化组件 Avro(实现数据文件共享) 的 RPC 框架,默认采用 Netty 进行跨界点通信
它的 Netty Service 基于 Netty 框架二次封装实现。
4、其它开源项目使用到Netty
网址: https://netty.io/wiki/related-projects.html
3、Netty的学习参考资料
- 《Netty IN Action》
- Netty权威指南
2、Java BIO编程
1、I/O模型
1、I/O模型的基本说明
I/O 模型简单的理解:就是用什么样的通道进行数据的发送和接收,很大程度上决定了程序通信的性能
Java共支持3种网络编程模型/IO模式:
BIO
、NIO
、AIO
Java BIO
: 同步并阻塞(传统阻塞型),服务器实现模式为==一个连接一个线程==,即客户端有连接请求时服务器端就需要启动一个线程进行处理,如果这个连接不做任何事情会造成不必要的线程开销Java NIO
: 同步非阻塞,服务器实现模式为==一个线程处理多个请求(连接)==,即客户端发送的连接请求都会注册到多路复用器上,多路复用器轮询到连接有I/O请求就进行处理Java AIO(NIO.2)
: 异步非阻塞,AIO 引入异步通道的概念,采用了Proactor 模式
,简化了程序编写,有效的请求才启动线程,它的特点是先由操作系统完成后才通知服务端程序启动线程去处理,一般适用于连接数较多且连接时间较长的应用
2、BIO、NIO、AIO适用场景分析
- BIO方式适用于连接数目比较小且固定的架构,这种方式对服务器资源要求比较高,并发局限于应用中,JDK1.4以前的唯一选择,但程序简单易理解。
- NIO方式适用于连接数目多且连接比较短(轻操作)的架构,比如聊天服务器,弹幕系统,服务器间通讯等。编程比较复杂,JDK1.4开始支持。
- AIO方式使用于连接数目多且连接比较长(重操作)的架构,比如相册服务器,充分调用OS参与并发操作,编程比较复杂,JDK7开始支持。
2、Java BIO 基本介绍
- Java BIO 就是传统的java io编程,其相关的类和接口在
java.io
- BIO(blocking I/O)**: **同步阻塞,服务器实现模式为==一个连接一个线程==,即客户端有连接请求时服务器端就需要启动一个线程进行处理,如果这个连接不做任何事情会造成不必要的线程开销,可以通过线程池机制改善(实现多个客户连接服务器)。 【后有应用实例】
- BIO方式适用于连接数目比较小且固定的架构,这种方式对服务器资源要求比较高,并发局限于应用中,JDK1.4以前的唯一选择,程序简单易理解
3、Java BIO 工作机制
1、工作原理图
2、BIO编程简单流程
- 服务器端启动一个ServerSocket
- 客户端启动Socket对服务器进行通信,默认情况下服务器端需要对每个客户建立一个线程与之通讯
- 客户端发出请求后,先咨询服务器是否有线程响应,如果没有则会等待,或者被拒绝
- 如果有响应,客户端线程会等待请求结束后,在继续执行
4、Java BIO 应用实例
实例说明:
- 使用BIO模型编写一个服务器端,监听6666端口,当有客户端连接时,就启动一个线程与之通讯。
- 要求使用线程池机制改善,可以连接多个客户端;
- 服务器端可以接收客户端发送的数据(telnet 方式即可)。
代码:
1 | package com.awo.bio; |
5、Java BIO 问题分析
- 每个请求都需要创建独立的线程,与对应的客户端进行数据 Read,业务处理,数据 Write 。
- 当并发数较大时,需要创建大量线程来处理连接,系统资源占用较大。
- 连接建立后,如果当前线程暂时没有数据可读,则线程就阻塞在 Read 操作上,造成线程资源浪费
3、Java NIO编程
1、Java NIO 基本介绍
Java NIO 全称 java non-blocking IO,是指 JDK 提供的新 API。从 JDK1.4 开始,Java 提供了一系列改进的输入/输出的新特性,被统称为 NIO(即 New IO),是同步非阻塞的
NIO 相关类都被放在 java.nio 包及子包下,并且对原 java.io 包中的很多类进行改写。
NIO 有三大核心部分:
Channel(通道)
,Buffer(缓冲区)
,Selector(选择器)
NIO是 ==面向缓冲区== ,或者==面向 块 编程==的。数据读取到一个它稍后处理的缓冲区,需要时可在缓冲区中前后移动,这就增加了处理过程中的灵活性,使用它可以提供非阻塞式的高伸缩性网络
Java NIO的非阻塞模式,使一个线程从某通道发送请求或者读取数据,但是它仅能得到目前可用的数据,如果目前没有数据可用时,就什么都不会获取,而不是保持线程阻塞,所以直至数据变的可以读取之前,该线程可以继续做其他的事情。 非阻塞写也是如此,一个线程请求写入一些数据到某通道,但不需要等待它完全写入,这个线程同时可以去做别的事情。【后面有案例说明】
通俗理解:NIO是可以做到用一个线程来处理多个操作的。假设有10000个请求过来,根据实际情况,可以分配50或者100个线程来处理。不像之前的阻塞IO那样,非得分配10000个。
HTTP2.0
使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。
2、NIO 和 BIO的比较
- BIO 以==流==的方式处理数据,而 NIO 以==块==的方式处理数据,块 I/O 的效率比流 I/O 高很多
- BIO 是==阻塞==的,NIO 则是==非阻塞==的
- BIO基于==字节流==和==字符流==进行操作,而 NIO 基于 ==Channel(通道)==和 ==Buffer(缓冲区)==进行操作,数据总是从通道读取到缓冲区中,或者从缓冲区写入到通道中。Selector(选择器)用于==监听多个通道的事件==(比如:连接请求,数据到达等),因此使用单个线程就可以监听多个客户端通道
3、NIO 三大核心原理示意图
一张图描述NIO 的 Selector
、 Channel
和 Buffer
的关系:
Selector
、 Channel
和 Buffer
的关系图(简单版)关系图的说明:
- 每个channel 都会对应一个Buffer
- Selector 对应一个线程, 一个线程对应多个channel(连接)
- 该图反应了有三个channel 注册到 该selector //程序
- 程序切换到哪个channel 是有事件决定的,Event 就是一个重要的概念
- Selector 会根据不同的事件,在各个通道上切换
- Buffer 就是一个内存块 ,底层是有一个数组
- 数据的读取写入是通过Buffer,这个和BIO有着本质的不同:BIO 中要么是输入流,要么是输出流,不能双向,但是NIO的Buffer 是可以读也可以写,需要
flip
方法切换 - channel 是双向的,可以返回底层操作系统的情况,比如Linux:底层的操作系统通道就是双向的。
4、缓冲区(Buffer)
1、基本介绍
缓冲区(Buffer):缓冲区本质上是一个可以读写数据的内存块,可以理解成是一个容器对象(含数组)**,该对象提供了一组方法,可以更轻松地使用内存块,缓冲区对象内置了一些机制,能够跟踪和记录缓冲区的状态变化情况**。Channel 提供从文件、网络读取数据的渠道,但是读取或写入的数据都必须经由 Buffer,如图: 【后面举例说明】
2、Buffer 类及其子类
1、Buffer类继承关系
在 NIO 中,Buffer 是一个顶层父类,它是一个抽象类,类的层级关系图
- 常用Buffer子类一览
ByteBuffer
:存储字节数据到缓冲区ShortBuffer
:存储字符串数据到缓冲区CharBuffer
:存储字符数据到缓冲区IntBuffer
:存储整数数据到缓冲区LongBuffer
:存储长整型数据到缓冲区DoubleBuffer
:存储小数到缓冲区FloatBuffer
:存储小数到缓冲区
- 每一个Buffer的实现类都有一个属性:
hb
(不同实现类该属性的类型不同,但都是一个数组),数据实际上就是存放在hb
数组里面的
2、Buffer的四个主要属性
Buffer类定义了所有的缓冲区都具有的四个属性来提供关于其所包含的数据元素的信息:
Capacity
:容量,即可以容纳的最大数据量;在缓冲区创建时被设定并且不能改变Limit
:表示缓冲区的当前终点,不能对缓冲区超过极限的位置进行读写操作(左闭右开)。且极限是可以修改的Position
:位置,下一个要被读或写的元素的索引,每次读写缓冲区数据时都会改变改值,为下次读写作准备Mark
:标记(很少主动修改)
1 | // Invariants: mark <= position <= limit <= capacity |
其中最重要的flip()方法:用来切换Buffer的读写(其中对于limit是一个“左闭右开区间”)
1 | public final Buffer flip() { |
左闭右开:
3、Buffer类相关方法一览
1 | public abstract class Buffer { |
注:什么是直接缓冲区?
- 直接缓冲区指的是操作系统的缓冲区
- 而平常的缓冲区通常都是JVM分配的缓冲区
4、ByteBuffer(最常用)
从前面可以看出对于 Java 中的基本数据类型(boolean除外),都有一个 Buffer 类型与之相对应,最常用的自然是ByteBuffer 类(二进制数据),该类的主要方法如下:
1 | public abstract class ByteBuffer { |
5、通道(Channel)
1、基本介绍
NIO的通道类似于流,但有些区别如下:
- 通道可以同时进行读写,而流只能读或者只能写
- 通道可以实现异步读写数据
- 通道可以从缓冲读数据,也可以写数据到缓冲:
BIO 中的 stream 是单向的,例如 FileInputStream 对象只能进行读取数据的操作,而 NIO 中的通道(Channel)是双向的,可以读操作,也可以写操作。
Channel在NIO中是一个接口:
public interface Channel extends Closeable{}
1
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
4. 常用的 Channel 类有:
- `FileChannel`:用于文件的数据读写
- `DatagramChannel`:用于 UDP 的数据读写
- `ServerSocketChannel`:用于 TCP 的数据读写
- ServerSocketChanne 类似 ServerSocket
- `SocketChannel`:用于 TCP 的数据读写
- SocketChannel 类似 Socket
![image-20210817001954099](Netty/image-20210817001954099.png)
![image-20210817002125912](Netty/image-20210817002125912.png)
#### 2、FileChannel类
FileChannel主要用来对本地文件进行 IO 操作,常见的方法有:
```java
// 从通道读取数据并放到缓冲区中
public int read(ByteBuffer dst);
// 把缓冲区的数据写到通道中
public int write(ByteBuffer src);
// 从目标通道中复制数据到当前通道(可以用来做文件的拷贝,速度很快)
public long transferFrom(ReadableByteChannel src, long position, long count);
// 把数据从当前通道复制给目标通道(底层实现了零拷贝,速度很快)
public long transferTo(long position, long count, WritableByteChannel target);
3、应用实例
1、应用实例1——本地文件写数据
实例要求:
- 使用前面的ByteBuffer(缓冲) 和 FileChannel(通道), 将 “hello,world” 写入到file01.txt 中
- 文件不存在就创建
分析:
代码:
1 | package com.awo.nio; |
2、应用实例2——本地文件读数据
实例要求:
- 使用前面的ByteBuffer(缓冲) 和 FileChannel(通道), 将 file01.txt 中的数据读入到程序,并显示在控制台屏幕
- 假定文件已经存在
分析:
代码:
1 | package com.awo.nio; |
3、应用实例3——使用一个Buffer完成文件读取
实例要求:
- 使用 FileChannel(通道) 和 方法 read , write,完成文件的拷贝
- 拷贝一个文本文件 1.txt , 放在项目下即可
分析:
代码:
1 | package com.awo.nio; |
clear()的相关代码:
1 | public final Buffer clear() { |
4、应用实例4——拷贝文件transferFrom 方法
实例要求:
- 使用 FileChannel(通道) 和 方法 transferFrom ,完成文件的拷贝
- 拷贝一张图片
代码:
1 | package com.awo.nio; |
4、关于Buffer 和 Channel的注意事项和细节
- ByteBuffer 支持类型化的put 和 get, put 放入的是什么数据类型,get就应该使用相应的数据类型来取出,否则可能有
BufferUnderflowException
异常。 - 可以将一个普通Buffer 转成只读Buffer:使用
buffer.asReadOnlyBuffer();
方法将一个普通buffer转换成只读Buffer- 如果在只读Buffer当中添加数据,会抛出一个
ReadOnlyBufferException
异常
- 如果在只读Buffer当中添加数据,会抛出一个
- NIO 还提供了
MappedByteBuffer
, 可以让文件直接在内存(堆外的内存)中进行修改, 而如何同步到文件由NIO 来完成。调用channel.map(FileChannel.MapMode.READ_WRITE, 0, 6);
方法生成一个MappedByteBuffer
对象- 注意:map的几个参数
MapMode mode
:映射的模式——与上面创建流的模式对应long position
:从哪里开修改,即修改的开始位置long size
:修改的大小,如果修改的地方超过设置的修改大小,会抛出一个IndexOutOfBoundsException
异常
- 注意:map的几个参数
- 前面我们讲的读写操作,都是通过一个Buffer 完成的,NIO 还支持 通过多个Buffer (即 Buffer 数组) 完成读写操作,即
Scattering
和Gathering
- Scattering:将数据写入到buffer时,可以采用buffer数组,依次写入 [分散读取]
- Gathering: 从buffer读取数据时,可以采用buffer数组,依次读取 [聚集写入]
1、关于MappedByteBuffer的相关示例:
1 | package com.awo.nio; |
2、关于 Scattering 和 Gathering的相关示例
1 | package com.awo.nio; |
6、Selector(选择器)
1、基本介绍
- Java 的 NIO,用非阻塞的 IO 方式。可以用一个线程,处理多个的客户端连接,就会使用到Selector选择器
- **Selector 能够检测多个注册的通道上是否有事件发生(注意:多个Channel以事件的方式可以注册到同一个Selector)**,如果有事件发生,便获取事件然后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个通道,也就是管理多个连接和请求。
- 只有在 连接/通道 真正有读写事件发生时,才会进行读写,就大大地减少了系统开销,并且不必为每个连接都创建一个线程,不用去维护多个线程
- 避免了多线程之间的上下文切换导致的开销
2、Selector示意图和特点说明
1、Selector示意图
2、特点说明
- Netty 的 IO 线程
NioEventLoop
聚合了 Selector(选择器,也叫多路复用器),可以同时并发处理成百上千个客户端连接。 - 当线程从某客户端 Socket 通道进行读写数据时,若没有数据可用时,该线程可以进行其他任务。
- 线程通常将非阻塞 IO 的空闲时间用于在其他通道上执行 IO 操作,所以单独的线程可以管理多个输入和输出通道。
- 由于读写操作都是非阻塞的,这就可以充分提升 IO 线程的运行效率,避免由于频繁 I/O 阻塞导致的线程挂起。
- 一个 I/O 线程可以并发处理 N 个客户端连接和读写操作,这从根本上解决了传统同步阻塞 I/O 一连接一线程模型,架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。
3、Selector类相关方法
Selector 类是一个抽象类,以下为Selector的相关方法:
常用方法和说明如下:
1 | public abstract class Selector implements Closeable { |
4、注意事项
NIO中的 ServerSocketChannel功能类似ServerSocket,SocketChannel功能类似Socket
selector 相关方法说明:
selector.select()//阻塞 selector.select(1000);//阻塞1000毫秒,在1000毫秒后返回 selector.wakeup();//唤醒selector selector.selectNow();//不阻塞,立马返还
1
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
### 7、NIO 非阻塞 网络编程
#### 1、NIO 非阻塞 网络编程原理分析图
NIO 非阻塞 网络编程相关的(`Selector`、`SelectionKey`、`ServerScoketChannel`和`SocketChannel`) 关系梳理图:
![image-20210817173445617](Netty/image-20210817173445617.png)
对上图的说明:
1. 当客户端连接时,会通过 ServerSocketChannel 得到 SocketChannel
2. Selector 进行监听 select 方法, 返回有事件发生的通道的个数.
3. 将 socketChannel 注册到Selector上,register(Selector sel, int ops), 一个selector上可以注册多个SocketChannel
- 其中register(Selector sel, int ops)方法的两个参数:
- Selector sel:想要注册到的选择器
- int ops:SelectionKey与Channel的注册关系
- `int OP_ACCEPT`:有新的网络连接可以 accept,值为 16
- `int OP_CONNECT`:代表连接已经建立,值为 8
- `int OP_READ`:代表读操作,值为 1
- `int OP_WRITE`:代表写操作,值为 4
4. 注册后返回一个 SelectionKey,会和该Selector 关联(集合)
5. 进一步得到各个 SelectionKey (有事件发生)
6. 在通过 SelectionKey 反向获取 SocketChannel,方法 channel()
7. 可以通过channel()方法得到的 channel , 完成业务处理
#### 2、NIO 非阻塞 网络编程快速入门
案例要求:
1. 编写一个 NIO 入门案例,实现服务器端和客户端之间的数据简单通讯(非阻塞)
2. 目的:理解NIO非阻塞网络编程机制
代码示例:
- 服务端:
```java
package com.awo.nio;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.*;
import java.util.Iterator;
import java.util.Set;
public class NIOServer {
public static void main(String[] args) throws IOException {
//创建ServerSocketChannel -> ServerSocket
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
//得到一个Selector对象
Selector selector = Selector.open();
//绑定一个端口6666, 在服务器端监听
serverSocketChannel.socket().bind(new InetSocketAddress(6666));
//设置为非阻塞
serverSocketChannel.configureBlocking(false);
//把 serverSocketChannel 注册到 selector 关心 事件为 OP_ACCEPT
serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
// 1
System.out.println("注册后的Selectionkey 数量=" + selector.keys().size());
//循环等待客户端连接
while (true) {
//这里我们等待1秒,如果没有事件发生, 返回
if (selector.select(1000) == 0) {
//没有事件发生
System.out.println("服务器等待了1秒,无连接");
continue;
}
//如果返回的>0, 就获取到相关的 selectionKey集合
//1.如果返回的>0, 表示已经获取到关注的事件
//2. selector.selectedKeys() 返回关注事件的集合
// 通过 selectionKeys 反向获取通道
Set<SelectionKey> selectionKeys = selector.selectedKeys();
System.out.println("selectionKeys 数量 = " + selectionKeys.size());
//遍历 Set<SelectionKey>, 使用迭代器遍历
Iterator<SelectionKey> keyIterator = selectionKeys.iterator();
while (keyIterator.hasNext()) {
//获取到SelectionKey
SelectionKey selectionKey = keyIterator.next();
//根据key 对应的通道发生的事件做相应处理
//如果是 OP_ACCEPT, 有新的客户端连接
if (selectionKey.isAcceptable()) {
//该该客户端生成一个 SocketChannel
SocketChannel socketChannel = serverSocketChannel.accept();
System.out.println("客户端连接成功 生成了一个 socketChannel " + socketChannel.hashCode());
//将 SocketChannel 设置为非阻塞
socketChannel.configureBlocking(false);
//将socketChannel 注册到selector, 关注事件为 OP_READ, 同时给socketChannel关联一个Buffer
ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
socketChannel.register(selector, SelectionKey.OP_READ, byteBuffer);
//2,3,4..
System.out.println("客户端连接后 ,注册的selectionkey 数量=" + selector.keys().size());
}
//发生 OP_READ
if (selectionKey.isReadable()) {
//通过key 反向获取到对应channel
SocketChannel channel = (SocketChannel) selectionKey.channel();
//获取到该channel关联的buffer
ByteBuffer buffer = (ByteBuffer) selectionKey.attachment();
channel.read(buffer);
System.out.println("form 客户端 " + new String(buffer.array()));
}
//手动从集合中移动当前的selectionKey, 防止重复操作
keyIterator.remove();
}
}
}
}
- 客户端
1 | package com.awo.nio; |
8、SelectionKey
1、SelectionKey和网络通道的注册关系
SelectionKey,表示 Selector 和网络通道的注册关系, 共四种:
int OP_ACCEPT
:有新的网络连接可以 accept,值为 16int OP_CONNECT
:代表连接已经建立,值为 8int OP_READ
:代表读操作,值为 1int OP_WRITE
:代表写操作,值为 4
相关源代码:
1 | public static final int OP_READ = 1 << 0; |
2、SelectionKey相关方法
其中几个比较常用的方法:
1 | public abstract class SelectionKey { |
9、ServerSocketChannel
ServerSocketChannel 在服务器端监听新的客户端 Socket 连接
ServerSocketChannel相关方法如下:
常用方法以及说明:
1 | public abstract class ServerSocketChannel extends AbstractSelectableChannel implements NetworkChannel{ |
10、SocketChannel
SocketChannel,网络 IO 通道,具体负责进行读写操作。NIO 把缓冲区的数据写入通道,或者把通道里的数据读到缓冲区。
相关方法如下:
常用方法以及说明:
1 | public abstract class SocketChannel extends AbstractSelectableChannel implements ByteChannel, ScatteringByteChannel, GatheringByteChannel, NetworkChannel{ |
11、NIO 网络编程应用实例——群聊系统
1、实例要求
- 编写一个 NIO 群聊系统,实现服务器端和客户端之间的数据简单通讯(非阻塞)
- 实现多人群聊
- 服务器端:可以监测用户上线,离线,并实现消息转发功能
- 客户端:通过channel 可以无阻塞发送消息给其它所有用户,同时可以接受其它用户发送的消息(有服务器转发得到)
- 目的:进一步理解NIO非阻塞网络编程机制
2、实例需求图
3、分析
- 先编写服务器端
- 服务器启动并监听 6667
- 服务器接收客户端信息,并实现转发 [处理上线和离线]
- 其中转发注意需要排除发送消息的客户端
- 编写客户端
- 连接服务器
- 发送消息
- 接收服务器消息
4、代码
服务端:
1 | package com.awo.nio.groupchat; |
客户端:
1 | package com.awo.nio.groupchat; |
12、NIO与零拷贝
1、零拷贝基本介绍
- 零拷贝是网络编程的关键,很多性能优化都离不开零拷贝。
- 在 Java 程序中,常用的零拷贝有
mmap(内存映射)
和sendFile
。那么,他们在 OS 里,到底是怎么样的一个的设计?我们分析 mmap 和 sendFile 这两个零拷贝 - 另外我们看下NIO 中如何使用零拷贝
2、传统IO数据读写
代码:
1 | File file = new File("test.txt"); |
3、传统IO模型
注意:
DMA
:direct memory access——直接内存拷贝(不使用CPU)- 这个IO经过了四次拷贝(两次CPU拷贝、两次DMA拷贝)和三次状态切换(用户态->内核态->用户态->内核态),代价较高
- 四次拷贝
- 第一次: 从硬盘 经过 DMA 拷贝 到 kernel buffer (内核buferr)
- 第二次: 从kernel buffer 经过cpu 拷贝到 user buffer,比如拷贝到应用程序
- 第三次: 从user buffer 拷贝到 socket buffer
- 第四次: 从socket buffer 拷贝到 protocol engine 协议栈
- 三次状态切换
- 第一次状态切换: 用户态 —> 内核态 (或者叫着 用户上下文—-> 内核上下文)
- 第二次状态切换: 内核态—> 用户态
- 第三次状态切换: 用户态—> 内核态
- 四次拷贝
- 有一个观点认为状态切换变成了四次(最后需要从内核态切换为用户态)
- 第四次状态切换:内核态—> 用户态
4、mmap优化
mmap 通过内存映射,将文件映射到内核缓冲区,同时,用户空间可以共享内核空间的数据。这样,在进行网络传输时,就可以减少内核空间到用户控件的拷贝次数。
注意:
- 通过mmap内存映射优化之后,拷贝次数变成了3次,状态切换还是3次
- 三次拷贝
- 第一次拷贝: DMA拷贝,从硬件拷贝到内核空间
- 因为user buffer 与kernel buffer共享数据 ,所以不需要将数据从kernel buffer 拷贝到 user buffer , 数据可以直接在内核空间修改
- 第二次拷贝: kernel buffer 中的数据经过 cpu 拷贝到 socket buffer
- 第三次拷贝: socket buffer 过DMA拷贝到protocol engine 协议栈
- 第一次拷贝: DMA拷贝,从硬件拷贝到内核空间
- 三次状态切换
- 第一次状态切换: 用户态 —> 内核态(或者叫着 用户上下文—-> 内核上下文)
- 第二次状态切换: 内核态—> 用户态
- 第三次状态切换: 用户态—> 内核态
- 三次拷贝
- 有一个观点认为状态切换变成了四次(最后需要从内核态切换为用户态)
- 第四次状态切换:内核态—> 用户态
5、sendFile优化
Linux 2.1 版本 提供了 sendFile 函数,其基本原理如下:数据根本不经过用户态,直接从内核缓冲区进入到 Socket Buffer,同时,由于和用户态完全无关,就减少了一次上下文切换。具体如下图和小结:
注意:
- Linux 2.1 版本中,通过sendFile优化之后,拷贝次数变成了3次,状态切换还是2次
- 三次拷贝
- 第一次拷贝: DMA拷贝,从硬件拷贝到内核空间
- 第二次拷贝: kernel buffer 中的数据经过 cpu 拷贝到 socket buffer
- 第三次拷贝: socket buffer 过DMA拷贝到protocol engine 协议栈
- 两次状态切换
- 第一次状态切换: 用户态 —> 内核态(或者叫着 用户上下文—-> 内核上下文)
- 第二次状态切换: 内核态—> 用户态
- 由于和用户态完全无关,所以就不用切换到用户态后再切换到内核态了,减少了一次上下文切换
- 三次拷贝
注:
- 零拷贝从操作系统角度,是没有cpu 拷贝(DMA不可避免)
- Linux 2.1 版本 提供了 sendFile 函数并没有完全实现零拷贝(存在CPU拷贝)
Linux 在 2.4 版本中,做了一些修改,避免了从内核缓冲区拷贝到 Socket buffer 的操作,直接拷贝到协议栈,从而再一次减少了数据拷贝。具体如下图和小结:
注意:
- Linux 在 2.4 版本中,通过sendFile优化之后,拷贝次数变成了2次,状态切换还是2次
- 两次拷贝
- 第一次拷贝: DMA拷贝,将数据从硬盘拷贝到kernel buffer
- 第二次拷贝: DMA拷贝,将数据从kernel buffer拷贝到protocol engine
- 没有经过cpu拷贝,也就是操作系统级别的拷贝,实现了真正的零拷贝
- 两次状态切换
- 第一次状态切换: 用户态 —> 内核态(或者叫着 用户上下文—-> 内核上下文)
- 第二次状态切换: 内核态—> 用户态
- 两次拷贝
注:
- Linux2.4 提供的sendFile实现了真正的零拷贝
- 这里其实有 一次cpu 拷贝 kernel buffer -> socket buffer 但是,拷贝的信息很少,比如 lenght , offset , 消耗低,可以忽略
6、零拷贝的再次理解
- 我们说零拷贝,是从操作系统的角度来说的。因为内核缓冲区之间,没有数据是重复的(只有 kernel buffer 有一份数据)。
- 零拷贝不仅仅带来更少的数据复制,还能带来其他的性能优势,例如更少的上下文切换,更少的 CPU 缓存伪共享以及无 CPU 校验和计算。
7、mmap与sendFile的区别
- mmap 适合小数据量读写,sendFile 适合大文件传输。
- mmap 需要 4 次上下文切换,3 次数据拷贝;sendFile 需要 3 次上下文切换,最少 2 次数据拷贝。
- sendFile 可以利用 DMA 方式,减少 CPU 拷贝,mmap 则不能(必须从内核拷贝到 Socket 缓冲区)。
8、NIO零拷贝案例
案例要求:
- 使用传统的IO 方法传递一个大文件
- 使用NIO 零拷贝方式传递(transferTo)一个大文件
- 看看两种传递方式耗时时间分别是多少
代码:
传统IO的服务端:
1 | import java.io.DataInputStream; |
传统IO的客户端:
1 | import java.io.DataInputStream; |
零拷贝的服务端:
1 | import java.net.InetSocketAddress; |
零拷贝的客户端:
1 | import java.io.FileInputStream; |
结果:
传统IO:
1 | 发送的总的字节数 = 1,007,473 耗时:60 |
零拷贝:
1 | 发送的总的字节数 = 1,007,473 耗时:21 |
4、Java AIO 以及 三种IO模型的对比
1、Java AIO 基本介绍
- JDK 7 引入了 Asynchronous I/O,即 AIO。在进行 I/O 编程中,常用到两种模式:
Reactor
和Proactor
。Java 的 NIO 就是 Reactor,当有事件触发时,服务器端得到通知,进行相应的处理 - AIO 即 NIO2.0,叫做异步不阻塞的 IO。AIO 引入异步通道的概念,采用了 Proactor 模式,简化了程序编写,有效的请求才启动线程,它的特点是先由操作系统完成后才通知服务端程序启动线程去处理,一般适用于连接数较多且连接时间较长的应用
- 目前 AIO 还没有广泛应用,Netty 也是基于NIO, 而不是AIO, 因此我们就不详解AIO了,有兴趣的同学可以参考 <<Java新一代网络编程模型AIO原理及Linux系统AIO介绍>>
2、BIO、NIO、AIO对比表
BIO | NIO | AIO | |
---|---|---|---|
IO 模型 | 同步阻塞 | 同步非阻塞(多路复用) | 异步非阻塞 |
编程难度 | 简单 | 复杂 | 复杂 |
可靠性 | 差 | 好 | 好 |
可靠性 | 低 | 高 | 高 |
举例说明:
- 同步阻塞:到理发店理发,就一直等理发师,直到轮到自己理发。
- 同步非阻塞:到理发店理发,发现前面有其它人理发,给理发师说下,先干其他事情,一会过来看是否轮到自己。
- 异步非阻塞:给理发师打电话,让理发师上门服务,自己干其它事情,理发师自己来家给你理发
4、Netty概述
1、原生NIO存在的问题
- NIO 的类库和 API 繁杂,使用麻烦:需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
- 需要具备其他的额外技能:要熟悉 Java 多线程编程,因为 NIO 编程涉及到 Reactor 模式,你必须对多线程和网络编程非常熟悉,才能编写出高质量的 NIO 程序。
- 开发工作量和难度都非常大:例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常流的处理等等。
- JDK NIO 的 Bug:例如臭名昭著的 Epoll Bug,它会导致 Selector 空轮询,最终导致 CPU 100%。直到 JDK 1.7 版本该问题仍旧存在,没有被根本解决。
2、Netty官网
Netty官网上的说明:
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients
3、Netty官网说明
- Netty 是由 JBOSS 提供的一个 Java 开源框架。Netty 提供==异步==的、==基于事件驱动==的网络应用程序框架,用以快速开发高性能、高可靠性的网络 IO 程序
- Netty 可以帮助你快速、简单的开发出一个网络应用,相当于简化和流程化了 NIO 的开发过程
- Netty 是目前最流行的 NIO 框架,Netty 在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用,知名的 Elasticsearch 、Dubbo 框架内部都采用了 Netty。
4、Netty的优点
Netty 对 JDK 自带的 NIO 的 API 进行了封装,解决了上述问题。
- 设计优雅:适用于各种传输类型的统一 API 阻塞和非阻塞 Socket;基于灵活且可扩展的事件模型,可以清晰地分离关注点;高度可定制的线程模型 - 单线程,一个或多个线程池。
- 使用方便:详细记录的 Javadoc,用户指南和示例;没有其他依赖项,JDK 5(Netty 3.x)或 6(Netty 4.x)就足够了。
- 高性能、吞吐量更高:延迟更低;减少资源消耗;最小化不必要的内存复制。
- 安全:完整的 SSL/TLS 和 StartTLS 支持。
- 社区活跃、不断更新:社区活跃,版本迭代周期短,发现的 Bug 可以被及时修复,同时,更多的新功能会被加入
5、Netty版本说明
- netty版本分为 netty3.x 和 netty4.x、netty5.x
- 因为Netty5出现重大bug,已经被官网废弃了,目前推荐使用的是Netty4.x的稳定版本
- 目前在官网可下载的版本 netty3.x netty4.0.x 和 netty4.1.x
- 本次以 Netty4.1.x 版本为主
- netty 下载地址
5、Netty 高性能架构设计
1、线程模型基本介绍
- 不同的线程模式,对程序的性能有很大影响,为了搞清Netty 线程模式,我们来系统的讲解下各个线程模式, 最后看看Netty 线程模型有什么优越性。
- 目前存在的线程模型有:
- 传统阻塞 I/O 服务模型
- Reactor 模式
- 根据 Reactor 的数量和处理资源池线程的数量不同,有 3 种典型的实现
- 单 Reactor 单线程;
- 单 Reactor 多线程;
- 主从 Reactor 多线程;
- Netty 线程模式(Netty 主要基于主从 Reactor 多线程模型做了一定的改进,其中主从 Reactor 多线程模型有多个 Reactor)
2、传统阻塞 I/O 服务模型
1、工作原理图
黄色的框表示对象, 蓝色的框表示线程,白色的框表示方法(API)
2、模型特点
- 采用阻塞IO模式获取输入的数据
- 每个连接都需要独立的线程完成数据的输入,业务处理,数据返回
3、问题分析
- 当并发数很大,就会创建大量的线程,占用很大系统资源
- 连接创建后,如果当前线程暂时没有数据可读,该线程会阻塞在read 操作,造成线程资源浪费
3、Reactor 模式(整体)
1、针对传统阻塞 I/O 服务模型的 2 个缺点,解决方案
- ==基于 I/O 复用模型==:多个连接共用一个阻塞对象,应用程序只需要在一个阻塞对象等待,无需阻塞等待所有连接。当某个连接有新的数据可以处理时,操作系统通知应用程序,线程从阻塞状态返回,开始进行业务处理
- `Reactor 对应的叫法:
- 反应器模式
- 分发者模式(Dispatcher)
- 通知者模式(notifier)
- `Reactor 对应的叫法:
- ==基于线程池复用线程资源==:不必再为每个连接创建线程,将连接完成后的业务处理任务分配给线程进行处理,一个线程可以处理多个连接的业务。
2、工作原理图
I/O 复用结合线程池,就是 Reactor 模式基本设计思想,如图:
3、模型特点
- Reactor 模式,通过一个或多个输入同时传递给服务处理器的模式(基于事件驱动)
- 服务器端程序处理传入的多个请求,并将它们同步分派到相应的处理线程, 因此Reactor模式也叫 Dispatcher模式
- Reactor 模式使用IO复用监听事件,收到事件后,分发给某个线程(进程),这点就是网络服务器高并发处理关键
4、Reactor 模式中 核心组成
Reactor
:Reactor 在一个单独的线程中运行,负责监听和分发事件,分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员,它接听来自客户的电话并将线路转移到适当的联系人;Handlers
:处理程序执行 I/O 事件要完成的实际事件,类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件,处理程序执行非阻塞操作。
5、Reactor 模式分类
根据 Reactor 的数量和处理资源池线程的数量不同,有 3 种典型的实现:
- 单 Reactor 单线程
- 单 Reactor 多线程
- 主从 Reactor 多线程
4、单 Reactor 单线程
1、工作原理图
2、原理图说明
- Select 是前面 I/O 复用模型介绍的标准网络编程 API,可以实现应用程序通过一个阻塞对象监听多路连接请求
- Reactor 对象通过 Select 监控客户端请求事件,收到事件后通过 Dispatch 进行分发
- 如果是建立连接请求事件,则由 Acceptor 通过 Accept 处理连接请求,然后创建一个 Handler 对象处理连接完成后的后续业务处理
- 如果不是建立连接事件,则 Reactor 会分发调用连接对应的 Handler 来响应
- Handler 会完成 Read→业务处理→Send 的完整业务流程
结合实例:服务器端用一个线程通过多路复用搞定所有的 IO 操作(包括连接,读、写等),编码简单,清晰明了,但是如果客户端连接数量较多,将无法支撑,前面的 NIO 案例就属于这种模型。
3、单 Reactor 单线程的优缺点
- 优点:
- 模型简单,没有多线程、进程通信、竞争的问题,全部都在一个线程中完成
- 缺点:
- 性能问题,只有一个线程,无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时,整个进程无法处理其他连接事件,很容易导致性能瓶颈
- 可靠性问题,线程意外终止,或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障
- 使用场景:
- 客户端的数量有限,业务处理非常快速,比如 Redis在业务处理的时间复杂度 O(1) 的情况
5、单Reactor 多线程
1、工作原理图
2、原理图说明
- Reactor 对象通过select 监控客户端请求事件,收到事件后,通过dispatch进行分发
- 如果建立连接请求,则由 Acceptor 通过accept 处理连接请求,然后创建一个Handler对象处理完成连接后的各种事件
- 如果不是连接请求,则由reactor分发调用连接对应的handler 来处理
- handler 只负责响应事件,不做具体的业务处理,通过read 读取数据后,会分发给后面的worker线程池的某个线程处理业务
- worker 线程池会分配独立线程完成真正的业务,并将结果返回给handler
- handler收到响应后,通过send 将结果返回给client
3、单Reactor 多线程的优缺点
- 优点:可以充分的利用多核cpu 的处理能力
- 缺点:多线程数据共享和访问比较复杂, reactor 处理所有的事件的监听和响应,在单线程运行, 在高并发场景容易出现性能瓶颈。
6、主从 Reactor 多线程
1、工作原理图
针对单 Reactor 多线程模型中,Reactor 在单线程中运行,高并发场景下容易成为性能瓶颈,可以让 Reactor 在多线程中运行
2、原理图说明
- Reactor主线程 MainReactor 对象通过select 监听连接事件,收到事件后,通过Acceptor 处理连接事件
- 当 Acceptor 处理连接事件后,MainReactor 将连接分配给SubReactor
- subreactor 将连接加入到连接队列进行监听,并创建handler进行各种事件处理
- 当有新事件发生时, subreactor 就会调用对应的handler处理
- handler 通过read 读取数据,分发给后面的worker 线程处理
- worker 线程池分配独立的worker 线程进行业务处理,并返回结果
- handler 收到响应的结果后,再通过send 将结果返回给client
- Reactor 主线程可以对应多个Reactor 子线程,即MainRecator 可以关联多个SubReactor
3、Scalable IO in Java 对 Multiple Reactors 的原理图解
4、主从 Reactor 多线程的优缺点
- 优点:
- 父线程与子线程的数据交互简单职责明确,父线程只需要接收新连接,子线程完成后续的业务处理。
- 父线程与子线程的数据交互简单,Reactor 主线程只需要把新连接传给子线程,子线程无需返回数据。
- 缺点:
- 编程复杂度较高
- 结合实例:这种模型在许多项目中广泛使用,包括
Nginx
主从 Reactor 多进程模型,Memcached
主从多线程,Netty
主从多线程模型的支持
7、Reactor 模式小结
1、3 种模式用生活案例来理解
- 单 Reactor 单线程,前台接待员和服务员是同一个人,全程为顾客服务
- 单 Reactor 多线程,1 个前台接待员,多个服务员,接待员只负责接待
- 主从 Reactor 多线程,多个前台接待员,多个服务生
2、Reactor 模式具有如下的优点
- 响应快,不必为单个同步时间所阻塞,虽然 Reactor 本身依然是同步的
- 可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销
- 扩展性好,可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源
- 复用性好,Reactor 模型本身与具体事件处理逻辑无关,具有很高的复用性
8、Netty模型
1、工作原理图1——简单版
Netty 主要基于主从 Reactors 多线程模型(如图)做了一定的改进,其中主从 Reactor 多线程模型有多个 Reactor。
- BossGroup 线程维护 Selector ,只关注 Accecpt 事件
- 当接收到Accept事件,获取到对应的SocketChannel,封装成 NIOScoketChannel并注册到Worker 线程(事件循环),并进行维护
- 当Worker线程监听到 selector 中通道发生自己感兴趣的事件后,就进行处理(就由handler进行处理), 注意handler 已经加入到通道
2、工作原理图2——进阶版
Netty 主要基于主从 Reactors 多线程模型(如图)做了一定的改进,其中主从 Reactor 多线程模型有多个 Reactor
3、工作原理图3——详细版
4、原理图说明
- Netty抽象出两组线程池:
BossGroup
:专门负责接收客户端的连接WorkerGroup
: 专门负责网络的读写
- BossGroup 和 WorkerGroup 类型都是
NioEventLoopGroup
- NioEventLoopGroup 相当于一个事件循环组, 这个组中含有多个事件循环 ,每一个事件循环是 NioEventLoop
- NioEventLoop 表示一个不断循环的执行处理任务的线程, 每个NioEventLoop 都有一个selector,用于监听绑定在其上的socket的网络通讯
- NioEventLoopGroup 可以有多个线程,即可以含有多个NioEventLoop
- 每个Boss NioEventLoop 循环执行的步骤有3步
- 轮询accept 事件
- 处理accept 事件,与client建立连接,生成NioScocketChannel,并将其注册到某个worker NIOEventLoop 上的 selector
- 处理任务队列的任务,即 runAllTasks
- 每个 Worker NIOEventLoop 循环执行的步骤
- 轮询read/write 事件
- 处理i/o事件,即read/write 事件,在对应NioScocketChannel上进行处理
- 处理任务队列的任务 , 即 runAllTasks
- 每个Worker NIOEventLoop 处理业务时,会使用pipeline(管道),pipeline 中包含了 channel,即通过pipeline 可以获取到对应通道,管道中维护了很多的处理器(可对数据进行相关的拦截与过滤等等)。
5、Netty快速入门实例——TCP服务
- 实例要求:使用IDEA 创建Netty项目
- Netty 服务器在 6668 端口监听,客户端能发送消息给服务器 “hello, 服务器~”
- 服务器可以回复消息给客户端 “hello, 客户端~”
- 目的:对Netty 线程模型 有一个初步认识,便于理解Netty 模型理论
- 编写服务端
- 编写客户端
- 对netty 程序进行分析,看看netty模型特点
代码:
服务端:
1 | package com.awo.netty.simple; |
服务端的Handler:
1 | package com.awo.netty.simple; |
客户端:
1 | package com.awo.netty.simple; |
客户端的Handler:
1 | package com.awo.netty.simple; |
6、相关问题以及解答
问题1:bossGroup与workerGroup含有的子线程的数量
解答:默认为CPU核数的两倍,即CPU核数*2
相关源码:
1 | // NioEventLoopGroup构造函数(空参) |
问题2:Netty服务端接收的新连接是如何绑定到worker线程池的(即worker线程池是怎么分配线程的)?
解答:通过==轮询==的方式,(假设worker线程的个数为8)首先为第一个连接分配线程1,接着为第二个连接分配线程2……然后为第八个连接分配线程8;如果之后还有连接到来的的话,在线程1空闲的情况下,会分配线程1到第九个连接。
问题3:ctx(上下文对象)里面包含的内容
ctx实际上是一个数据流,有着出站与入站(inbound 入站 ,outbound 出站)
问题4:channel与 pipeline 之间的关系
pipeline(管道) 本质上是一个双向链表,有着头尾指针。一个pipeline 与一个 channel对应,可以通过pipeline 获取到它对应的channel
channel(通道) :其中也包含了与channel对应的pipeline对象
7、任务队列中的 Task 有 3 种典型使用场景
如果当前有一个非常耗时长(长时间的操作)的业务,如果正常地放在handler中去执行的话,势必会造成pipeline的阻塞。因此,对于某些任务的执行可以提交到NioEventLoop的TaskQueue任务队列中去异步执行。其实TaskQueue与Channel之间存在绑定关系。对于这些任务有以下3种典型的应用:
- 用户程序自定义的普通任务
- 用户自定义定时任务
- 非当前 Reactor 线程调用 Channel 的各种方法
例如在推送系统的业务线程里面,根据用户的标识,找到对应的 Channel 引用,然后调用 Write 类方法向该用户推送消息,就会进入到这种场景。最终的 Write 会提交到任务队列中后被异步消费
将这些任务从handler中提交到channel对应的NIOEventLoop 的 TaskQueue的方法:
1、用户程序自定义的普通任务 -> 提交到该channel 对应的NioEventLoop 的 taskQueue中
1 | // 用户程序自定义的普通任务 |
注意:
该方法是通过ctx获得channel对象,在通过channel对象去获取该channel所在的evevtLoop,最后在将任务提交到eventLoop的taskQueue中
eventLoop会起一个线程去异步解决taskQueue当中的任务,==注意是一个线程==。如果taskQueue当中有多个任务的话,那么该线程会按照taskQueue中任务的顺序依次执行任务,即执行taskQueue任务的时间是累加的
- eg:taskQueue的第一个任务花费10s,taskQueue的第二个任务花费20s,那么该线程执行完taskQueue当中的任务总共要花费30s
解决方法:
在当前Handler中创建一个业务线程池,把耗时任务放到创建的线程池中执行。此时就变成了一个线程有一个业务线程池,来完成耗时任务的异步操作。(局部异步)
创建线程池的方法:
// 创建一个线程池,线程数为16 // 这里是用static 创建的全局线程池,即在整一个Handler都可以使用该业务线程池 static final EventExecutorGroup group = new DefaultEventExecutorGroup(16); // 调用一下方法将耗时任务放在线程池创建的线程中进行执行 group.sumbit(Callable task);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2. **在Server端中创建一个业务线程池(Context中添加线程池)**(整个异步)
- 创建线程池的方法:
- ```java
// 创建一个线程池,线程数为16
// 这里是用static 创建的全局线程池,即在整一个Handler都可以使用该业务线程池
static final EventExecutorGroup group = new DefaultEventExecutorGroup(16);
// 在ChannelInitializer的initChannel方法中
ChannelPipeline p = chpipeline();
// 在这里将group设置进去:如果这样设置的话,该handler会优先加入到该线程池中,这样一来,workerGroup主要接收任务 然后在将任务提交给线程池来处理。
// 默认没添加group的话,handler会进入workerLoopGroup的某一个workerLoop子线程
p.addLast(group,new MyServerHandler());
2、用户自定义定时任务 -> 提交到该channel 对应的NioEventLoop 的 scheduleTaskQueue中
1 | ctx.channel().eventLoop().schedule(new Runnable() { |
注意:
- 该任务在5s后执行
- sleep 需要占用线程资源,这5s线程啥都干不了,延时5s执行任务,这5s线程可以做别的事情
- taskQueue里的任务执行完毕后,会再执行scheduledtaskQueue。并且scheduled里的延迟时间是从taskQueue执行第一个任务之前开始算的
- 并且如果scheduled延迟时间若小于taskQueue里的总执行时间,在后者执行完后前者会立即执行,而不会在后者运行期间执行前者。
- 以上代码只是一个延迟任务,如果是定时任务的话还少了个参数,在第一个数字(延迟时间)后加一个间隔时间
3、非当前 Reactor 线程调用 Channel 的各种方法
1 | // 在Server端的ServerBootstrap的配置中的childHandler进行初始化的时候就可以将客户端的SocketChannel维护在一个集合里面,方便之后的获取 |
8、方案再说明
- Netty 抽象出两组线程池,BossGroup 专门负责接收客户端连接,WorkerGroup 专门负责网络读写操作。
- NioEventLoop 表示一个不断循环执行处理任务的线程,每个 NioEventLoop 都有一个 selector,用于监听绑定在其上的 socket 网络通道。
- NioEventLoop 内部采用==串行化设计==,从消息的读取->解码->处理->编码->发送,始终由 IO 线程 NioEventLoop 负责(如果在处理方面需要花费长时间的话就会阻塞这个流程,所以通常将花费长时间的任务放在taskQueue当中取异步执行)
- NioEventLoopGroup 下包含多个 NioEventLoop
- 每个 NioEventLoop 中包含有一个 Selector,一个 taskQueue
- 每个 NioEventLoop 的 Selector 上可以注册监听多个 NioChannel
- 每个 NioChannel 只会绑定在唯一的 NioEventLoop 上
- 每个 NioChannel 都绑定有一个自己的 ChannelPipeline
6、异步模型
1、基本介绍
- 异步的概念和同步相对。当一个异步过程调用发出后,调用者不能立刻得到结果。实际处理这个调用的组件在完成后,通过状态、通知和回调来通知调用者。
- Netty 中的 I/O 操作是异步的,包括 Bind、Write、Connect 等操作会简单的返回一个 ChannelFuture。
- 调用者并不能立刻获得结果,而是通过 ==Future-Listener 机制==,用户可以方便的主动获取或者通过通知机制获得 IO 操作结果
- Netty 的异步模型是建立在 future 和 callback 的之上的。callback 就是回调。重点说 Future,它的核心思想是:假设一个方法 fun,计算过程可能非常耗时,等待 fun返回显然不合适。那么可以在调用 fun 的时候,立马返回一个 Future,后续可以通过 Future去监控方法 fun 的处理过程(即 : Future-Listener 机制)
2、Future说明
表示异步的执行结果,可以通过它提供的方法来检测执行是否完成,比如检索计算等等。
ChannelFuture 是一个接口,我们可以添加监听器,当监听的事件发生时,就会通知到监听器。
public interface ChannelFuture extends Future<Void> {}
1
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
35
36
37
38
39
40
### 3、工作原理图
![image-20210819212841178](Netty/image-20210819212841178.png)
![image-20210819212905885](Netty/image-20210819212905885.png)
说明:
1. 在使用 Netty 进行编程时,拦截操作和转换出入站数据只需要您提供 callback 或利用future 即可。这使得**链式操作**简单、高效, 并有利于编写可重用的、通用的代码。
2. Netty 框架的目标就是让你的业务逻辑从网络基础应用编码中分离出来、解脱出来
### 4、Future-Listener 机制
1. 当 Future 对象刚刚创建时,处于非完成状态,调用者可以通过返回的 ChannelFuture 来获取操作执行的状态,注册监听函数来执行完成后的操作。
2. 常见有如下操作
- 通过 `isDone` 方法来**判断当前操作是否完成**;
- 通过 `isSuccess` 方法来**判断已完成的当前操作是否成功**;
- 通过 `getCause` 方法来**获取已完成的当前操作失败的原因**;
- 通过 `isCancelled` 方法来**判断已完成的当前操作是否被取消**;
- 通过 `addListener` 方法来注册监听器,**当操作已完成(isDone 方法返回完成),将会通知指定的监听器;如果 Future 对象已完成,则通知指定的监听器**
3. 举例说明
- 演示:绑定端口是异步操作,当绑定操作处理完,将会调用相应的监听器处理逻辑
- ```java
serverBootstrap.bind(port).addListener(future -> {
if(future.isSuccess()) {
System.out.println(newDate() + ": 端口["+ port + "]绑定成功!");
} else{
System.err.println("端口["+ port + "]绑定失败!");
}
});
小结:相比传统阻塞 I/O,执行 I/O 操作后线程会被阻塞住,直到操作完成;异步处理的好处是不会造成线程阻塞,线程在 I/O 操作期间可以执行别的程序,在高并发情形下会更稳定和更高的吞吐量。
5、快速入门实例——HTTP服务
- 实例要求:使用IDEA 创建Netty项目
- Netty 服务器在 7777端口监听,浏览器发出请求 “http://localhost:7777/ “
- 服务器可以回复消息给客户端 “Hello! 我是服务器 5 “ ,并对特定请求资源进行过滤。
- 目的:Netty 可以做Http服务开发,并且理解Handler实例和客户端及其请求的关系。
- 效果:
代码:
Server
1 | package com.awo.netty.http; |
TestServerInitializer:
1 | package com.awo.netty.http; |
TestHttpServerHandler:
1 | package com.awo.netty.http; |
注意:
- Http是无状态协议,而且建立的一般都是长链接,所以在刷新浏览器后,服务端会为本次的http请求创建新的handler和pipeline(一个handler与一个pipeline对应,为一组。多个http请求就会有多组handler与pipeline)
7、Netty 核心模块组件
1、Bootstrap、ServerBootstrap
- Bootstrap 意思是引导,一个 Netty 应用通常由一个 Bootstrap 开始,主要作用是配置整个 Netty 程序,串联各个组件。
- Netty 中
Bootstrap
类是==客户端==程序的启动引导类,ServerBootstrap
是==服务端==启动引导类
常见的方法有:
1 | // 该方法用于服务器端,用来设置两个 EventLoop |
2、Channel
- Netty 网络通信的组件,能够用于执行网络 I/O 操作。
- 通过Channel 可获得 当前网络连接的通道的状态
- 通过Channel 可获得 网络连接的配置参数 (例如接收缓冲区大小)
- 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。
3、Selector
- Netty 基于 Selector 对象实现 I/O 多路复用,通过 Selector 一个线程可以监听多个连接的 Channel 事件。
- 当向一个 Selector 中注册 Channel 后,Selector 内部的机制就可以自动不断地查询(Select) 这些注册的 Channel 是否有已就绪的 I/O 事件(例如可读,可写,网络连接完成等),这样程序就可以很简单地使用一个线程高效地管理多个 Channel
4、ChannelHandler 及其实现类
- ChannelHandler 是一个接口,处理 I/O 事件或拦截 I/O 操作,并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。
- ChannelHandler 本身并没有提供很多方法,因为这个接口有许多的方法需要实现,方便使用期间,可以继承它的子类
ChannelHandler 及其实现类一览图:
ChannelInboundHandler
:用于处理入站 I/O 事件。ChannelOutboundHandler
:用于处理出站 I/O 操作。
适配器模式:
ChannelInboundHandlerAdapter
:用于处理入站 I/O 事件。ChannelOutboundHandlerAdapter
:用于处理出站 I/O 操作。ChannelDuplexHandler
:用于处理入站和出站事件。
为什么ChannelDuplexHandler既能解决入站事件,又能解决出站事件?
查看ChannelDuplexHandler的实现
1 | public class ChannelDuplexHandler extends ChannelInboundHandlerAdapter implements ChannelOutboundHandler {...} |
- ChannelDuplexHandler继承了ChannelInboundHandlerAdapter类,所以能解决入站事件
- ChannelDuplexHandler实现了ChannelOutboundHandler接口,所以能解决出站事件
我们经常需要自定义一个 Handler 类去继承 ChannelInboundHandlerAdapter,然后通过重写相应方法实现业务逻辑,我们接下来看看一般都需要重写哪些方法:
1 | public class ChannelInboundHandlerAdapter extends ChannelHandlerAdapter implements ChannelInboundHandler { |
ChannelInboundHandlerAdapter的所有实现方法:
5、Pipeline 和 ChannelPipeline
ChannelPipeline 是一个重点:
ChannelPipeline 是一个 Handler 的集合,它负责处理和拦截 inbound 或者 outbound 的事件和操作,相当于一个贯穿 Netty 的链。(也可以这样理解:ChannelPipeline 是 保存 ChannelHandler 的 List,用于处理或拦截 Channel 的入站事件和出站操作)
ChannelPipeline 实现了一种高级形式的拦截过滤器模式,使用户可以完全控制事件的处理方式,以及 Channel 中各个的 ChannelHandler 如何相互交互
在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应,它们的组成关系如下
一个 Channel 包含了一个 ChannelPipeline,而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表,并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler
可以通过Channel拿到ChannelPipeline,也可以通过ChannelPipeline拿到Channel(双方都包含对方的引用)
ChannelHandlerContext实际上是一个接口,在双向链表当中的ChannelHandlerContext实际上是ChannelHandlerContext的实现类
DefaultChannelHandlerContext
public interface ChannelHandlerContext extends AttributeMap, ChannelInboundInvoker, ChannelOutboundInvoker {...}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
- 入站事件和出站事件在一个双向链表中,入站事件会从链表 head 往后传递到最后一个入站的 handler,出站事件会从链表 tail 往前传递到最前一个出站的 handler,两种类型的 handler 互不干扰
- ChannelPipeline提供了ChannelHandler链的容器。以==客户端==应用程序为例:
- **如果事件的运动方向是从客户端到服务端的,那么我们称这些事件为出站的**,即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler,并被这些Handler处理,以上图就是从链表 tail 往前传递到最前一个出站的 handler (head)
- **如果事件的运动方向是从服务端到客户端的,那么我们称这些事件为入站的**,即服务端发送给客户端的数据会通过pipeline中的一系列ChannelInboundHandler,并被这些Handler处理,以上图就是从链表 head 往后传递到最后一个入站的 handler(tail)。
- 前面客户端和服务端都是Inbound是因为他们都要读对方的消息,读取对方的消息就是入站
4. 常用方法
- ```java
// 把一个业务处理类(handler)添加到链中的第一个位置
ChannelPipeline addFirst(ChannelHandler... handlers);
// 把一个业务处理类(handler)添加到链中的最后一个位置
ChannelPipeline addLast(ChannelHandler... handlers);
6、ChannelHandlerContext
保存 Channel 相关的所有上下文信息,同时关联一个 ChannelHandler 对象
即ChannelHandlerContext 中包含一个具体的事件处理器 ChannelHandler , 同时ChannelHandlerContext 中也绑定了对应的 pipeline 和 Channel 的信息,方便对 ChannelHandler进行调用。
常用方法
// 关闭通道 ChannelFuture close(); // 刷新 ChannelOutboundInvoker flush(); // 将数据写到 ChannelPipeline 中当前ChannelHandler 的下一个 ChannelHandler 开始处理(出站) ChannelFuture writeAndFlush(Object msg);
1
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
### 7、ChannelOption
1. Netty 在创建 Channel 实例后,一般都需要设置 ChannelOption 参数。
2. ChannelOption 参数如下:
- `ChannelOption.SO_BACKLOG`:对应 TCP/IP 协议 listen 函数中的 backlog 参数,**用来初始化服务器可连接队列大小**。服务端处理客户端连接请求是顺序处理的,所以同一时间只能处理一个客户端连接。多个客户端来的时候,服务端将不能处理的客户端连接请求放在队列中等待处理,backlog 参数指定了队列的大小。
- `ChannelOption.SO_KEEPALIVE`:一直保持连接活动状态
### 8、EventLoopGroup 和其实现类 NioEventLoopGroup
1. EventLoopGroup 是一组 EventLoop 的抽象,Netty 为了更好的利用多核 CPU 资源,一般会有多个 EventLoop 同时工作,每个 EventLoop 维护着一个 Selector 实例。
2. EventLoopGroup 提供 next 接口,可以从组里面按照一定规则获取其中一个 EventLoop来处理任务。在 Netty ==服务器端==编程中,我们一般都需要提供两个 EventLoopGroup,例如:`BossEventLoopGroup` 和 `WorkerEventLoopGroup`。
3. 通常一个服务端口,即一个 ServerSocketChannel 对应一个Selector 和一个EventLoop线程。BossEventLoop 负责接收客户端的连接并将 SocketChannel 交给 WorkerEventLoopGroup 来进行 IO 处理,如下图所示
- ![image-20210820000928747](Netty/image-20210820000928747.png)
- BossEventLoopGroup 通常是一个单线程的 EventLoop,EventLoop 维护着一个注册了ServerSocketChannel 的 Selector 实例,BossEventLoop 不断轮询 Selector 将连接事件分离出来
- 通常是 `OP_ACCEPT` 事件,然后将接收到的 SocketChannel 交给 WorkerEventLoopGroup
- WorkerEventLoopGroup 会由 next 选择其中一个 EventLoop来将这个 SocketChannel 注册到其维护的 Selector 并对其后续的 IO 事件进行处理
4. 常用方法
- ```java
// 构造方法
public NioEventLoopGroup();
// 断开连接,关闭线程
public Future<?> shutdownGracefully();
9、Unpooled 类
Netty 提供一个专门用来操作缓冲区(即Netty的数据容器)的工具类
常用方法如下所示
//通过给定的数据和字符编码返回一个 ByteBuf 对象(类似于 NIO 中的 ByteBuffer 但有区别) public static ByteBuf copiedBuffer(CharSequence string, Charset charset)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
![image-20210820003558340](Netty/image-20210820003558340.png)
```java
// 创建一个ByteBuf
ByteBuf buffer = Unpooled.buffer(10);
// 常用方法
// 写入
buffer.writeByte(i);
// 读取
buffer.readByte();
// 根据下标读取
buffer.getByte(i);
// 获取buffer的长度
buffer.capacity();
结合上图与代码对ByteBuf进行讲解:
- 创建一个ByteBuf对象,该对象包含一个数组arr , 是一个byte[10]
- 在netty 的ByteBuf中,不需要先nio中的ByteBuffer一样,使用flip 进行读写反转
- 原因:netty 的ByteBuf在底层维护了两个变量:
readerindex
和writerIndex
(双指针模式)。其中- readerindex:用于记录ByteBuf读时的位置
- writerIndex:用于记录ByteBuf写时的位置
- netty 的ByteBuf在底层还维护了一个重要的变量:
capacity
——用来保存ByteBuf的底层byte[]数组的长度 - 通过这3个变量的合作,完成了netty的ByteBuf的读写相关操作
- 原因:netty 的ByteBuf在底层维护了两个变量:
- 通过 readerindex 和 writerIndex 和 capacity, 将buffer分成三个区域(从上图可以看出)
- [0,readerindex):已经读取的区域
- [readerindex,writerIndex):可读的区域
- [writerIndex,capacity):可写的区域
- 在ByteBuf读取的方法中,有着 getByte(int) 与 readByte()两个方法,两者的区别:
- 对于readByte()方法:readerindex会随着readByte()方法的执行而增加
- 对于getByte(int)方法:readerindex不会随着readByte()方法的执行而增加
- 对于ByteBuf的写方法:writeByte()——writerIndex会随着writeByte()方法的执行而增加
- 注意:
- 如果使用了ByteBuf的readByte()方法进行读取的时候,由于readerindex会随着readByte()方法的执行而增加,所以在进行第二次读取的时候会发生数组下标越界异常,需要我们调用ByteBuf的
readerIndex(int readIndex)
方法重新设置读取位置。
- 如果使用了ByteBuf的readByte()方法进行读取的时候,由于readerindex会随着readByte()方法的执行而增加,所以在进行第二次读取的时候会发生数组下标越界异常,需要我们调用ByteBuf的
也可以通过以下方法创建一个ByteBuf对象:
1 | //创建ByteBuf |
ByteBuf的一些API:
1 | // 查看当前的ByteBuf是否有数组支撑 |
注意:通过这种方式创建出来的bytebuf对象的底层实际上是
UnpooledByteBufAllocator
的内部类InstrumentedUnpooledUnsafeHeapByteBuf
类型。
10、Netty应用实例-群聊系统
实例要求:
- 编写一个 Netty 群聊系统,实现服务器端和客户端之间的数据简单通讯(非阻塞)
- 实现多人群聊
- 服务器端:可以监测用户上线,离线,并实现消息转发功能
- 客户端:通过channel 可以无阻塞发送消息给其它所有用户,同时可以接受其它用户发送的消息(有服务器转发得到)
- 目的:进一步理解Netty非阻塞网络编程机制
- 效果:
代码:
服务器端
1 | package com.awo.netty.groupchat; |
服务器端的handler:
1 | package com.awo.netty.groupchat; |
客户端:
1 | package com.awo.netty.groupchat; |
客户端的handler:
1 | package com.awo.netty.groupchat; |
sync()是因为:本身bootstrap里的任务如:监听器等等是异步的。所以适用此方法等待异步方法处理完毕再完成启动
11、Netty心跳检测机制案例
实例要求:
- 编写一个 Netty心跳检测机制案例, 当服务器超过3秒没有读时,就提示读空闲
- 当服务器超过5秒没有写操作时,就提示写空闲
- 实现当服务器超过7秒没有读或者写操作时,就提示读写空闲
代码:
服务器端:
1 | package com.atguigu.netty.heartbeat; |
服务器的handler:
1 | package com.atguigu.netty.heartbeat; |
对于以上代码的几点说明:
**handler(new LoggingHandler(LogLevel.INFO));**:这代码的作用是在bossGroup开启日志处理
IdleStateHandler
类的相关说明:IdleStateHandler 是netty 提供的处理空闲状态的处理器
文档说明:==triggers an {@link IdleStateEvent} when a {@link Channel} has not performed read, write, or both operation for a while.==
public class IdleStateHandler extends ChannelDuplexHandler { public IdleStateHandler(long readerIdleTime, long writerIdleTime, long allIdleTime, TimeUnit unit) { this(false, readerIdleTime, writerIdleTime, allIdleTime, unit); } }
1
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
- IdleStateHandler继承了ChannelDuplexHandler,说明了它既能处理入站事件,也能处理出站事件
- IdleStateHandler的构造方法的参数说明:
1. **long readerIdleTime**:表示多长时间没有读,就会发送一个心跳检测包检测是否连接
2. **long writerIdleTime**:表示多长时间没有写,就会发送一个心跳检测包检测是否连接
3. **long allIdleTime**:表示多长时间没有读写,就会发送一个心跳检测包检测是否连接
4. **TimeUnit unit**:时间单位
- 当 IdleStateEvent 触发后,就会传递给管道 的下一个handler去处理
* 通过调用(触发)下一个handler 的 `userEventTiggered`方法,在该方法中去处理 IdleStateEvent(读空闲,写空闲,读写空闲)
### 12、Netty 通过WebSocket编程实现服务器和客户端长连接
实例要求:
1. Http协议是无状态的, 浏览器和服务器间的请求响应一次,下一次会重新创建连接.
2. 要求:实现基于webSocket的长连接的全双工的交互
3. 改变Http协议多次请求的约束,实现长连接了, 服务器可以发送消息给浏览器
4. 客户端浏览器和服务器端会相互感知,比如服务器关闭了,浏览器会感知,同样浏览器关闭了,服务器会感知
5. 效果:
- ![image-20210820001859808](Netty/image-20210820001859808.png)
代码:
服务器端:(ChannelInitializer<SocketChannel>当中的内容,其他与上面类似)
```java
serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
//因为基于http协议,使用http的编码和解码器
pipeline.addLast(new HttpServerCodec());
//是以块方式写,添加ChunkedWriteHandler处理器
pipeline.addLast(new ChunkedWriteHandler());
/*
说明
1. http数据在传输过程中是分段, HttpObjectAggregator ,就是可以将多个段聚合
2. 这就就是为什么,当浏览器发送大量数据时,就会发出多次http请求
*/
pipeline.addLast(new HttpObjectAggregator(8192));
/*
说明
1. 对应websocket ,它的数据是以 帧(frame) 形式传递
2. 可以看到WebSocketFrame 下面有六个子类
3. 浏览器请求时 ws://localhost:7000/hello 表示请求的uri
4. WebSocketServerProtocolHandler 核心功能是将 http协议升级为 ws协议 , 保持长连接
*/
pipeline.addLast(new WebSocketServerProtocolHandler("/hello2"));
//自定义的handler ,处理业务逻辑
pipeline.addLast(new MyTextWebSocketFrameHandler());
}
});
服务器端的Handler:
1 | package com.atguigu.netty.websocket; |
对以上代码的几点说明:
- 由于建立的是webSocket长连接,http为短连接,需要将http协议升级为ws协议
- 对于http:
- http数据在传输过程中是分段传输,所以需要添加
HttpObjectAggregator
,可以将多个段的数据进行聚合 - 这就就是为什么,当浏览器发送大量数据时,就会发出多次http请求
- http数据在传输过程中是分段传输,所以需要添加
- 对于webSocket:
- webSocket的数据是以 帧(frame) 形式传递,所以在进行数据处理的时候都是以帧为单位进行处理的
- 对于ws协议:
- 浏览器请求时 ws://localhost:7000/xxx:表示请求的uri
- http协议升级为ws协议的方法:是通过一个 状态码
101
- netty与ws协议的一些方法:
- webSocket数据对应类:
WebSocketFrame
,其下有六个子类,分别应用在不同的场景 WebSocketServerProtocolHandler
:核心功能是将 http协议升级为 ws协议,保持长连接
- webSocket数据对应类:
8、Google Protobuf
1、编码和解码的基本介绍
- 编写网络应用程序时,因为数据在网络中传输的都是二进制字节码数据,在发送数据时就需要编码,接收数据时就需要解码
- codec(编解码器) 的组成部分有两个:
decoder(解码器)
和encoder(编码器)
。- encoder:负责把业务数据转换成字节码数据
- decoder:负责把字节码数据转换成业务数据
2、Netty 本身的编码解码的机制和问题分析
- Netty 自身提供了一些 codec(编解码器)
- Netty 提供的编码器encoder
- StringEncoder:对字符串数据进行编码
- ObjectEncoder:对 Java 对象进行编码
- ……
- Netty 提供的解码器decoder
- StringDecoder:对字符串数据进行解码
- ObjectDecoder:对 Java 对象进行解码
- ……
- Netty 本身自带的 ObjectDecoder 和 ObjectEncoder 可以用来实现 POJO 对象或各种业务对象的编码和解码,底层使用的仍是 Java 序列化技术,而Java 序列化技术本身效率就不高,存在如下问题:
- 无法跨语言
- 序列化后的体积太大,是二进制编码的 5 倍多。
- 序列化性能太低
- => 引出 新的解决方案 [Google 的 Protobuf]
3、Protobuf
1、Protobuf基本介绍和使用示意图
- Protobuf 是 Google 发布的开源项目,全称 Google Protocol Buffers,是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC[远程过程调用 remote procedure call ] 数据交换格式 。
目前很多公司将http+json
替换成tcp+protobuf
- 参考文档 :语言指南
- Protobuf 是以
message
的方式来管理数据的 - 支持跨平台、跨语言,即[客户端和服务器端可以是不同的语言编写的] (支持目前绝大多数语言,例如 C++、C#、Java、python 等)
- 高性能,高可靠性
- 使用 protobuf 编译器能自动生成代码,Protobuf 是将类的定义使用.proto 文件进行描述。
- 说明,在idea 中编写 .proto 文件时,会自动提示是否下载 .ptotot 编写插件. 可以让语法高亮。
- 然后通过 protoc.exe 编译器根据.proto 自动生成.java 文件
- protobuf 使用示意图:
2、Netty中Protobuf的使用流程
在Maven 项目中引入 Protobuf 坐标,下载相关的jar包
<dependencies> <dependency> <groupId>com.google.protobuf</groupId> <artifactId>protobuf-java</artifactId> <version>3.6.1</version> </dependency> </dependencies>
1
2
3
4
5
6
7
8
9
10
11
2. 在IDEA创建.proto文件,进行.proto文件的编写(以Student.proto为例)
- ```protobuf
syntax = "proto3"; //版本
option java_outer_classname = "StudentPOJO";//生成的外部类名,同时也是文件名
//protobuf 使用message 管理数据
message Student { //会在 StudentPOJO 外部类生成一个内部类 Student, 他是真正发送的POJO对象
int32 id = 1; // Student 类中有一个属性 名字为 id 类型为int32(protobuf类型) 1表示属性序号,不是值
string name = 2;
}
利用protoc.exe 编译器对刚刚编写好的.proto文件进行编译,生成一个java文件
执行指令(cmd)
protoc.exe --java_out=. Student.proto
1
2
3
4
5
6
7
8
9
10
- idea里面也可以下载相应的maven插件进行编译:有工具mave protobuf-java-util
4. 之后会生成一个Student.java文件
- 这里主要是看两点:
- ```java
// DO NOT EDIT!
public static final class Student extends com.google.protobuf.GeneratedMessageV3 implements // 说明真正的PoJo 类是Student
把生成的 StudentPoJo.java 拷贝到自己的项目中打开
在项目的服务端
ChannelInitializer<SocketChannel>
中的initChannel
方法里面添加解码的handler(服务端<—>解码),在解码的handler中添加StudentPOJO.Student.getDefaultInstance()
serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {//创建一个通道初始化对象(匿名对象) //给pipeline 设置处理器 @Override protected void initChannel(SocketChannel ch) throws Exception { ChannelPipeline pipeline = ch.pipeline(); //在pipeline加入ProtoBufDecoder //指定对哪种对象进行解码 pipeline.addLast("decoder", new ProtobufDecoder(StudentPOJO.Student.getDefaultInstance())); pipeline.addLast(new NettyServerHandler()); } }); // 给我们的workerGroup 的 EventLoop 对应的管道设置处理器
1
2
3
4
5
6
7
8
9
10
11
12
13
7. 在项目的客户端`ChannelInitializer<SocketChannel>`中的`initChannel`方法里面添加编码的handler(客户端<--->编码)
- ```java
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
//在pipeline中加入 ProtoBufEncoder
pipeline.addLast("encoder", new ProtobufEncoder());
pipeline.addLast(new NettyClientHandler()); //加入自己的处理器
}
});
在服务端的自定义handler中可以选择继承
SimpleChannelInboundHandler
并设置泛型StudentPOJO.Student
,这样一来重写的channelRead0
方法的第二个参数就变成了StudentPOJO.Student msg
(而不是Object,还需要我们去判断Object类型向下转型),我可以通过该msg获取Student的相关信息而在客户端就需要我们去生成一个StudentPOJO.Student,往StudentPOJO.Student设置一些信息:
StudentPOJO.Student student = StudentPOJO.Student.newBuilder().setId(4).setName("智多星 吴用").build();
1
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#### 3、使用Protobuf的几点说明
1. Protobuf是以`message`的方式来管理数据的
2. 在.proto文件的编写中使用message声明的变量,在之后生成java文件后会成为java文件的内部类,也是真正存储PoJo 类信息的地方,使用option java_outer_classname方式生成的类对象其实是java的外部类,包裹着存储PoJo 类信息的内部类
3. java PoJo 类的属性数据类型 与 Protobuf文件中的属性数据类型的对比:
![image-20210821025959285](Netty/image-20210821025959285.png)
4. 在Protobuf文件中 `int32 id = 1`中的`1`并不是属性的值,而是该属性在Protobuf文件的属性序号,即该属性是Protobuf文件的第几个属性(**从1开始**)
5. 通过以上的项目的服务端与客户端可以发现一个问题:项目的handler与PoJo的耦合很高。基本上一个handler只能为一个PoJo服务
6. 解决方法:**Protobuf可以使用 message 管理其他的message**
7. Protobuf文件中可以使用一个总的message作为大包裹,里面包含了各式各样的PoJo信息——使用枚举的方式(注意:**在proto3 要求enum的编号从0开始**)
- ```protobuf
syntax = "proto3";
option optimize_for = SPEED; // 加快解析
option java_package="com.atguigu.netty.codec2"; //指定生成到哪个包下
option java_outer_classname="MyDataInfo"; // 外部类名, 文件名
//protobuf 可以使用message 管理其他的message
message MyMessage {
//定义一个枚举类型
enum DataType {
StudentType = 0; //在proto3 要求enum的编号从0开始
WorkerType = 1;
}
//用data_type 来标识传的是哪一个枚举类型
DataType data_type = 1;
//表示每次枚举类型最多只能出现其中的一个, 节省空间
oneof dataBody {
Student student = 2;
Worker worker = 3;
}
}
message Student {
int32 id = 1;//Student类的属性
string name = 2; //
}
message Worker {
string name=1;
int32 age=2;
}
这样的话,在服务端的
ChannelInitializer<SocketChannel>
中的initChannel
方法的里面ProtobufDecoder
的里面就不能写某个PoJo的getDefaultInstance(),而是得写整个大包裹的getDefaultInstance()pipeline.addLast("decoder", new ProtobufDecoder(MyDataInfo.MyMessage.getDefaultInstance()));
1
2
3
4
5
6
7
8
9
10
9. 各种PoJo的信息的设置与获取在各自的handler中
- 设置(客户端)
- ```java
MyDataInfo.MyMessage myMessage = null;
myMessage = MyDataInfo.MyMessage.newBuilder().setDataType(MyDataInfo.MyMessage.DataType.StudentType).setStudent(MyDataInfo.Student.newBuilder().setId(5).setName("玉麒麟 卢俊义").build()).build();
myMessage = MyDataInfo.MyMessage.newBuilder().setDataType(MyDataInfo.MyMessage.DataType.WorkerType).setWorker(MyDataInfo.Worker.newBuilder().setAge(20).setName("老李").build()).build();获取(服务端)(继承的SimpleChannelInboundHandler的泛型要修改成大包裹:
MyDataInfo.MyMessage
)//根据dataType 来显示不同的信息 MyDataInfo.MyMessage.DataType dataType = msg.getDataType(); if(dataType == MyDataInfo.MyMessage.DataType.StudentType) { MyDataInfo.Student student = msg.getStudent(); System.out.println("学生id=" + student.getId() + " 学生名字=" + student.getName()); } else if(dataType == MyDataInfo.MyMessage.DataType.WorkerType) { MyDataInfo.Worker worker = msg.getWorker(); System.out.println("工人的名字=" + worker.getName() + " 年龄=" + worker.getAge()); } else { System.out.println("传输的类型不正确"); }
1
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
35
36
37
38
39
40
41
42
43
44
45
46
-----
## 9、Netty编解码器和handler的调用机制
### 1、基本说明
1. netty的组件设计:Netty的主要组件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等
2. **ChannelHandler充当了处理入站和出站数据的应用程序逻辑的容器**。例如,实现ChannelInboundHandler接口(或ChannelInboundHandlerAdapter),你就可以接收入站事件和数据,这些数据会被业务逻辑处理。当要给客户端发送响应时,也可以从ChannelInboundHandler冲刷数据。业务逻辑通常写在一个或者多个ChannelInboundHandler中。ChannelOutboundHandler原理一样,只不过它是用来处理出站数据的。
3. **ChannelPipeline提供了ChannelHandler链的容器**。**以客户端应用程序为例,如果事件的运动方向是从客户端到服务端的,那么我们称这些事件为出站的,即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler,并被这些Handler处理**,反之则称为入站的
![image-20210821034142241](Netty/image-20210821034142241.png)
### 2、编码解码器
1. **当Netty发送或者接受一个消息的时候,就将会发生一次数据转换。==入站消息会被解码==:从字节转换为另一种格式(比如java对象);如果是==出站消息,它会被编码成字节==**。
2. **Netty提供一系列实用的编解码器,他们都实现了ChannelInboundHadnler或者ChannelOutboundHandler接口。在这些类中,channelRead方法已经被重写了**。以入站为例,对于每个从入站Channel读取的消息,这个方法会被调用。随后,它将调用由解码器所提供的decode()方法进行解码,并将已经解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。
### 3、解码器——ByteToMessageDecoder(服务器端,入站)
1. 关系继承图
- ![image-20210821034417112](Netty/image-20210821034417112.png)
2. **由于不可能知道远程节点是否会一次性发送一个完整的信息,==tcp有可能出现粘包拆包的问题==**,这个类会对入站数据进行缓冲,直到它准备好被处理。
3. 一个关于ByteToMessageDecoder实例分析
- ```java
public class ToIntegerDecoder extends ByteToMessageDecoder {
// 读取一个int类型
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
if (in.readableBytes() >= 4) {
out.add(in.readInt());
}
}
}
说明:
- 这个例子,每次入站从ByteBuf中读取4字节,将其解码为一个int,然后将它添加到下一个List中。当没有更多元素可以被添加到该List中时,它的内容将会被发送给下一个ChannelInboundHandler。int在被添加到List中时,会被自动装箱为Integer。
- 在调用readInt()方法前必须验证所输入的ByteBuf是否具有足够的数据。
- 关于if还是while的问题,”decode”方法确实会被循环调用,只要还有可读就会一直循环,除非”decode”没有再读出数据,则会退出循环。
- 所以如果把”if”改成”while”也是可以的没有区别,相当于自己先把buf处理完了,外层循环就不会再调用了
- decode 会根据接收的数据,被调用多次,直到确定没有新的元素被添加到list,或者是ByteBuf 没有更多的可读字节为止
- 如果list out 不为空,就会将list的内容传递给下一个 channelinboundhandler处理,该channelinboundhandler的方法也会被调用多次(不管是if还是while,因为循环调用的依据是list的内容)
Netty的handler链的调用机制
实例要求:使用自定义的编码器和解码器来说明Netty的handler 调用机制
- 客户端发送long -> 服务器
- 服务端发送long -> 客户端
思路:
注意:
- ctx.write 会去调用outbound的方法
- outbound一定要放到最后一个inbound之前,保证inbound在write的时候,可以往前找到outbound
代码:
自定义编码器:
1 | import io.netty.buffer.ByteBuf; |
自定义解码器:
1 | import io.netty.buffer.ByteBuf; |
服务端:
1 | import io.netty.bootstrap.ServerBootstrap; |
服务端的处理器的初始化:MyServerInitializer
1 | import io.netty.channel.ChannelInitializer; |
服务端的自定义处理器:MyServerHandler
1 | import io.netty.channel.ChannelHandlerContext; |
客户端:
1 | import io.netty.bootstrap.Bootstrap; |
客户端的处理器的初始化:MyClientInitializer
1 | import io.netty.channel.ChannelInitializer; |
客户端的自定义处理器:MyServerHandler
1 | import io.netty.buffer.Unpooled; |
执行流程:
结论:
不论解码器handler 还是 编码器handler 即接收的消息类型必须与待处理的消息类型一致,否则该handler不会被执行
底层调用了父类 MessageToByteEncoder的write方法,源码:
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception { ByteBuf buf = null; try { //判断当前msg 是不是应该处理的类型,如果是就处理,不是就跳过encode if (acceptOutboundMessage(msg)) { @SuppressWarnings("unchecked") I cast = (I) msg; buf = allocateBuffer(ctx, cast, preferDirect); try { encode(ctx, cast, buf); } finally { ReferenceCountUtil.release(cast); } if (buf.isReadable()) { ctx.write(buf, promise); } else { buf.release(); ctx.write(Unpooled.EMPTY_BUFFER, promise); } buf = null; } else { ctx.write(msg, promise); } }
1
2
3
4
5
6
7
8
9
- **在解码器 进行数据解码时,需要判断 缓存区(ByteBuf)的数据是否足够 ,否则接收到的结果会期望结果可能不一致**
### 4、解码器——ReplayingDecoder(客户端,出站)
1. ```java
public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder
ReplayingDecoder扩展了ByteToMessageDecoder类,使用这个类,我们不必调用readableBytes()方法。参数S指定了用户状态管理的类型,其中
Void
代表不需要状态管理ReplayingDecoder使用方便,但它也有一些局限性:
- 并不是所有的 ByteBuf 操作都被支持,如果调用了一个不被支持的方法,将会抛出一个
UnsupportedOperationException
。 - ReplayingDecoder 在某些情况下可能稍慢于 ByteToMessageDecoder,例如网络缓慢并且消息格式复杂时,消息会被拆成了多个碎片,速度变慢
- 并不是所有的 ByteBuf 操作都被支持,如果调用了一个不被支持的方法,将会抛出一个
5、其它编解码器
- 其它解码器:
LineBasedFrameDecoder
:这个类在Netty内部也有使用,它使用行尾控制字符(\n或者\r\n)作为分隔符来解析数据。DelimiterBasedFrameDecoder
:使用自定义的特殊字符作为消息的分隔符。HttpObjectDecoder
:一个HTTP数据的解码器LengthFieldBasedFrameDecoder
:通过指定长度来标识整包消息,这样就可以自动的处理==黏包==和==半包==消息。
- 其它编码器:
- 例子:如果客户端传输大量数据到服务端的时候,为了节省时间与开销。可以在客户端使用
ZlibEncoder
对数据进行压缩编码,然后在服务端使用ZlibDecoder
进行压缩阶码就能得到数据。这些操作Netty都帮助我们完成了,我们只需要在将Initializer对象的initChennel方法中将对应的编解码器加入pipeline当中
6、Log4j 整合到Netty
在Maven 中添加对Log4j的依赖 在 pom.xml
<dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.7.25</version> <scope>test</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.7.25</version> <scope>test</scope> </dependency>
1
2
3
4
5
6
7
8
2. 配置 Log4j,在 resources/log4j.properties
- ```properties
log4j.rootLogger=DEBUG, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%p] %C{1} - %m%n
演示:
10、TCP 粘包和拆包 及解决方案
1、TCP 粘包和拆包基本介绍
- TCP是面向连接的,面向流的,提供高可靠性服务。收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发给接收端的包,更有效的发给对方,使用了优化方法(==Nagle算法==),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样做虽然提高了效率,但是接收端就难于分辨出完整的数据包了,因为面向流的通信是无消息保护边界的
- 由于TCP无消息保护边界,需要在接收端处理消息边界问题,也就是我们所说的粘包、拆包问题,看一张图:
- 客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到字节数是不确定的,故可能存在以下四种情况:
- 服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包
- 服务端一次接受到了两个数据包,D1和D2粘合在一起,称之为==TCP粘包==
- 服务端分两次读取到了数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,这称之为==TCP拆包==
- 服务端分两次读取到了数据包,第一次读取到了D1包的部分内容D1_1,第二次读取到了D1包的剩余部分内容D1_2和完整的D2包。
2、TCP 粘包和拆包解决方案
- 使用自定义协议 + 编解码器 来解决
- 关键就是要解决 服务器端每次读取数据长度的问题,这个问题解决,就不会出现服务器多读或少读数据的问题,从而避免的TCP 粘包、拆包 。
看一个具体的实例:
- 要求客户端发送 5 个 Message 对象,客户端每次发送一个 Message 对象
- 服务器端每次接收一个Message,分5次进行解码, 每读取到 一个Message,会回复一个Message 对象 给客户端。
代码:
由于我们是自定义协议,需要我们编写一个协议包类,规定每次发送的协议包的内容和大小(重要)
1 | //协议包 |
由于我们是自定义协议,需要我们自定义编解码器,将我们自定义的协议包进行编解码
编码器:
1 | import io.netty.buffer.ByteBuf; |
解码器:
1 | import io.netty.buffer.ByteBuf; |
服务器端:
1 | import io.netty.bootstrap.ServerBootstrap; |
1 | import io.netty.bootstrap.ServerBootstrap; |
1 | import io.netty.buffer.ByteBuf; |
客户端:
1 | import io.netty.bootstrap.Bootstrap; |
1 | import io.netty.channel.ChannelInitializer; |
1 | import io.netty.buffer.ByteBuf; |
效果:
客户端:
服务端:
调用流程说明:
- 客户端发送5条数据到服务端(编码5次)
- 服务端调用解码器将客户端发送过来的数据进行解码,收到信息后,发送一个协议包给客户端(编码1次),由于客户端发送了5条数据,所以这个过程会执行5次
- 客户端接收到服务端发送过来的协议包,调用解码器进行解码,接收数据。由于服务端会回发5次数据,所以客户端也会接收到5次数据,每一次接收都要调用一次解码器进行数据解码
- 由于数据都是通过自定义的协议包进行传输的,协议包中规定了每一次传输的数据的长度,所以不会出现TCP的粘包拆包问题。
11、Netty 核心源码剖析
1、Netty 启动过程源码剖析
说明:
- 源码需要剖析到Netty 调用doBind方法, 追踪到 NioServerSocketChannel的doBind
- 并且要Debug 程序到 NioEventLoop类 的run代码 ,无限循环,在服务器端运行。
Netty启动过程梳理:
- 创建2个 EventLoopGroup 线程池数组。数组默认大小CPU*2,方便chooser选择线程池时提高性能
- BootStrap 将 boss 设置为 group属性,将 worker 设置为 childer 属性
- 通过 bind 方法启动,内部重要方法为
initAndRegister
和dobind
方法 - initAndRegister 方法会反射创建 NioServerSocketChannel 及其相关的 NIO 的对象, pipeline , unsafe,同时也为 pipeline 初始了 head 节点和 tail 节点。
- 在
register0
方法成功以后调用在dobind
方法中调用doBind0
方法,该方法会 调用 NioServerSocketChannel 的 doBind 方法对 JDK 的 channel 和端口进行绑定,完成 Netty 服务器的所有启动,并开始监听连接事件
2、Netty 接受请求过程源码剖析
说明:
- 从之前服务器启动的源码中,我们得知,服务器最终注册了一个 Accept 事件等待客户端的连接。我们也知道,NioServerSocketChannel 将自己注册到了 boss 单例线程池(reactor 线程)上,也就是 EventLoop 。
- 先简单说下EventLoop的逻辑(后面我们详细讲解EventLoop)
- EventLoop 的作用是一个死循环,而这个循环中做3件事情:
- 有条件的等待 Nio 事件。
- 处理 Nio 事件。
- 处理消息队列中的任务。
- EventLoop 的作用是一个死循环,而这个循环中做3件事情:
- 仍用前面的项目来分析:进入到 NioEventLoop 源码中后,在
private void processSelectedKey(SelectionKey k, AbstractNioChannel ch)
方法开始调试 - 最终我们要分析到AbstractNioChannel 的
doBeginRead
方法, 当到这个方法时,针对于这个客户端的连接就完成了,接下来就可以监听读事件了
Netty接受请求过程梳理:
总体流程:
接受连接 —–> 创建一个新的NioSocketChannel ———–> 注册到一个 worker EventLoop 上 ——–> 注册selecot Read 事件。
- 服务器轮询 Accept 事件,获取事件后调用 unsafe 的 read 方法,这个 unsafe 是 ServerSocket 的内部类,该方法内部由2部分组成
- doReadMessages 用于创建 NioSocketChannel 对象,该对象包装 JDK 的 Nio Channel 客户端。该方法会像创建 ServerSocketChanel 类似创建相关的 pipeline , unsafe,config
- 随后执行 pipeline.fireChannelRead 方法,并将自己绑定到一个 chooser 选择器选择的 workerGroup 中的一个 EventLoop。并且注册一个0,表示注册成功,但并没有注册读(1)事件
3、Pipeline Handler HandlerContext创建源码剖析
- 每当创建 ChannelSocket 的时候都会创建一个绑定的 pipeline,一对一的关系,创建 pipeline 的时候也会创建 tail 节点和 head 节点,形成最初的链表。
- 在调用 pipeline 的 addLast 方法的时候,会根据给定的 handler 创建一个 Context,然后将这个 Context 插入到链表的尾端(tail 前面)。
- Context 包装 handler,多个 Context 在 pipeline 中形成了双向链表
- 入站方向叫 inbound,由 head 节点开始,出站方法叫 outbound ,由 tail 节点开始
4、ChannelPipeline 调度 handler 的源码剖析
- 当一个请求进来的时候,ChannelPipeline 是如何调用内部的这些 handler 的呢?
- 首先,当一个请求进来的时候,会第一个调用 pipeline 的 相关方法,如果是入站事件,这些方法由 fire 开头,表示开始管道的流动。让后面的 handler 继续处理
ChannelPipeline 调度 handler 梳理:
- Context 包装 handler,多个 Context 在 pipeline 中形成了双向链表,入站方向叫 inbound,由 head 节点开始,出站方法叫 outbound ,由 tail 节点开始。
- 而节点中间的传递通过 AbstractChannelHandlerContext 类内部的 fire 系列方法,找到当前节点的下一个节点不断的循环传播。是一个过滤器形式完成对handler 的调度
5、Netty 心跳(heartbeat)服务源码剖析
Netty 作为一个网络框架,提供了诸多功能,比如编码解码等,Netty 还提供了非常重要的一个服务——心跳机制heartbeat。通过心跳检查对方是否有效,这是 RPC 框架中是必不可少的功能。
说明:
- Netty 提供了
IdleStateHandler
,ReadTimeoutHandler
,WriteTimeoutHandler
三个Handler 检测连接的有效性,重点分析 IdleStateHandler 。
hasOutputChanged
流程图:
6、Netty 核心组件 EventLoop 源码剖析
eventloop继承图:
handler 中加入线程池和Context 中添加线程池的源码剖析
- 在 Netty 中做耗时的,不可预料的操作,比如数据库,网络请求,会严重影响 Netty 对 Socket 的处理速度。
- 而解决方法就是将耗时任务添加到异步线程池中。但就添加线程池这步操作来讲,可以有2种方式,而且这2种方式实现的区别也蛮大的。
- 处理耗时业务的第一种方式——handler 中加入线程池
- 处理耗时业务的第二种方式——Context 中添加线程池
将这些任务从handler中提交到channel对应的NIOEventLoop 的 TaskQueue的方法:
用户程序自定义的普通任务 -> 提交到该channel 对应的NioEventLoop 的 taskQueue中
1 | // 用户程序自定义的普通任务 |
注意:
该方法是通过ctx获得channel对象,在通过channel对象去获取该channel所在的evevtLoop,最后在将任务提交到eventLoop的taskQueue中
eventLoop会起一个线程去异步解决taskQueue当中的任务,==注意是一个线程==。如果taskQueue当中有多个任务的话,那么该线程会按照taskQueue中任务的顺序依次执行任务,即执行taskQueue任务的时间是累加的
- eg:taskQueue的第一个任务花费10s,taskQueue的第二个任务花费20s,那么该线程执行完taskQueue当中的任务总共要花费30s
解决方法:
在当前Handler中创建一个业务线程池,把耗时任务放到创建的线程池中执行。此时就变成了一个线程有一个业务线程池,来完成耗时任务的异步操作。(局部异步)
创建线程池的方法:
// 创建一个线程池,线程数为16 // 这里是用static 创建的全局线程池,即在整一个Handler都可以使用该业务线程池 static final EventExecutorGroup group = new DefaultEventExecutorGroup(16); // 调用一下方法将耗时任务放在线程池创建的线程中进行执行 group.sumbit(Callable task);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2. **在Server端中创建一个业务线程池(Context中添加线程池)**(整个异步)
- 创建线程池的方法:
- ```java
// 创建一个线程池,线程数为16
// 这里是用static 创建的全局线程池,即在整一个Handler都可以使用该业务线程池
static final EventExecutorGroup group = new DefaultEventExecutorGroup(16);
// 在ChannelInitializer的initChannel方法中
ChannelPipeline p = chpipeline();
// 在这里将group设置进去:如果这样设置的话,该handler会优先加入到该线程池中,这样一来,workerGroup主要接收任务 然后在将任务提交给线程池来处理。
// 默认没添加group的话,handler会进入workerLoopGroup的某一个workerLoop子线程
p.addLast(group,new MyServerHandler());
流程图:
12、用Netty 自己 实现 dubbo RPC
1、RPC基本介绍
- RPC(Remote Procedure Call)——远程过程调用,是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程
- 两个或多个应用程序都分布在不同的服务器上,它们之间的调用都像是本地方法调用一样
- 常见的 RPC 框架有:比较知名的如:
- 阿里的Dubbo
- google的gRPC
- Go语言的rpcx
- Apache的thrift
- Spring 旗下的 Spring Cloud
2、RPC调用流程
1、RPC调用流程图
术语说明:在RPC 中, Client 叫服务消费者,Server 叫服务提供者
2、RPC调用流程说明
- 服务消费方(client)以本地调用方式调用服务
- client stub 接收到调用后负责将方法、参数等封装成能够进行网络传输的消息体
- client stub 将消息进行编码并发送到服务端
- server stub 收到消息后进行解码
- server stub 根据解码结果调用本地的服务
- 本地服务执行并将结果返回给 server stub
- server stub 将返回导入结果进行编码并发送至消费方
- client stub 接收到消息并进行解码
- 服务消费方(client)得到结果
小结:RPC 的目标就是将 2-8 这些步骤都封装起来,用户无需关心这些细节,可以像调用本地方法一样即可完成远程服务调用。
3、自己实现 dubbo RPC(基于Netty)
1、需求说明
- dubbo 底层使用了 Netty 作为网络通讯框架,要求用 Netty 实现一个简单的 RPC 框架
- 模仿 dubbo,消费者和提供者约定接口和协议,消费者远程调用提供者的服务,提供者返回一个字符串,消费者打印提供者返回的数据。底层网络通信使用 Netty 4.1.20
2、设计说明
- 创建一个接口,定义抽象方法。用于消费者和提供者之间的约定。
- 创建一个提供者,该类需要监听消费者的请求,并按照约定返回数据。
- 创建一个消费者,该类需要透明的调用自己不存在的方法,内部需要使用 Netty 请求提供者返回数据