前言
我们都知道Netty是一款用于创建高性能网络应用程序的高级框架，但是实际工作中真正地去直接使用Netty的场景好像不多(反正我没有)。其实Netty无处不在，很多中间件底层通信框架用的都是Netty，dubbo、rocketMQ、Elasticsearch等常用的框架和中间件其实都用到了Netty。最近在读《Netty实战》这本书，做一个知识点的简要概括吧，省略了一些章节(比如Netty用于单元测试等)。
异步和事件驱动
bio线程模型：
image
nio线程模型：
image
Netty 的核心组件
- Channel
- 回调
- Future
-
事件和 ChannelHandler
image
Netty的组件和设计
Netty网络抽象的代表
- Channel— Socket
- EmbeddedChannel
- LocalServerChannel
- NioDatagramChannel
- NioSctpChannel
- NioSocketChannel
-
EventLoop— 控制流、多线程处理、并发
image
- ChannelFuture— 异步通知
ChannelHandler 和 ChannelPipeline
- 应用程序的业务逻辑通常驻留在一个或者多个 ChannelInboundHandler 中
-
ChannelPipeline 提供了 ChannelHandler 链的容器
image
- 在Netty中，有两种发送消息的方式。你可以直接写到Channel中，也可以写到和ChannelHandler 相关联的 ChannelHandlerContext 对象中。前一种方式将会导致消息从 ChannelPipeline 的尾端开始流动，而后者将导致消息从 ChannelPipeline 中的下一个 ChannelHandler 开始流动。
- channelHandler的应用：编码器和解码器
-
服务端EventLoopGroup
image
传输
分类
- OIO——阻塞传输
- NIO——异步传输
- Local——JVM 内部的异步通信
- Embedded——测试你的ChannelHandler
channel
image
-
每个 Channel 都将会被分配一个 ChannelPipeline 和 ChannelConfig。 ChannelConfig 包含了该 Channel 的所有配置设置，并且支持热更新。
-
Netty 的 Channel 实现是线程安全的。
-
NIO处理channel状态
image
-
关注linux的epoll实现
-
应用程序最佳传输实现
image
数据容器ByteBuf
优点
- 可以被用户自定义的缓冲区类型扩展
- 通过内置的复合缓冲区类型实现了透明的零拷贝
- 容量可以按需增长(类似于 JDK 的 StringBuilder)
- 在读和写这两种模式之间切换不需要调用 ByteBuffer 的 flip()方法
- 读和写使用了不同的索引
- 支持方法的链式调用
- 支持引用计数
- 支持池化
ByteBuf使用模式
- 堆缓冲区，支撑数组
- 直接缓冲区
- 复合缓冲区
字节级操作
image
-
丢弃字节：discardReadBytes()
image
-
索引复位：clear()
image
- 切片：slice()；副本：copy()
重要的类
- ByteBufHolder，持有ByteBuf引用，可以存储额外信息
- ByteBufAllocator，获取池化ByteBuf，可以从Channel或者ChannelHandlerContext获取ByteBufAllocator的引用
- Unpooled，获取未池化ByteBuf
- ByteBufUtil，工具类
引用计数
ReferenceCounted接口
ChannelHandler和ChannelPipeline
- 当某个 ChannelInboundHandler 的实现重写 channelRead()方法时，它将负责显式地 释放与池化的 ByteBuf 实例相关的内存。Netty 为此提供了一个实用方法 ReferenceCount- Util.release()
public class DiscardHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ReferenceCountUtil.release(msg);
}
}
资源管理
- 每当通过调用 ChannelInboundHandler.channelRead()或者 ChannelOutboundHandler.write()方法来处理数据时，都需要确保没有任何的资源泄漏。除非调用了ChannelHandlerContext.fireChannelRead()交给下一个处理器处理。
- ChannelOutboundHandler.write()不仅要释放资源，还要通知ChannelPromise。否则可能会出现 ChannelFutureListener 收不到某个消息已经被处理了的通知的情况。
-
资源泄露检测类——ResourceLeakDetector
利用了JDK的虚引用，配置参数java -Dio.netty.leakDetectionLevel=ADVANCED
image
ChannelPipeline接口
- 每一个新创建的 Channel 都将会被分配一个新的 ChannelPipeline。这项关联是永久性的; Channel 既不能附加另外一个 ChannelPipeline，也不能分离其当前的。在 Netty 组件 的生命周期中，这是一项固定的操作，不需要开发人员的任何干预。
- ChannelInboundHandler从头部开始处理，ChannelOutboundHandler从尾部开始处理
ChannelHandlerContext接口
- ChannelHandlerContext 有很多的方法，其中一些方法也存在于 Channel 和 Channel- Pipeline 本身上，但是有一点重要的不同。如果调用 Channel 或者 ChannelPipeline 上的这 些方法，它们将沿着整个 ChannelPipeline 进行传播。而调用位于 ChannelHandlerContext 上的相同方法，则将从当前所关联的 ChannelHandler 开始，并且只会传播给位于该 ChannelPipeline 中的下一个能够处理该事件的 ChannelHandler。
-
重要组件之间的关系
image
-
事件传播
image
image
异常处理
- 通过调用 ChannelPromise 上的 setSuccess()和 setFailure()方法，可以使一个操作的状态在 ChannelHandler 的方法返回给其调用者时便即刻被感知到
EventLoop和线程模型
类层次结构
image
EventLoop实现细节
-
执行逻辑
image
-
分配方式
image
image
引导
Bootstrap——客户端或无连接协议
-
Bootstrap 类负责为客户端和使用无连接协议的应用程序创建 Channel
image
ServerBootstrap——服务端
-
ServerChannel 的实现负责创建子 Channel，这些子 Channel 代表了已被接受的连接
image
DatagramChannel——无连接
Bootstrap bootstrap = new Bootstrap();
bootstrap.group(new OioEventLoopGroup()).channel(
OioDatagramChannel.class).handler(new SimpleChannelInboundHandler<DatagramPacket>(){
@Override
public void channelRead0(ChannelHandlerContext ctx, DatagramPacket msg) throws Exception {
// Do something with the packet
}
);}
ChannelFuture future = bootstrap.bind(new InetSocketAddress(0));
future.addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture channelFuture) throws Exception {
if (channelFuture.isSuccess()) {
System.out.println("Channel bound");
} else {
System.err.println("Bind attempt failed");
channelFuture.cause().printStackTrace();
}
});
关闭
- EventLoopGroup.shutdownGracefully()
- 它将处理任何挂起的事件和任务，并且随后释放所有活动的线程
编解码器
编码器操作出站数据，而解码器处理入站数据。
编解码器中的引用计数是会自动处理的，ReferenceCountUtil.release(message)
解码器
- ByteToMessageDecoder
- ReplayingDecoder
- MessageToMessageDecoder
- TooLongFrameException 防止解码器缓冲的数据耗尽内存
编码器
- MessageToByteEncoder
- MessageToMessageEncoder
编解码器
- ByteToMessageCodec
- MessageToMessageCodec
- CombinedChannelDuplexHandler
预置的 ChannelHandler 和编解码器
SslHandler
在大多数情况下，SslHandler将是ChannelPipeline中的第一个ChannelHandler。 这确保了只有在所有其他的 ChannelHandler 将它们的逻辑应用到数据之后，才会进行加密。
image
HTTP 解码器、编码器和编解码器
- HttpRequestEncoder
- HttpResponseEncoder
- HttpRequestDecoder
- HttpResponseDecoder
- HttpObjectAggregator——聚合 HTTP 消息
-
HttpContentCompressor && HttpContentDecompressor——HTTP 压缩和解压
image
WebSocketProtocolHandler
image
空闲的连接和超时
- IdleStateHandler——可以用来实现心跳
- ReadTimeoutHandler
- WriteTimeoutHandler
基于分隔符的协议
- DelimiterBasedFrameDecoder
- LineBasedFrameDecoder——比DelimiterBasedFrameDecoder效率高
基于长度的协议
LineBasedFrameDecoder
- FixedLengthFrameDecoder
- LengthFieldBasedFrameDecoder
写大型数据
- FileRegion
- 通过支持零拷贝的文件传输的 Channel 来发送的文件区域
- 只适用于文件内容的直接传输，不包括应用程序对数据的任何处理
- ChunkedWriteHandler
- 支持将数据从文件系统复制到用户内存中
- 支持异步写大型数据流，而又不会导致大量的内存消耗
序列化数据
- JBoss Marshalling
- Protocol Buffers
扩展——研究Netty中碰到的思考
- netty解决的epoll空轮询
- FastThreadLocal实现原理
- EventLoopGroup分配EventLoop的实现细节
类似于轮询，用原子变量来实现索引递增，做了一个优化，如果总数是2的倍数，会通过位移来计算余数
- ChannelProgressivePromise实时获取传输进度怎么实现
网友评论