netty实战

最新推荐文章于 2024-07-31 20:40:14 发布

阿拉斯加大闸蟹

最新推荐文章于 2024-07-31 20:40:14 发布

阅读量1w

点赞数 2

分类专栏： netty

本文链接：https://blog.csdn.net/singgel/article/details/117950068

版权

netty 专栏收录该内容

11 篇文章 1 订阅

订阅专栏

首先先自己熟悉一下selector、epoll、NIO编程、reactor模型

I/O 模型基本说明 I/O 模型简单的理解：就是用什么样的通道进行数据的发送和接收，很大程度上决定了程序通信的性能

Java共支持3种网络编程模型/IO模式：BIO、NIO、AIO

Java BIO ：同步并阻塞(传统阻塞型)，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销
BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序简单易理解。
Java NIO ：同步非阻塞，服务器实现模式为一个线程处理多个请求(连接)，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求就进行处理
NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，弹幕系统，服务器间通讯等。编程比较复杂，JDK1.4开始支持。
Java AIO(NIO.2) ：异步非阻塞，AIO 引入异步通道的概念，采用了 Proactor 模式，简化了程序编写，有效的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

Selector

Channel注册到Selector，Selector能够检测到Channel是否有事件发生。

如果有事件发生，则进行相应的处理。这样可以实现一个线程管理多个Channel（即多个连接和请求）只有通道真正有读写事件发生时，才会进行读写。

减少了创建的线程数，降低了系统开销，减少了上下文的切换，用户态和系统态的切换

以ServerSocketChannel为例说明：

当有客户端连接时，ServerSocketChannel会返回一个SocketChannel
SocketChannel注册到Selector。（register方法）
register方法会返回一个SelectionKey，SelectionKey与Channel关联
Selector监听select方法，返回有事件的个数
进一步得到SelectionKey
通过SelectionKey获取SocketChannel（SelectionKey中的channel方法）
通过获取的channel，执行业务处理

NIO与零拷贝：

传统IO

mmap优化：

mmap 通过内存映射，将文件映射到内核缓冲区，同时，用户空间可以共享内核空间的数据。这样，在进行网络传输时，就可以减少内核空间到用户控件的拷贝次数。如下图

sendFile优化：

Linux 2.1 版本提供了 sendFile 函数，其基本原理如下：数据根本不经过用户态，直接从内核缓冲区进入到 Socket Buffer，同时，由于和用户态完全无关，就减少了一次上下文切换

提示：零拷贝从操作系统角度，是没有cpu 拷贝

Linux 在 2.4 版本中，做了一些修改，避免了从内核缓冲区拷贝到 Socket buffer 的操作，直接拷贝到协议栈，从而再一次减少了数据拷贝。具体如下图和小结：这里其实有一次cpu 拷贝 kernel buffer -> socket buffer 但是，拷贝的信息很少，比如 lenght , offset , 消耗低，可以忽略

reactor模型

IO复用解释：I/O复用就是单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流.

这个作者我感觉讲的很好，最起码是他自己的理解：IO复用

线程模型基本介绍：

传统阻塞 I/O 服务模型

采用阻塞IO模式获取输入的数据
每个连接都需要独立的线程完成数据的输入，业务处理, 数据返回
当并发数很大，就会创建大量的线程，占用很大系统资源
连接创建后，如果当前线程暂时没有数据可读，该线程会阻塞在read 操作，造成线程资源浪费

Reactor 模式中核心组成：

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

Reactor 模式

单 Reactor 单线程

Select 是前面 I/O 复用模型介绍的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求

Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发

果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理

如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应

Handler 会完成 Read→业务处理→Send 的完整业务流程

优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点：性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈

缺点：可靠性问题，线程意外终止，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

使用场景：客户端的数量有限，业务处理非常快速，比如 Redis在业务处理的时间复杂度 O(1) 的情况

单 Reactor 多线程

Reactor 对象通过select 监控客户端请求事件, 收到事件后，通过dispatch进行分发

如果建立连接请求, 则右Acceptor 通过 accept 处理连接请求, 然后创建一个Handler对象处理完成连接后的各种事件

如果不是连接请求，则由reactor分发调用连接对应的handler 来处理

handler 只负责响应事件，不做具体的业务处理, 通过read 读取数据后，会分发给后面的worker线程池的某个线程处理业务

worker 线程池会分配独立线程完成真正的业务，并将结果返回给handler

handler收到响应后，通过send 将结果返回给client

