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，硬件自己去直接访问系统主内存。如下图

回到本文中的文件传输，有了DMA后，就可以实现绝对的零拷贝，因为网卡是直接去访问系统主内存的。如下图：
总结
kafka采用顺序读写、page cache、零拷贝以及分区分段等这些设计，再加上在索引方面做的优化，另外kafka数据读写也是批量的而不是单条的，使得kafka就有了高性能、高吞吐、低延时的特点。这样kafka提供大容量的磁盘存储也变成了一种优点
java的nio提供了filechannel，它的tarnsferto、transferfrom方法就是zero copy