零拷贝原理+kafka中的零拷贝_kafka零拷贝

kafka性能之零拷贝

kafka中的零拷贝并不是说完全避免了上下文切换与cpu拷贝的次数, 而是减少这种拷贝次数

传统IO

传统的一次IO流程

read: 数据从磁盘读取到内核缓冲区, 然后从内核缓冲区拷贝到用户缓冲区

write: 数据从用户缓冲区写入socket缓冲区, 然后写入网卡设备

1. read之后, 也即向操作系统发出IO调用, 用户态切换到内核态
2. DMA拷贝数据从硬盘到内核缓冲区
3. CPU拷贝内核缓冲区数据到用户缓冲区, 内核态切换到用户态
4. write之后, 也即发起IO调用, 用户态切换到内核态
5. CPU拷贝用户缓冲区数据到socket缓冲区
6. DMA拷贝socket缓冲区到网卡设备, 内核态切换到用户态

• 上述过程可以看出有4次上下文切换, 4次拷贝. 其实这个地方可以优化, 我们把数据拷贝到用户缓冲区再从用户缓冲区拿出数据到socket纯属多此一举, 如果有一种操作直接可以把数据从内核缓冲区到socket缓冲区的话, 就能减少拷贝操作了

零拷贝mmp优化

mmp优化是基于虚拟内存实现的

虚拟内存是什么东西?简单来讲, 虚拟内存是由于主存不够大而出现的辅存(理论上来说, 主存想多大就多大, 实际上来说怎么可能, 主存越大价格越高, 追求性价比的情况下才出现的虚拟内存)

虚拟内存主要是干啥呢? 虚拟内存可以把内核空间和用户空间的虚拟地址映射到同一个地方, 这样用户对这个映射地址的操作, 内核空间也可以感知到, 那么内核和用户之间就可以减少拷贝了

当引入mmp机制后的IO操作

1. mmp调用向操作系统发起IO, 用户态切换到内核态
2. DMA拷贝数据从硬盘到内核缓冲区
3. 内核态切换到用户态
4. write之后, 也即发起IO调用, 用户态切换到内核态
5. CPU拷贝内核缓冲区数据到socket缓冲区
6. DMA拷贝socket缓冲区到网卡设备, 内核态切换到用户态

• 上述操作可以看出, 我们进行了4次上下文切换, 3次拷贝, 好像还是不够优化, 我们虽然优化了拷贝次数, 但是上下文切换也很耗费时间的, 4次上下文切换能否可以优化呢?对于系统调用来说(read, write,mmp这类函数) 上下文切换是不可避免的, 想要优化就必然减少系统调用次数, 上述我们不可避免使用到了write函数,如果我们将read和write合并成一次系统调用, 在内核中实现磁盘和网课数据传输, 就能够减少上下文切换了, 也就是sendfile优化

• 通过mmap，进程像读写硬盘一样读写内存（当然是虚拟机内存），也不必关心内存的大小有虚拟内存为我们兜底。

sendfile优化

当引入sendfile优化后的IO操作

1. 用户进程发起sendfile进行IO，用户态切换至内核态
2. DMA拷贝数据从硬盘到内核缓冲区
3. CPU拷贝内核缓冲区到socket缓冲区
4. DMA拷贝数据从socket缓冲区到网卡
5. 内核态切换到用户态, sendfile函数返回

• 上述操作发现, 我们只进行了2次上下文切换, 这下上下文切换好像是优化到极致了,但是依旧是3次拷贝, 如何继续优化拷贝次数? Linux 2.4 版本之后，对 sendfile 做了升级优化，引入了 SG-DMA技术，其实就是对DMA拷贝加入了 scatter/gather 操作，它可以直接从内核空间缓冲区中将数据读取到网卡，无需将内核空间缓冲区的数据再复制一份到 socket 缓冲区，从而省去了一次 CPU拷贝。

sendfile +DMA scatter/gather优化

当使用优化后的IO操作

1. 用户进程发起sendfile进行IO，用户态切换至内核态
2. DMA拷贝数据从硬盘到内核缓冲区
3. CPU直接将文件描述符等信息(内核缓冲区的地址+偏移量)复制到socket缓冲区中
4. DMA根据文件描述符拷贝内核区数据到网卡
5. 内核态切换到用户态, sendfile函数返回

• 至此, 我们通过两次上下文切换+两次拷贝完成零拷贝终极优化
• 这里的两次拷贝不是cpu拷贝, 而是DMA拷贝, 零拷贝的意义也是在减少cpu拷贝, 使用mmp和sendfile实现的也叫做零拷贝, 只是不够那么零

Kafka是怎么使用零拷贝的

简单来说:

Kafka的两个过程

1. Producer生产数据到broker ->数据持久化到磁盘 -> 使用了mmp
2. Consumer从broker获取数据 ->磁盘文件发送到网卡 -> 使用了sendfile

mmap也有一个很明显的缺陷——不可靠，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。Kafka提供了一个参数——producer.type来控制是不是主动flush；如果Kafka写入到mmap之后就立即flush然后再返回Producer叫同步(sync)；写入mmap之后立即返回Producer不调用flush叫异步(async)。

RocketMQ选择了mmap + write这种零拷贝方式，适用于业务级消息这种小块文件的数据持久化和传输；而Kafka采用的是sendfile这种零拷贝方式，适用于系统日志消息这种高吞吐量的大块文件的数据持久化和传输。但是值得注意的一点是，Kafka的索引文件使用的是mmap+write方式，数据文件使用的是sendfile方式。

这里有一篇详细一点的文章, 网上讲kafka中如何实现零拷贝的好像比较少, 大部分围绕着零拷贝是什么展开的, 找了半天觉得这个比较好,感兴趣的可以戳这个大佬的链接