优点：可以充分的利用多核cpu 的处理能力

缺点：多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行，在高并发场景容易出现性能瓶颈.

主从 Reactor 多线程

Reactor主线程 MainReactor 对象通过select 监听连接事件, 收到事件后，通过Acceptor 处理连接事件

当 Acceptor 处理连接事件后，MainReactor 将连接分配给SubReactor

subreactor 将连接加入到连接队列进行监听,并创建handler进行各种事件处理

当有新事件发生时， subreactor 就会调用对应的handler处理

handler 通过read 读取数据，分发给后面的worker 线程处理

worker 线程池分配独立的worker 线程进行业务处理，并返回结果

handler 收到响应的结果后，再通过send 将结果返回给client

Reactor 主线程可以对应多个Reactor 子线程, 即MainRecator 可以关联多个SubReactor

优点：父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理。

优点：父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。

缺点：编程复杂度较高

这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持

Netty 线程模式(Netty 主要基于主从 Reactor 多线程模型做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor)

基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象等待，无需阻塞等待所有连接。当某个连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理
基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。
I/O 复用结合线程池，就是 Reactor 模式基本设计思想
Reactor 模式，通过一个或多个输入同时传递给服务处理器的模式(基于事件驱动)
服务器端程序处理传入的多个请求,并将它们同步分派到相应的处理线程，因此Reactor模式也叫 Dispatcher模式
Reactor 模式使用IO复用监听事件, 收到事件后，分发给某个线程(进程), 这点就是网络服务器高并发处理关键

响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的

可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销

扩展性好，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源

复用性好，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性

netty模型：

netty抽象出两组线程池BossGroup专门负责接收客户端的连接，WorkGroup专门负责网络的读写
BossGroup和WorkGroup类型都是NIOEventLoopGroup
NIOEventLoopGroup相当于一个事件循环组，这个组中有多个事件循环，每个事件循环是NIOEventLoop
NIOEventLoop表示一个不断循环的执行处理任务的线程，每个NIOEventLoop都有一个selector，用于监听绑定在其上的socket的网络通讯
NIOEventLoopGroup可以有多个线程，即可以含有多个NIOEventLoop
每个BossNIOEventLoop的执行步骤有3步：
1.轮询accept事件
2.处理accept事件，与client建立连接生成NIOSocketChannel，并将其注册到某个worker NIOEventLoop上的selector上去（根据他的算法）
3.处理任务队列的任务，即runAllTasks
每个Worker NIOEventLoop循环执行的步骤
1.轮询read、write事件
2.处理IO事件，即read、write事件，在对应的NIOSocketChannel上进行处理
3.处理任务队列的任务，即runAllTasks
每个worker NIOEventLoop在处理业务时，会使用到pipeline（管道），pipeline中包含了channel，即通过pipeline可以获取到对应的通道。pipeline中维护了很多的处理器

netty处理流程：

Netty 抽象出两组线程池，BossGroup 专门负责接收客户端连接，WorkerGroup 专门负责网络读写操作。
NioEventLoop 表示一个不断循环执行处理任务的线程，每个 NioEventLoop 都有一个 selector，用于监听绑定在其上的 socket 网络通道。
NioEventLoop 内部采用串行化设计，从消息的读取->解码->处理->编码->发送，始终由 IO 线程 NioEventLoop 负责 NioEventLoopGroup 下包含多个 NioEventLoop

 每个 NioEventLoop 中包含有一个 Selector，一个 taskQueue

 每个 NioEventLoop 的 Selector 上可以注册监听多个 NioChannel

 每个 NioChannel 只会绑定在唯一的 NioEventLoop 上

 每个 NioChannel 都绑定有一个自己的 ChannelPipeline

pipeline功能：

pipeline的适配器里面有一个ChannelHandlerContext上下文对象，含有管道pipeline、通道channel、地址
用户程序自定义的普通任务：ctx.channel().eventLoop().execute(。。。); 用户自定义定时任务：ctx.channel().eventLoop().schedule(。。。); 非当前Reactor线程调用channel的各种方法：initChannel开始的时候将用户标识与socketChannel绑定（例如HashMap，这个估计就是雪球IM的实现部分了，如何将channel和各个uid绑定起来维护连接关系上下线，根据雪球公开文档描述应该是采用的akka的工具包实现的）

netty的异步模型：

