官网定义: netty是一个异步、事件驱动的网络应用框架,用于快速开发可维护的、高性能的服务端和客户端程序。
原理分析
Architecture Overview
网络模型:netty采用了Reactor设计模式,Reactor设计可分三种:
单线程版本,如图:
学C的朋友会知道IO多路复用,我感觉和这个Reactor模式差不多,Reactor收到新连接调用acceptor的accept,返回的SocketChannel会注册到Reactor里,当连接可读或者可写时,分发一个handler处理。
多线程版本,如图:
处理部分增加了线程池。
Multi-Reactor版本:
监听端口注册到mainReactor里,有连接,调用accept,返回的连接注册到subReactor里,subReactor只负责读写,处理部分交给线程池。
Netty采用的方式类似于第三种,Netty3.6里mainReactor对应Boss类,subReactord对应NioWorker类;4.x里是实现EventLoopGroup接口的某个类,如NioEventLoopGroup(multithreaded event loop that handles I/O operation),EventLoopGroup相当于管理EventLoop的线程池,thread数量是可以配置的,echoServer例子中:
42,43行就是boss和worker了,ServerBootstrap是设置服务器的帮助类。
47行用NioServerSocketChannel类说明后面会用它去实例channel来接受incoming连接。
48行option方法可以指定Channel实现的方式。
50行:subReactor监听的channel来事件了,处理方法要通过childHandler方法指定,这是需要我们实现的,childHandler方法的参数是ChannelHandler接口的某个类,然后回调;拿FactorialServerInitializer举例,层次关系如图:
ChannelInitializer用来配置channel,这里要实现抽象类ChannelInitializer里的initChannel方法,意味着要在initChannel方法里配置pipeline。
我们观察EventLoopGroup类,如下图所示:
EventExecutor和EventLoopGroup都包含通用的 event loop API;EventLoopGroup有register方法,提供向其注册channel,返回ChannelFuture;
Netty Pipeline:
每个channel都有自己的pipeline,channel创建则对应的pipeline自动创建,下图显示了IO事件如何通过ChannelHandler在ChannelPipeline中处理的:
在pipeline里,每个stage运行一个InboundHandler或OutboundHandler,设计过MIPS经典五段pipeline的朋友应该知道锁存器设计,这里对应ChannelHandlerContext,ChannelHandlerContext可以通知ChannelPipeline里下一个ChannelHandler工作,并把事件流传给下一个ChannelHandler,也可以动态修改它所属的ChannelPipeline;
Inbound事件流传递方法:
Outbound事件流传递方法:
我们看下官网的例子,io.netty.example.factorial 这个包,Pipeline部分(服务端):
当Socket.read()发生时,handler处理事件的顺序是:BigIntegerDecoder->FactorialServeHandler
当Socket.write()发生时,handler处理事件的顺序是:NumberEncoder
ChannelInboundHandlerAdapter的方法:
ChannelOutboundHandlerAdapter的方法:
关于Pipeline的一些说明:并不是一个阶段执行完了,才去执行下一个阶段,而是每个Handler有对应的事件处理方法(如上ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter中的方法),当这个Handler接收到了某事件,就会调用这个事件处理方法,然后会触发下个Handler对应的事件处理方法,下面用自带的io.netty.example.http.helloworld包验证这个想法(在方法里插了输出):
Socket.read():HttpServerCodec->HttpHelloWorldServerHandler;
Socket.write():HttpServerCodec
Zero Copy:
Netty里用到了ZC技术,这里是介绍ZeroCopy比较好的一篇文章,Netty里FileRegion就是用来支持ZeroCopy的接口,ZC在传输大文件时比较有优势,把大文件指定到Channel上,直接传输,不经过Application层。
Channel包:
Channel接口封装了socket,提供IO操作(如read,write,connect,bind等)的组建,具体属性、方法可参考文档;
ChannelFuture接口继承了io.netty.util.concurrent.Future,Netty中IO调用均是异步的,调用立即返回,返回结果记录在ChannelFuture里,ChannelFuture随着IO操作的开始而被创建,它的状态可以是完成或者未完成,初始态是未完成,状态如下:
我们可以通过向ChannelFuture里增加和删除ChannelFutureListener(继承GenericFutureListener)(通过addListener(s)、removeListener(s)方法),IO操作完成时触发GenericFutureListener的operationComplete方法执行,这是异步的操作;我们也可以调用ChannelFuture的await方法阻塞Control Flow,直到ChannelFuture完成。
ChannelPipeline已在上文介绍;
Buffer包:
Netty使用自己的buffer API处理字节序列,而不是使用NIO自带的buffer,这样的定制有很多优势吧,官方文档是这么说的:在常见的网络应用中,我们会有一些buffer,它们经常需要组装成一个buffer,netty提供composite buffer,它允许你把已经存在的几个buffer组合起来创建一个virtual buffer,不需要内存拷贝:
还有许多协议的MTU都是不确定的,Netty允许你创建动态大小的buffer,来降低内存开销。
Channel读的数据会写到实现ByteBuf接口的某个类里,ByteBuf里数据满了,会调用handler处理,io.netty.handler.codec包里面会有一些类把package frame,也就是收到的ByteBuf decode成Message,交给handler处理;ByteBuf提供Java nio缓存(ByteBuffer)类似的方法,ByteBuf接口的实现层次图:
buffer包中有一个帮助类Unpooled,用于创建ByteBuf,所有的ByteBuf都是通过ByteBufAllocatore和UnpooledByteBufAllocator分配的,在Unpooled类里,默认的分配器是UnpooledByteBufAllocator,默认分配的ByteBuf类型是UnpooledHeapByteBuf;
HeapByteBuf是在Java堆上分配内存;DirectByteBuf用的是NIO的ByteBuffer,CompositeByteBuf是一个虚拟的buffer,将多种buffer合并成一个buffer;
细心的同学会看到PoolByteBuf和UnpooledByteBuf,PoolByteBuf是4.0新引入的,设计思想借鉴jemalloc(core:混合了slab分配器和buddy分配器),优点是减少内存碎片,Slab分配器是基于对象管理的,分配对象,直接从Slab系统里拿,无需再次初始化,释放对象,则保留在Slab系统里,标记为脏,不需释放,降低GC压力;
io.netty.handler.codec包:
ByteToMessageCodec类封装了ByteToMessageDecoder和MessageToByteEncoder(都作为Pipeline Handler);我们先观察ByteToMessageDecoder,其可以将流式的字节转化成消息类型,他有一个成员cumulation(ByteBuf类型),收消息时会把收到的msg(ByteBuf类型)传递给cumulation,数据准备好后调用callDecode,callDecode进一步调用decode方法(具体分帧方法),这个方法交给子类实现;MessageToByteEncoder里的write方法同理,write里调用子类实现的encode方法将消息encode成ByteBuf,发送出去。
Netty in Twitter:
写Netty的同学在twitter工作,twitter的新搜索架构Blender就是基于Netty的,如果您能FQ,可以访问这里,否则中文在这里,英文在这里,来了解Blender的架构。