网上关于“零拷贝”原理相关的文章满天飞,但你知道如何使用零拷贝吗?

互联网全栈架构

共 3764字,需浏览 8分钟

 ·

2021-11-19 15:20


零拷贝是中间件相关面试中必考题,本文就和大家一起来总结一下NIO拷贝的原理,并结合Netty代码,从代码实现层面近距离观摩如何使用java实现零拷贝。

1、零拷贝实现原理

**“零拷贝”**其实包括两个层面的含义:

  • 拷贝 一份相同的数据从一个地方移动到另外一个地方的过程,叫拷贝。
  • 零 希望在IO读写过程中,CPU控制的数据拷贝到次数为0。

在IO编程领域,当然是拷贝的次数越少越好,逐步优化,将其拷贝次数将为0,最大化的提高性能。

那接下来我们循序渐进来看一下如何减少数据复制。

接下来我们将以RocketMQ消息发送、消息读取场景来阐述IO读写过程中可能需要进行的数据复制与上下文切换。

1.1 传统的IO读流程

一次传统的IO读序列流程如下所示:java应用中,如果要将从文件中读取数据,其基本的流程如下所示:

  1. 当broker收到拉取请求时发起一次read系统调用,此时操作系统会进行一次上下文的切换,从用态间切换到内核态
  2. 通过直接存储访问器(DMA)从磁盘将数据加载到内核缓存区DMA Copy,这个阶段不需要CPU参与,如果是阻塞型IO,该过程用户线程会处于阻塞状态)
  3. 然后在CPU的控制下,将内核缓存区的数据copy到用户空间的缓存区(由于这个是操作系统级别的行为,通常这里指的内存缓存区,通常使用的是堆外内存),这里将发生一次CPU复制与一次上下文切换(从内核态切换到用户态)
  4. 堆外内存中的数据复制到应用程序的堆内存,供应用程序使用,本次复制需要经过CPU控制。
  5. 将数据加载到堆空间,需要传输到网卡,这个过程又要进入到内核空间,然后复制到sockebuffer,然后进入网卡协议引擎,从而进入到网络传输中。该部分会在接下来会详细介绍。

温馨提示:RocketMQ底层的工作机制并不是上述模型,是经过优化后的读写模型,本文将循序渐进的介绍优化过程。

1.2 传统的IO写流程

一次传统的IO写入流程如下图所示:核心关键步骤如下:

  1. 在broker收到消息时首先会在堆空间中创建一个堆缓存区,用于存储用户需要写入的数据,然后需要将jvm堆内存中数据复制到操作系统内存(CPU COPY)
  2. 发起write系统调用,将用户空间中的数据复制到内存缓存区,**此过程发生一次上下文切换(用户态切换到内核态)**并进行一次CPU Copy。
  3. 通过直接存储访问器(DMA)将内核空间的数据写入到磁盘,并返回结果,此过程发生一次DMA Copy 与一次上下文切换(内核态切换到用户态)

1.3 读写优化技巧

从上面两张流程图,我们不能看出读写处理流程中存在太多复制,同样的数据需要被复制多次,造成性能损耗,故IO读写通常的优化方向主要为:减少复制次数、减少用户态/内核态切换次数。

1.3.1 引入堆外内存

jvm堆空间中数据要发送到内核缓存区,通常需要先将jvm堆空间中的数据拷贝到系统内存(一个非官方的理解,用C语言实现的本地方法调用中,首先需要将堆空间中数据拷贝到C语言相关的存储结构),故提高性能的第一个措施:使用堆外内存。

不过堆外内存中的数据,通常还是需要从堆空间中获取,从这个角度来看,貌似提升的性能有限。

1.3.2 引入内存映射(MMap与write)

通过引入内存映射机制,减少用户空间与内核空间之间的数据复制,如下图所示:内存映射的核心思想就是将内核缓存区、用户空间缓存区映射到同一个物理地址上,可以减少用户缓存区与内核缓存区之间的数据拷贝

但由于内存映射机制并不会减少上下文切换次数。

1.3.3 大名鼎鼎鼎sendfile

在Linux 2.1内核引入了sendfile函数用于将文件通过socket传送

注意sendfile的传播方向:使用于将文件中的内容直接传播到Socket,通常使用客户端从服务端文件中读取数据,在服务端内部实现零拷贝。