表示异步的执行结果, 可以通过它提供的方法来检测执行是否完成，比如检索计算等等.
ChannelFuture 是一个接口：我们可以添加监听器，当监听的事件发生时，就会通知到监听器.
在使用 Netty 进行编程时，拦截操作和转换出入站数据只需要您提供 callback 或利用future 即可。这使得链式操作简单、高效, 并有利于编写可重用的、通用的代码。
Netty 框架的目标就是让你的业务逻辑从网络基础应用编码中分离出来、解脱出来
future-listener:相比传统阻塞 I/O，执行 I/O 操作后线程会被阻塞住, 直到操作完成；异步处理的好处是不会造成线程阻塞，线程在 I/O 操作期间可以执行别的程序，在高并发情形下会更稳定和更高的吞吐量

netty核心组件：

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。

selector

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

channelHandler

ChannelHandler 是一个接口，处理 I/O 事件或拦截 I/O 操作，并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。
ChannelHandler 本身并没有提供很多方法，因为这个接口有许多的方法需要实现，方便使用期间，可以继承它的子类
ChannelHandler 及其实现类一览图

Pipeline 和 ChannelPipeline

ChannelPipeline 是一个 Handler 的集合，它负责处理和拦截 inbound 或者 outbound 的事件和操作，相当于一个贯穿 Netty 的链。(也可以这样理解：ChannelPipeline 是保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站操作)
ChannelPipeline 实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互
在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应，它们的组成关系如下：

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

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

ChannelHandlerContext

保存 Channel 相关的所有上下文信息，同时关联一个 ChannelHandler 对象
即ChannelHandlerContext 中包含一个具体的事件处理器 ChannelHandler ，同时ChannelHandlerContext 中也绑定了对应的 pipeline 和 Channel 的信息，方便对 ChannelHandler进行调用.
常用方法：

ChannelFuture close()，关闭通道

ChannelOutboundInvoker flush()，刷新

ChannelFuture writeAndFlush(Object msg) ，将数据写到 ChannelPipeline 中当前

ChannelHandler 的下一个 ChannelHandler 开始处理（出站）

ChannelOption

Netty 在创建 Channel 实例后,一般都需要设置 ChannelOption 参数。
ChannelOption 参数如下:

ChannelOption.SO_BACKLOG ：对应 TCP/IP 协议 listen 函数中的 backlog 参数，用来初始化服务器可连接队列大小。服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接。多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，backlog 参数指定了队列的大小。

ChannelOption.SO_KEEPALIVE ：一直保持连接活动状态

EventLoopGroup 和其实现类 NioEventLoopGroup

EventLoopGroup 是一组 EventLoop 的抽象，Netty 为了更好的利用多核 CPU 资源，一般会有多个 EventLoop 同时工作，每个 EventLoop 维护着一个 Selector 实例。
EventLoopGroup 提供 next 接口，可以从组里面按照一定规则获取其中一个 EventLoop来处理任务。在 Netty 服务器端编程中，我们一般都需要提供两个 EventLoopGroup，例如：BossEventLoopGroup 和 WorkerEventLoopGroup。
通常一个服务端口即一个 ServerSocketChannel对应一个Selector 和一个EventLoop线程。BossEventLoop 负责接收客户端的连接并将 SocketChannel 交给 WorkerEventLoopGroup 来进行 IO 处理

Unpooled

Netty 提供一个专门用来操作缓冲区(即Netty的数据容器)的工具类
常用方法如下所示

//通过给定的数据和字符编码返回一个 ByteBuf 对象（类似于 NIO 中的 ByteBuffer 但有区别）

public static ByteBuf copiedBuffer(CharSequence string, Charset charset)

netty心跳

IdelStateHandler

http是无状态，Http协议是无状态的, 浏览器和服务器间的请求响应一次，下一次会重新创建连接，webSocket的长连接的全双工的交互，改变Http协议多次请求的约束，实现长连接了，服务器可以发送消息给浏览器

http传输过程中是分段的，HttpObjectAggregator可以将多个段聚合

浏览器在发送大量数据的时候，就会发出多次http请求

对应websocket，他的数据以帧（frame）的形式传递

WebSocketServerProtocolHandler核心功能是将http协议升级为ws协议，保持长连接

http协议升级ws协议，是通过一个状态码101

netty编码解码

编写网络应用程序时，因为数据在网络中传输的都是二进制字节码数据，在发送数据时就需要编码，接收数据时就需要解码

codec(编解码器) 的组成部分有两个：decoder(解码器)和 encoder(编码器)。encoder 负责把业务数据转换成字节码数据，decoder 负责把字节码数据转换成业务数据

