Netty工作原理最详细分析

• NIO通讯服务端步骤：

1、创建ServerSocketChannel,为它配置非阻塞模式
2、绑定监听，配置TCP参数，录入backlog大小等
3、创建一个独立的IO线程，用于轮询多路复用器Selector
4、创建Selector，将之前的ServerSocketChannel注册到Selector上，并设置监听标识位SelectionKey.ACCEPT
5、启动IO线程，在循环体中执行Selector.select()方法，轮询就绪的通道
6、当轮询到处于就绪的通道时，需要进行判断操作位，如果是ACCEPT状态，说明是新的客户端介入，则调用accept方法接受新的客户端。
7、设置新接入客户端的一些参数，并将其通道继续注册到Selector之中。设置监听标识等
8、如果轮询的通道操作位是READ，则进行读取，构造Buffer对象等
9、更细节的还有数据没发送完成继续发送的问题

• 零拷贝技术原理

• “零拷贝”是指计算机操作的过程中，CPU不需要为数据在内存之间的拷贝消耗资源。而它通常是指计算机在网络上发送文件时，不需要将文件内容拷贝到用户空间（User Space）而直接在内核空间（Kernel Space）中传输到网络的方式
• Netty的“零拷贝”主要体现在三个方面
  • Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝读取直接从“堆外直接内存”，不像传统的堆内存和直接内存拷贝，ByteBufAllocator 通过ioBuffer分配堆外内存
  • Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer，Netty允许我们将多段数据合并为一整段虚拟数据供用户使用，而过程中不需要对数据进行拷贝操作，组合Buffer对象，避免了内存拷贝，ＣhannelBuffer接口：Netty为需要传输的数据制定了统一的ChannelBuffer接口，使用getByte(int index)方法来实现随机访问，使用双指针的方式实现顺序访问
  •  Netty主要实现了HeapChannelBuffer，ByteBufferBackedChannelBuffer，与Zero Copy直接相关的CompositeChannelBuffer类
    • CompositeChannelBuffer类
      • CompositeChannelBuffer类的作用是将多个ChannelBuffer组成一个虚拟的ChannelBuffer来进行操作
      • 为什么说是虚拟的呢，因为CompositeChannelBuffer并没有将多个ChannelBuffer真正的组合起来，而只是保存了他们的引用，这样就避免了数据的拷贝，实现了Zero Copy，内部实现
        • 其中readerIndex既读指针和writerIndex既写指针是从AbstractChannelBuffer继承而来的
        • components是一个ChannelBuffer的数组，他保存了组成这个虚拟Buffer的所有子Buffer
        • indices是一个int类型的数组，它保存的是各个Buffer的索引值
        • lastAccessedComponentId是一个int值，它记录了最后一次访问时的子Buffer ID
      • CompositeChannelBuffer实际上就是将一系列的Buffer通过数组保存起来，然后实现了ChannelBuffer 的接口，使得在上层看来，操作这些Buffer就像是操作一个单独的Buffer一样
  • Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题
    • Linux中的sendfile()以及Java NIO中的FileChannel.transferTo()方法都实现了零拷贝的功能，而在Netty中也通过在FileRegion中包装了NIO的FileChannel.transferTo()方法实现了零拷贝

Netty 的 Zero-copy 体现在如下几个个方面:

1. Netty 提供了 CompositeByteBuf 类, 它可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf, 避免了各个 ByteBuf 之间的拷贝。
2. 通过 wrap 操作, 我们可以将byte[] 数组、ByteBuf、ByteBuffer等包装成一个 Netty ByteBuf 对象, 进而避免了拷贝操作。
3. ByteBuf 支持 slice 操作,因此可以将 ByteBuf 分解为多个共享同一个存储区域的ByteBuf, 避免了内存的拷贝。
4. 通过 FileRegion 包装的FileChannel.tranferTo 实现文件传输, 可以直接将文件缓冲区的数据发送到目标 Channel, 避免了传统通过循环 write 方式导致的内存拷贝问题。

• 技术栈

• Netty的三层网络架构进行设计

1. 第一层：Reactor通信调度层。该层的主要职责就是监听网络的连接和读写操作，负责将网络层的数据读取到内存缓冲区中，然后触发各种网络事件，例如连接创建、连接激活、读事件、写事件等，将这些事件触发到Pipeline中，再由Pipeline充当的职责链来进行后续的处理。
2. 第二层：职责链Pipeline层。负责事件在职责链中有序的向前（后）传播，同时负责动态的编排职责链。Pipeline可以选择监听和处理自己关心的事件。
3. 第三层：业务逻辑处理层，一般可分为两类：a. 纯粹的业务逻辑处理，例如日志、订单处理。b. 应用层协议管理，例如HTTP(S)协议、FTP协议等。

影响网络服务通信性能的主要因素有：网络I/O模型、线程（进程）调度模型和数据序列化方式。

在网络I/O模型方面，Netty采用基于非阻塞I/O的实现，底层依赖的是JDKNIO框架的Selector。

在线程调度模型方面，Netty采用Reactor线程模型。常用的Reactor线程模型有三种，分别是：

a、Reactor单线程模型：Reactor单线程模型，指的是所有的I/O操作都在同一个NIO线程上面完成。对于一些小容量应用场景，可以使用单线程模型。

b、Reactor多线程模型：Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理I/O操作。主要用于高并发、大业务量场景。

