Netty 是什么?
- Netty 是一个 基于 NIO 的 client-server(客户端服务器)框架,使用它可以快速简单地开发网络应用程序。
- 它极大地简化并优化了 TCP 和 UDP 套接字服务器等网络编程,并且性能以及安全性等很多方面甚至都要更好。
用官方的总结就是:Netty 成功地找到了一种在不妥协可维护性和性能的情况下实现易于开发,性能,稳定性和灵活性的方法。
为啥不直接用NIO呢?
不用NIO主要是因为NIO的编程模型复杂而且存在一些BUG,并且对编程功底要求比较高。下图就是一个典型的使用 NIO 进行编程的案例:而且,NIO在面对断连重连、包丢失、粘包等问题时处理过程非常复杂。Netty的出现正是为了解决这些问题,更多关于Netty的特点可以看下面的内容。
Netty 应用场景了解么?
- 作为 RPC 框架的网络通信工具 : 我们在分布式系统中,不同服务节点之间经常需要相互调用,这个时候就需要 RPC 框架了。不同服务指点的通信是如何做的呢?可以使用 Netty 来做。比如我调用另外一个节点的方法的话,至少是要让对方知道我调用的是哪个类中的哪个方法以及相关参数吧!
- 实现一个自己的 HTTP 服务器 :通过 Netty 我们可以自己实现一个简单的 HTTP 服务器,这个大家应该不陌生。说到 HTTP 服务器的话,作为 Java 后端开发,我们一般使用 Tomcat 比较多。一个最基本的 HTTP 服务器可要以处理常见的 HTTP Method 的请求,比如 POST 请求、GET 请求等等。
- 实现一个即时通讯系统 : 使用 Netty 我们可以实现一个可以聊天类似微信的即时通讯系统,这方面的开源项目还蛮多的,可以自行去 Github 找一找。
- 实现消息推送系统 :市面上有很多消息推送系统都是基于 Netty 来做的。
- 我们平常经常接触的 Dubbo、RocketMQ、Elasticsearch、gRPC 等等都用到了 Netty。
Reactor线程模型
(线程模型->主从Reactor、BossGroup、WorkerGroup区别、EventLoopGroup与线程池的关系、EventLoop、Pipeline、ChannelHandler、Context))
(NIO介绍一下(Selector、Channel、ByteBuffer,IO多路复用,底层的select、poll、epoll(这里我只是了解,不清楚具体实现))
总结:
- BossGroup: 用于处理客户端的 TCP 连接请求。
- WorkerGroup: 负责每一条连接的具体读写数据的处理逻辑,真正负责 I/O 读写操作,交由对应的 Handler 处理。
- EventLoopGroup和EventLoop: EventLoopGroup包含多个 EventLoop(每一个 EventLoop 通常内部包含一个线程),它管理着所有的 EventLoop 的生命周期。并且,
EventLoop
处理的 I/O 事件都将在它专有的Thread
上被处理,即Thread
和EventLoop
属于 1 : 1 的关系,从而保证线程安全。 - Channel:
Channel
为 Netty 网络读写等操作的接口,EventLoop
处理连接中所发生的事件,两者配合进行 I/O 操作。每个channel都会分配一个EventLoop - Pipeline: 一个
Channel
包含一个ChannelPipeline
。ChannelPipeline
为ChannelHandler
的链,一个 pipeline 上可以有多个ChannelHandler
- ChannelHandler:
ChannelHandler
是消息的具体处理器,主要负责处理客户端/服务端接收和发送的数据。
ChannelPipeline上通过
addLast()方法添加一个或者多个
ChannelHandler(一个数据或者事件可能会被多个 Handler 处理) 。当一个
ChannelHandler处理完之后就将数据交给下一个
ChannelHandler` 。
- Context:
当 ChannelHandler
被添加到的 ChannelPipeline
它得到一个 ChannelHandlerContext
,它代表一个 ChannelHandler
和 ChannelPipeline
之间的“绑定”。 ChannelPipeline
通过 ChannelHandlerContext
来间接管理 ChannelHandler
。
异步: 监听器的回调⽅法operationComplete(),将会在对应的操作完成时被调⽤。 然后监听器可以判断该操作是成功地完成了还是出错了。 c 每个 Netty 的出站 I/O 操作都将返回⼀个 ChannelFuture,也就是说, 它们都不会阻塞。所以说,Netty完全是异步和事件驱动的。
Reactor是一种经典的线程模型,Reactor模式基于事件驱动,特别适合处理海量的I/O事件。
Reactor线程模型分为单线程模型、多线程模型以及主从多线程模型。
以下图片来源于网络,原出处不明,如有侵权请联系我。
单线程Reactor
所有的IO操作都由同一个NIO线程处理。
1 | //1.eventGroup既用于处理客户端连接,又负责具体的处理。 |
单线程Reactor
多线程Reactor
一个线程负责接受请求,一组NIO线程处理IO操作。
多线程Reactor
1 | // 1.bossGroup 用于接收连接,workerGroup 用于具体的处理 |
主从多线程Reactor
一组NIO线程负责接受请求,一组NIO线程处理IO操作。
1 | // 1.bossGroup 用于接收连接,workerGroup 用于具体的处理 |
Bytebuf(字节容器)
网络通信最终都是通过字节流进行传输的。 ByteBuf
就是 Netty 提供的一个字节容器,其内部是一个字节数组。 当我们通过 Netty 传输数据的时候,就是通过 ByteBuf
进行的。
我们可以将 ByteBuf
看作是 Netty 对 Java NIO 提供了 ByteBuffer
字节容器的封装和抽象。
Channel(网络操作抽象类)
Channel
接口是 Netty 对网络操作抽象类。通过 Channel
我们可以进行 I/O 操作。
一旦客户端成功连接服务端,就会新建一个 Channel
同该用户端进行绑定,示例代码如下:
1 | // 通过 Bootstrap 的 connect 方法连接到服务端 |
比较常用的Channel
接口实现类是 :
NioServerSocketChannel
(服务端)NioSocketChannel
(客户端)
这两个 Channel
可以和 BIO 编程模型中的ServerSocket
以及Socket
两个概念对应上。
EventLoop(事件循环)
EventLoop 介绍
说白了,EventLoop
的主要作用实际就是责监听网络事件并调用事件处理器进行相关 I/O 操作(读写)的处理。
Channel 和 EventLoop 的关系
那 Channel
和 EventLoop
直接有啥联系呢?
Channel
为 Netty 网络操作(读写等操作)抽象类,EventLoop
负责处理注册到其上的Channel
的 I/O 操作,两者配合进行 I/O 操作。
EventloopGroup 和 EventLoop 的关系
EventLoopGroup
包含多个 EventLoop
(每一个 EventLoop
通常内部包含一个线程),它管理着所有的 EventLoop
的生命周期。
并且,EventLoop
处理的 I/O 事件都将在它专有的 Thread
上被处理,即 Thread
和 EventLoop
属于 1 : 1 的关系,从而保证线程安全。
下图是 Netty NIO 模型对应的 EventLoop
模型。通过这个图应该可以将EventloopGroup
、EventLoop
、 Channel
三者联系起来。
https://www.jianshu.com/p/128ddc36e713
ChannelHandler(消息处理器) 和 ChannelPipeline(ChannelHandler 对象链表)
下面这段代码使用过 Netty 的小伙伴应该不会陌生,我们指定了序列化编解码器以及自定义的 ChannelHandler
处理消息。
1 | b.group(eventLoopGroup) |
ChannelHandler
是消息的具体处理器,主要负责处理客户端/服务端接收和发送的数据。
当 Channel
被创建时,它会被自动地分配到它专属的 ChannelPipeline
。 一个Channel
包含一个 ChannelPipeline
。 ChannelPipeline
为 ChannelHandler
的链,一个 pipeline 上可以有多个 ChannelHandler
。
我们可以在 ChannelPipeline
上通过 addLast()
方法添加一个或者多个ChannelHandler
(_一个数据或者事件可能会被多个 Handler 处理_) 。当一个 ChannelHandler
处理完之后就将数据交给下一个 ChannelHandler
。
当 ChannelHandler
被添加到的 ChannelPipeline
它得到一个 ChannelHandlerContext
,它代表一个 ChannelHandler
和 ChannelPipeline
之间的“绑定”。 ChannelPipeline
通过 ChannelHandlerContext
来间接管理 ChannelHandler
。
https://www.javadoop.com/post/netty-part-4
ChannelFuture(操作执行结果)
1 | public interface ChannelFuture extends Future<Void> { |
Netty 是异步非阻塞的,所有的 I/O 操作都为异步的。
因此,我们不能立刻得到操作是否执行成功,但是,你可以通过 ChannelFuture
接口的 addListener()
方法注册一个 ChannelFutureListener
,当操作执行成功或者失败时,监听就会自动触发返回结果。
1 | ChannelFuture f = b.connect(host, port).addListener(future -> { |
并且,你还可以通过ChannelFuture
的 channel()
方法获取连接相关联的Channel
。
1 | Channel channel = f.channel(); |
另外,我们还可以通过 ChannelFuture
接口的 sync()
方法让异步的操作编程同步的。
1 | //bind()是异步的,但是,你可以通过 `sync()`方法将其变为同步。 |
NioEventLoopGroup 默认的构造函数会起多少线程?
综上,我们发现 NioEventLoopGroup
默认的构造函数实际会起的线程数为 CPU核心数\*2
。
Netty 服务端和客户端的启动过程了解么?
服务端
1 | // 1.bossGroup 用于接收连接,workerGroup 用于具体的处理 |
简单解析一下服务端的创建过程具体是怎样的:
1.首先你创建了两个 NioEventLoopGroup
对象实例:bossGroup
和 workerGroup
。
bossGroup
: 用于处理客户端的 TCP 连接请求。workerGroup
: 负责每一条连接的具体读写数据的处理逻辑,真正负责 I/O 读写操作,交由对应的 Handler 处理。
2.接下来 我们创建了一个服务端启动引导/辅助类: ServerBootstrap
,这个类将引导我们进行服务端的启动工作。
3.通过 .group()
方法给引导类 ServerBootstrap
配置两大线程组,确定了线程模型。
通过下面的代码,我们实际配置的是多线程模型,这个在上面提到过。
1 | EventLoopGroup bossGroup = new NioEventLoopGroup(1); |
4.通过channel()
方法给引导类 ServerBootstrap
指定了 IO 模型为NIO
NioServerSocketChannel
:指定服务端的 IO 模型为 NIO,与 BIO 编程模型中的ServerSocket
对应NioSocketChannel
: 指定客户端的 IO 模型为 NIO, 与 BIO 编程模型中的Socket
对应
5.通过 .childHandler()
给引导类创建一个ChannelInitializer
,然后指定了服务端消息的业务处理逻辑 HelloServerHandler
对象
6.调用 ServerBootstrap
类的 bind()
方法绑定端口
客户端
1 | //1.创建一个 NioEventLoopGroup 对象实例 |
继续分析一下客户端的创建流程:
1.创建一个 NioEventLoopGroup
对象实例
2.创建客户端启动的引导类是 Bootstrap
3.通过 .group()
方法给引导类 Bootstrap
配置一个线程组
4.通过channel()
方法给引导类 Bootstrap
指定了 IO 模型为NIO
5.通过 .childHandler()
给引导类创建一个ChannelInitializer
,然后指定了客户端消息的业务处理逻辑 HelloClientHandler
对象
6.调用 Bootstrap
类的 connect()
方法进行连接,这个方法需要指定两个参数:
inetHost
: ip 地址inetPort
: 端口号
1 | public ChannelFuture connect(String inetHost, int inetPort) { |
connect
方法返回的是一个 Future
类型的对象
1 | public interface ChannelFuture extends Future<Void> { |
也就是说这个方是异步的,我们通过 addListener
方法可以监听到连接是否成功,进而打印出连接信息。具体做法很简单,只需要对代码进行以下改动:
1 | ChannelFuture f = b.connect(host, port).addListener(future -> { |
什么是 TCP 粘包/拆包?有什么解决办法呢?
👨💻面试官 :什么是 TCP 粘包/拆包?
🙋 我 :TCP 粘包/拆包 就是你基于 TCP 发送数据的时候,出现了多个字符串“粘”在了一起或者一个字符串被“拆”开的问题。比如你多次发送:“你好,你真帅啊!哥哥!”,但是客户端接收到的可能是下面这样的:
👨💻面试官 :那有什么解决办法呢?
🙋 我 :
1.使用 Netty 自带的解码器
LineBasedFrameDecoder
: 发送端发送数据包的时候,每个数据包之间以换行符作为分隔,LineBasedFrameDecoder
的工作原理是它依次遍历ByteBuf
中的可读字节,判断是否有换行符,然后进行相应的截取。DelimiterBasedFrameDecoder
: 可以自定义分隔符解码器,LineBasedFrameDecoder
实际上是一种特殊的DelimiterBasedFrameDecoder
解码器。FixedLengthFrameDecoder
: 固定长度解码器,它能够按照指定的长度对消息进行相应的拆包。LengthFieldBasedFrameDecoder
:LengthFieldBasedFrameDecoder解码器自定义长度
2.自定义序列化编解码器
在 Java 中自带的有实现 Serializable
接口来实现序列化,但由于它性能、安全性等原因一般情况下是不会被使用到的。
通常情况下,我们使用 Protostuff、Hessian2、json 序列方式比较多,另外还有一些序列化性能非常好的序列化方式也是很好的选择:
Netty 长连接、心跳机制了解么?
👨💻面试官 :TCP 长连接和短连接了解么?
所谓,短连接说的就是 server 端 与 client 端建立连接之后,读写完成之后就关闭掉连接,如果下一次再要互相发送消息,就要重新连接。短连接的有点很明显,就是管理和实现都比较简单,缺点也很明显,每一次的读写都要建立连接必然会带来大量网络资源的消耗,并且连接的建立也需要耗费时间。
长连接说的就是 client 向 server 双方建立连接之后,即使 client 与 server 完成一次读写,它们之间的连接并不会主动关闭,后续的读写操作会继续使用这个连接。长连接的可以省去较多的 TCP 建立和关闭的操作,降低对网络资源的依赖,节约时间。对于频繁请求资源的客户来说,非常适用长连接。
👨💻面试官 :为什么需要心跳机制?Netty 中心跳机制了解么?
🙋 我 :
在 TCP 保持长连接的过程中,可能会出现断网等网络异常出现,异常发生的时候, client 与 server 之间如果没有交互的话,它们是无法发现对方已经掉线的。为了解决这个问题, 我们就需要引入 心跳机制 。
心跳机制的工作原理是: 在 client 与 server 之间在一定时间内没有数据交互时, 即处于 idle 状态时, 客户端或服务器就会发送一个特殊的数据包给对方, 当接收方收到这个数据报文后, 也立即发送一个特殊的数据报文, 回应发送方, 此即一个 PING-PONG 交互。所以, 当某一端收到心跳消息后, 就知道了对方仍然在线, 这就确保 TCP 连接的有效性.
通过 Netty 实现心跳机制的话,核心类是 IdleStateHandler
。
Netty 的零拷贝了解么?
👨💻面试官 :讲讲 Netty 的零拷贝?
🙋 我 :
维基百科是这样介绍零拷贝的:
零复制(英语:Zero-copy;也译零拷贝)技术是指计算机执行操作时,CPU 不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省 CPU 周期和内存带宽。
在 OS 层面上的 Zero-copy
通常指避免在 用户态(User-space)
与 内核态(Kernel-space)
之间来回拷贝数据。而在 Netty 层面 ,零拷贝主要体现在对于数据操作的优化。
Netty 中的零拷贝体现在以下几个方面
- 使用 Netty 提供的
CompositeByteBuf
类, 可以将多个ByteBuf
合并为一个逻辑上的ByteBuf
, 避免了各个ByteBuf
之间的拷贝。 ByteBuf
支持 slice 操作, 因此可以将 ByteBuf 分解为多个共享同一个存储区域的ByteBuf
, 避免了内存的拷贝。- 通过
FileRegion
包装的FileChannel.tranferTo
实现文件传输, 可以直接将文件缓冲区的数据发送到目标Channel
, 避免了传统通过循环 write 方式导致的内存拷贝问题.