1、发现Kafka开挂
听过ZeroMQ吗
ZeroMQ完全没有任何服务器节点，也不会使用硬盘，按照道理说它应该比Kafka快。可是实际测试下来它的速度还是被Kafka“吊打”。
Kafka使用磁盘文件存储还想快速？
“一个用硬盘的比用内存的快”，这绝对违反常识；
如果这种事情发生说明——它开挂了。
没错，Kafka“开挂”实锤。
2、Kafka的金手指——顺序写入
因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。
每一个Partition其实都是一个文件，收到消息后Kafka会把数据插入到文件末尾
3、Kafka的金手指——内存映射
内存映射（Memory Mapped Files）
即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以Kafka的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。
Memory Mapped Files(后面简称mmap)也被翻译成内存映射文件，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上（操作系统在适当的时候）。
通过mmap，进程像读写硬盘一样读写内存（当然是虚拟机内存），也不必关心内存的大小有虚拟内存为我们兜底。
使用这种方式可以获取很大的I/O提升，省去了用户空间到内核空间复制的开销（调用文件的read会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中。）也有一个很明显的缺陷——不可靠，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。Kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回Producer叫同步(sync)；写入mmap之后立即返回Producer不调用flush叫异步(async)。
mmap其实是Linux中的一个函数就是用来实现内存映射的，谢谢Java NIO，它给我提供了一个mappedbytebuffer类可以用来实现内存映射（所以是沾了Java的光才可以如此神速和Scala没关系！！）
4、Kafka的金手指——零拷贝
sendfile函数在两个文件描述符之间直接传递数据（完全在内核中操作），从而避免了内核缓冲区和用户缓冲区之间的数据拷贝，效率很高，这被称为零拷贝。sendfile函数的定义如下：
#include <sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t* offset, size_t count);
- in_fd参数是待读出内容的文件描述符（mmap）,相当于sendfile输入流
- out_fd参数是待写入内容的文件描述符（socket），相当于sendfile输出流
- offset参数指定从读入文件流的哪个位置开始读，如果为空，则从in_fd文件描述符所指的文件的文件偏移位置开始读，并且sendfile会更新in_fd所指文件的文件偏移。offset如果不为空，则指定从读入文件的哪个位置开始读，当sendfile执行完后，offset返回下一个要读的字节位置，注意，offset不为空不更新in_fd所指文件的文件偏移。
- count参数指定在文件描述符in_fd和out_fd之间传输的字节数。sendfile成功时返回传输的字节数，失败则返回-1并设置errno。该函数的man手册明确指出in_fd必须是一个支持类似mmap函数的文件描述符，即它必须指向真实的文件，不能是socket和管道；在Linux2.6.33之前，out_fd必须是一个socket，而从Linux2.6.33之后，out_fd可以是任何文件。
没错，Kafka是用mmap作为文件读写方式的，它就是一个文件句柄（文件描述符），所以直接把它传给sendfile；偏移也好解决，用户会自己保持这个offset，每次请求都会发送这个offset
#总结
# producer写入的‘作弊方法’是——顺序写入
# 写入后使用内存映射——mmap
# consumer消费时的作弊方法是——零拷贝
# 零拷贝时，输入mmap与offset，输出到socket，最终到网络接口