Netty 本身的编码解码的机制和问题分析

Netty 自身提供了一些 codec(编解码器)

Netty 提供的编码器：StringEncoder，对字符串数据进行编码 ObjectEncoder，对 Java 对象进行编码

Netty 提供的解码器：StringDecoder, 对字符串数据进行解码 ObjectDecoder，对 Java 对象进行解码

Netty 本身自带的 ObjectDecoder 和 ObjectEncoder 可以用来实现 POJO 对象或各种业务对象的编码和解码，底层使用的仍是 Java 序列化技术 , 而Java 序列化技术本身效率就不高，存在如下问题

无法跨语言

序列化后的体积太大，是二进制编码的 5 倍多。

序列化性能太低

引出新的解决方案 [Google 的 Protobuf]

Protobuf 是 Google 发布的开源项目，全称 Google Protocol Buffers，是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC[远程过程调用 remote procedure call ] 数据交换格式。目前很多公司 http+json  tcp+protobuf

参考文档 : https://developers.google.com/protocol-buffers/docs/proto 语言指南 Protobuf 是以 message 的方式来管理数据的.

高性能，高可靠性

使用 protobuf 编译器能自动生成代码，Protobuf 是将类的定义使用.proto 文件进行描述。说明，在idea 中编写 .proto 文件时，会自动提示是否下载 .ptotot 编写插件. 可以让语法高亮。

然后通过 protoc.exe 编译器根据.proto 自动生成.java 文件

protobuf 使用示意图

syntax= "proto3";
//永远不要修改生成的代码，只能修改这里的代码
option optimize_for = SPEED;//加快解析速度
option java_package="atguigu.netty.codec2";//生成到哪个包下
opton java_outer_classname="MyDataInfo"; //外部类名

Netty编解码器和handler的调用机制

netty的组件设计：Netty的主要组件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等

ChannelHandler充当了处理入站和出站数据的应用程序逻辑的容器。例如，实现ChannelInboundHandler接口（或ChannelInboundHandlerAdapter），你就可以接收入站事件和数据，这些数据会被业务逻辑处理。当要给客户端发送响应时，也可以从ChannelInboundHandler冲刷数据。业务逻辑通常写在一个或者多个ChannelInboundHandler中。ChannelOutboundHandler原理一样，只不过它是用来处理出站数据的

ChannelPipeline提供了ChannelHandler链的容器。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站的，即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler，并被这些Handler处理，反之则称为入站的

编码解码器

当Netty发送或者接受一个消息的时候，就将会发生一次数据转换。入站消息会被解码：从字节转换为另一种格式（比如java对象）；如果是出站消息，它会被编码成字节。

Netty提供一系列实用的编解码器，他们都实现了ChannelInboundHadnler或者ChannelOutboundHandler接口。在这些类中，channelRead方法已经被重写了。以入站为例，对于每个从入站Channel读取的消息，这个方法会被调用。随后，它将调用由解码器所提供的decode()方法进行解码，并将已经解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。

解码器-ByteToMessageDecoder

由于不可能知道远程节点是否会一次性发送一个完整的信息，tcp有可能出现粘包拆包的问题，这个类会对入站数据进行缓冲，直到它准备好被处理.

关系继承图

不论解码器handler 还是编码器handler 即接收的消息类型必须与待处理的消息类型一致，否则该handler不会被执行

在解码器进行数据解码时，需要判断缓存区(ByteBuf)的数据是否足够，否则接收到的结果会期望结果可能不一致

解码器-ReplayingDecoder

public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder

ReplayingDecoder扩展了ByteToMessageDecoder类，使用这个类，我们不必调用readableBytes()方法。参数S指定了用户状态管理的类型，其中Void代表不需要状态管理

ReplayingDecoder使用方便，但它也有一些局限性：

并不是所有的 ByteBuf 操作都被支持，如果调用了一个不被支持的方法，将会抛出一个 UnsupportedOperationException。

ReplayingDecoder 在某些情况下可能稍慢于 ByteToMessageDecoder，例如网络缓慢并且消息格式复杂时，消息会被拆成了多个碎片，速度变慢

TCP 粘包和拆包及解决方案

TCP是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发给接收端的包，更有效的发给对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样做虽然提高了效率，但是接收端就难于分辨出完整的数据包了，因为面向流的通信是无消息保护边界的

由于TCP无消息保护边界, 需要在接收端处理消息边界问题，也就是我们所说的粘包、拆包问题, 看一张图