kafka快速的原因

kafka是大数据领域无处不在的消息中间件,目前广泛使用的企业内部的实时数据管道,并帮助企业构建自己的流计算应用程序。
kafka虽然是基于磁盘做的数据存储,但却具有高性能、高吞吐、低延时的特点,器吞吐量动辄几万,几十上百万,这其中的原由值得我们一探究竟。
1、顺序读写
磁盘顺序读写性能要高于内存的随机读写
众所周知kafka是将消息记录持久化到本地磁盘中的,一般人会认为磁盘读写性能差,可能会对kafka性能如何保证提出质疑。实际上不管是内存还是磁盘,快或慢关键在于寻址的方式,磁盘分为顺序读写与随机读写,内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢,但磁盘的顺序读写性能却很高,一般而言要高出磁盘随机读写三个数量级,一些情况下磁盘顺序读写性能甚至要高于内存随机读写。
磁盘的顺序读写是磁盘使用模式中最有规律的,并且操作系统也对这种模式做了大量优化,kafka就是使用了磁盘顺序读写来提升的性能。kafka的message是不断追加到本地磁盘文件末尾的,而不是随机的写入,这使得kafka写入吞吐量得到了显著提升
2、page cache
为了优化读写性能,kafka利用了操作系统本身的page cache,就是利用操作系统自身的内存而不是JVM空间内存。这样做的好处有:
(1)避免object消耗:如果是使用java堆,java对象的内存消耗比较大,通常是所存储数据的两倍甚至更多。
(2)避免GC问题:随着JVm数据不断增多,垃圾回收将会变得复杂与缓慢,使用系统缓存就不会存在GC问题。
3、零拷贝(sendfile)
零拷贝并不是不需要拷贝,而是减少不必要的拷贝次数。通常是说在IO读写过程中。
kafka利用linux操作系统“零拷贝(zero-copy)"机制在消费端做的优化。
首先来了解下数据从文件发送到socket网络连接中的常规传输路径
比如:读取文件,再用socket发送出去
传统方式实现:
先读取、再发送,实际经过1~4四次copy。
buffer=File.read
Socket.send(buffer)
*第一步:操作系统从磁盘读取数据到内核空间(kernel space)的Page Cache缓冲区
*第二步;应用程序读取内核缓冲区的数据copy到用户空间(user space)的缓冲区
*第三步:应用程序将用户空间缓冲区的数据copy回内核空间到socket缓冲区
*第四步:操作系统将数据从socket缓冲区copy到网卡,由网卡进行网络传输
传统方式,读取磁盘文件并进行网络发送,经过的四次数据copy是非常繁琐的。实际IO读写,需要进行IO中断,需要CPU响应中断(带来上下文切换),尽管后来引入DMA来接管CPU的中断请求,但四次copy是存在“不必要的拷贝”的。
重新思考传统IO方式,会注意到实际上并不需要第二个和第三个数据副本。应用程序除了缓存数据并将其传输回套接字缓冲区之外什么都不做。相反,数据可以直接从读缓冲区传输到套接字缓冲区。
显然,第二次和第三次数据copy其实在这种场景下没有什么帮助反而带来开销,这也正是零拷贝出现的意义。
这种场景:是指读取磁盘文件后,不需要做其他处理,直接用网络发送出去。试想,如果读取磁盘的数据需要用程序进一步处理的话,必须要经过第二次和第三次数据copy,让应用程序在内存缓冲区处理。
此时我们会发现用户态“空空如也”。数据没有来到用户态,而是直接在核心态就进行了传输,但这样依然还是有多次复制。首先数据被读取到read buffer中,然后发到socket buffer,最后才发到网卡。虽然减少了用户态和核心态的切换,但依然存在多次数据复制。
如果可以进一步减少数据复制的次数,甚至没有数据复制是不是就会做到最快呢?
DMA
DMA,全称叫Direct Memory Access,一种可让某些硬件子系统去直接访问系统主内存,而不用依赖CPU的计算机系统的功能。听着是不是很厉害,跳过CPU,直接访问主内存。传统的内存访问都需要通过CPU的调度来完成。如下图:
DMS,则可以绕过CPU,硬件自己去直接访问系统主内存。如下图
【kafka快速的原因】回到本文中的文件传输,有了DMA后,就可以实现绝对的零拷贝,因为网卡是直接去访问系统主内存的。如下图:
总结
kafka采用顺序读写、page cache、零拷贝以及分区分段等这些设计,再加上在索引方面做的优化,另外kafka数据读写也是批量的而不是单条的,使得kafka就有了高性能、高吞吐、低延时的特点。这样kafka提供大容量的磁盘存储也变成了一种优点
java的nio提供了filechannel,它的tarnsferto、transferfrom方法就是zero copy

    推荐阅读