RocketMQ基于MMAP的零拷贝技术方案

本期我们来聊一聊RocketMQ的一些亮点元素，比如说RocketMQ的零拷贝方案，先来一张RocketMQ接受数据拷贝时的示意图：

       传统的消息中间件在进行数据接入和接出的时候， *** 作系统会先将数据读到内存中，然后应用在将数据读到应用层中，对数据进行处理，进行持久化时候，也会将数据先写进文件缓冲区，然后再写入文件中去。

       为了提高性能，RocketMQ对持久化部分进行一个升级，开辟了一块MappedByteBuffer（磁盘映射区域），将用户空间的虚拟地址和内核空间的虚拟地址指向同一个物理内存地址，这样用户空间和内核空间共享同一个内存数据，就可以直接对磁盘进行 *** 作了，从而省去了cpu拷贝进缓冲区的 *** 作。节省了很大的资源开销。像这种创建磁盘映射的实现，我们称之为MMAP。而这种通过直接 *** 作硬盘的行为实现性能缩减的技术，我们统称为零拷贝技术。

       对于资源开销方面的问题，我们可以看到，流程中只有两种拷贝方式，DMA拷贝和CPU拷贝，由于两者性质的不同，我们假设DMA拷贝需要2ms的话，CPU拷贝大约需要200ms，虽然看起来RocketMQ只做了一步拷贝的省略，但是资源开销减少了近一半。

       当然，零拷贝技术不仅仅是RocketMQ一家独有的技术，也不仅仅只有MMAP一种零拷贝技术。比如说市面上另一种零拷贝方案：Sendfile。
       Sendfile是通过直接 *** 作磁盘上文件的方式进行零拷贝实现的，但是这种实现有一个弊端，就是只能获取到文件的描述信息，无法真正的在应用层获取到实际的数据，因此根本无法在应用层对数据进行进一步的处理，比如过滤等等。
       目前Kafka和Tomcat内部使用就是Sendfile这种零拷贝。

Ps：关于DMA
如果我们始终让CPU来进行各种数据传输工作，会特别浪费。一方面，我们的数据传输工作用不到多少CPU核新的“计算”功能。另一方面，CPU的运转速度也比I/O *** 作要快很多。所以，我们希望能够给CPU“减负”。
于是，工程师们就在主板上放上了DMAC这样一个协处理器芯片。通过这个芯片，CPU只需要告诉DMAC，我们要传输什么数据，从哪里来，到哪里去，就可以放心离开了。