c、主从Reactor多线程模型：主从Reactor线程模型的特点是服务端用于接收客户端连接的不再是一个单独的NIO线程，而是一个独立的NIO线程池。利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。Netty线程模型并非固定不变的，它可以支持三种Reactor线程模型。

在数据序列化方面，影响序列化性能的主要因素有：

a、序列化后的码流大小（网络带宽占用）。

b、序列化和反序列化操作的性能（CPU资源占用）。

c、并发调用时的性能表现：稳定性、线性增长等。

Netty默认提供了对GoogleProtobuf二进制序列化框架的支持，但通过扩展Netty的编解码接口，可以实现其它的高性能序列化框架，例如Avro、Thrift的压缩二进制编解码框架。

 

• 主从Reactor多线程模型

Netty使用ChannelBuffer来存储并操作读写的网络数据。ChannelBuffer除了提供和ByteBuffer类似的方法，还提供了 一些实用方法，具体可参考其API文档。

ChannelBuffer的实现类有多个，这里列举其中主要的几个：

1）HeapChannelBuffer：这是Netty读网络数据时默认使用的ChannelBuffer，这里的Heap就是Java堆的意思，因为 读SocketChannel的数据是要经过ByteBuffer的，而ByteBuffer实际操作的就是个byte数组，所以 ChannelBuffer的内部就包含了一个byte数组，使得ByteBuffer和ChannelBuffer之间的转换是零拷贝方式。根据网络字 节续的不同，HeapChannelBuffer又分为BigEndianHeapChannelBuffer和 LittleEndianHeapChannelBuffer，默认使用的是BigEndianHeapChannelBuffer。Netty在读网络 数据时使用的就是HeapChannelBuffer，HeapChannelBuffer是个大小固定的buffer，为了不至于分配的Buffer的 大小不太合适，Netty在分配Buffer时会参考上次请求需要的大小。

2）DynamicChannelBuffer：相比于HeapChannelBuffer，DynamicChannelBuffer可动态自适应大 小。对于在DecodeHandler中的写数据操作，在数据大小未知的情况下，通常使用DynamicChannelBuffer。

3）ByteBufferBackedChannelBuffer：这是directBuffer，直接封装了ByteBuffer的 directBuffer。

对于读写网络数据的buffer，分配策略有两种：1）通常出于简单考虑，直接分配固定大小的buffer，缺点是，对一些应用来说这个大小限制有时是不 合理的，并且如果buffer的上限很大也会有内存上的浪费。2）针对固定大小的buffer缺点，就引入动态buffer，动态buffer之于固定 buffer相当于List之于Array。

buffer的寄存策略常见的也有两种（其实是我知道的就限于此）：1）在多线程（线程池） 模型下，每个线程维护自己的读写buffer，每次处理新的请求前清空buffer（或者在处理结束后清空），该请求的读写操作都需要在该线程中完成。 2）buffer和socket绑定而与线程无关。两种方法的目的都是为了重用buffer。

Netty对buffer的处理策略是：读 请求数据时，Netty首先读数据到新创建的固定大小的HeapChannelBuffer中，当HeapChannelBuffer满或者没有数据可读 时，调用handler来处理数据，这通常首先触发的是用户自定义的DecodeHandler，因为handler对象是和ChannelSocket 绑定的，所以在DecodeHandler里可以设置ChannelBuffer成员，当解析数据包发现数据不完整时就终止此次处理流程，等下次读事件触 发时接着上次的数据继续解析。就这个过程来说，和ChannelSocket绑定的DecodeHandler中的Buffer通常是动态的可重用 Buffer（DynamicChannelBuffer），而在NioWorker中读ChannelSocket中的数据的buffer是临时分配的 固定大小的HeapChannelBuffer，这个转换过程是有个字节拷贝行为的。

从该结构图也可以看到，Channel主要提供的功能如下：

1）当前Channel的状态信息，比如是打开还是关闭等。 2）通过ChannelConfig可以得到的Channel配置信息。 3）Channel所支持的如read、write、bind、connect等IO操作。 4）得到处理该Channel的ChannelPipeline，既而可以调用其做和请求相关的IO操作。

在Channel实现方面，以通常使用的nio socket来说，Netty中的NioServerSocketChannel和NioSocketChannel分别封装了java.nio中包含的 ServerSocketChannel和SocketChannel的功能。

如前所述，Netty是事件驱动的，其通过ChannelEvent来确定事件流的方向。一个ChannelEvent是依附于Channel的 ChannelPipeline来处理，并由ChannelPipeline调用ChannelHandler来做具体的处理。下面是和 ChannelEvent相关的接口及类图：

对于使用者来说，在ChannelHandler实现类中会使用继承于ChannelEvent的MessageEvent，调用其 getMessage()方法来获得读到的ChannelBuffer或被转化的对象。

Netty 在事件处理上，是通过ChannelPipeline来控制事件流，通过调用注册其上的一系列ChannelHandler来处理事件，这也是典型的拦截 器模式。下面是和ChannelPipeline相关的接口及类图：

事件流有两种，upstream事件和downstream事件。在ChannelPipeline中，其可被注册的ChannelHandler既可以 是 ChannelUpstreamHandler 也可以是ChannelDownstreamHandler ，但事件在ChannelPipeline传递过程中只会调用匹配流的ChannelHandler。在事件流的过滤器链 中，ChannelUpstreamHandler或ChannelDownstreamHandler既可以终止流程，也可以通过调用 ChannelHandlerContext.sendUpstream(ChannelEvent)或 ChannelHandlerContext.sendDownstream(ChannelEvent)将事件传递下去。