在1.3.1中介绍客户端从服务端读取消息的过程中,并没有展开介绍从服务端写入到客户端网络中的过程,接下来看看sendfile的数据拷贝图解:sendfile的主要特点是在内核空间中通过DMA将数据从磁盘文件拷贝到内核缓存区,然后可以直接将内核缓存区中的数据在CPU控制下将数据复制到socket缓存区,最终在DMA的控制下将socketbufer中拷贝到协议引擎,然后经网卡传输到目标端。

sendfile的优势(特点):

  • 一次sendfile调用会只设计两次上下文切换,比read+write减少两次上下文切换。
  • 一次sendfile会存在3次copy,其中一次CPU拷贝,两次DMA拷贝。
1.3.4 Linux Gather

Linux2.4内核引入了gather机制,用以消除最后一次CPU拷贝,即不再将内核缓存区中的数据拷贝到socketbuffer,而是将内存缓存区中的内存地址、需要读取数据的长度写入到socketbuffer中,然后DMA直接根据socketbuffer中存储的内存地址,直接从内核缓存区中的数据拷贝到协议引擎(注意,这次拷贝由DMA控制)。

从而实现真正的零拷贝。

2、结合Netty谈零拷贝实战

上面讲述了“零拷贝”的实现原理,接下来将尝试从Netty源码去探究在代码层面如何使用“零拷贝”

从网上的资料可以得知,在java nio提供的类库中真正能运用底层操作系统的零拷贝机制只有FileChannel的transferTo,而在Netty中也不出意料的对这种方式进行了封装,其类图如下:其主要的核心要点是FileRegion的transferTo方法,我们结合该方法再来介绍DefaultFileRegion各个核心属性的含义。上述代码并不复杂,我们不难得出如下观点:

  • 首先介绍DefaultFileRegion的核心属性含义:
    • File f 底层抽取数据来源的底层磁盘文件
    • FileChannel file 底层文件的文件通道。
    • long position 数据从通道中抽取的起始位置
    • long count 需要传递的总字节数
    • long transfered 已传递的字节数量。
  • 核心要点是调用java nio FileChannel的transferTo方法,底层调用的是操作系统的sendfile函数,即真正的零拷贝。
  • 调用一次transferTo方法并不一定能将需要的数据全部传输完成,故该方法返回已传输的字节数,是否需要再次调用该方法的判断方法:已传递的字节数是否等于需要传递的总字节数(transfered == count)

接下来我们看一下FileRegion的transferTo在netty中的调用链,从而推断一下Netty中的零拷贝的触发要点。在Netty中代表两个类型的通道:

  • EpollSocketChannel 基于Epoll机制进行事件的就绪选择机制。

  • NioSocketChannel

    基于select机制的事件就绪选择。

在Netty中调用通道Channel的flush或writeAndFlush方法,都会最终触发底层通道的网络写事件,如果待写入的对象是FileRegion,则会触发零拷贝机制,接下来我们对两个简单介绍一下:

2.1 EpollSocketChannel 通道零拷贝

写入的入口函数为如下:核心思想为:如果待写入的消息是DefaultFileRegion,EpollSocketChannel将直接调用sendfile函数进行数据传递;如果是FileRegion类型,则按照约定调用FileRegion的transferTo进行数据传递,这种方式是否真正进行零拷贝取决于FileRegion的transferTo中是否调用了FileChannel的transferTo方法。

温馨提示:本文并没有打算详细分析Epoll机制以及编程实践。

2.2 NioSocketChannel 通道零拷贝实现

实现入口为:从这里可知,NioSocketChannel就是中规中矩的调用FileRegion的transferTo方法,是否真正实现了零拷贝,取决于底层是否调用了FileChannel的transferTo方法。

2.3 零拷贝实践总结

从Netty的实现中我们基本可以得出结论:是否是零拷贝,判断的依据是是否调用了FileChannel的transferTo方法,更准备的表述是底层是否调用了操作系统的sendfile函数,并且操作系统底层还需要支持gather机制,即linux的内核版本不低于2.4。

最后说一句(求关注,别白嫖我)

如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。

求一键三连:点赞、转发、在看。


推荐阅读:

为什么阿里把MySQL的事务隔离级别改成RC?

一个架构师的缓存修炼之路

Redis主节点的Key已过期的处理

Redis 哨兵模式


互联网全栈架构

浏览 28
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报