As we all know kafka throughput is higher than the average queue messages, known as the fastest, how did he do it, let's analyze the reasons from the following aspects.
Producer (write data)
Producer (producer) is responsible for submitting data to Kafka, let's analyze this part.
Kafka will receive the message are written to the hard disk, it will not lose data. To optimize the write speed Kafak using two techniques, sequential write and MMFile .
Sequential Write
Because the hard disk is a mechanical structure, are each read and write address -> Write, wherein the address is a "mechanical action" it is the most time consuming. So hard most "hated" random I / O, like most order the I / O . In order to improve read and write speed of the hard disk, Kafka is sequential use the I / O .
The figure shows how to write data to Kafka, each Partition in fact a document after receiving the message data will Kafka inserted end of the file (block imaginary part) .
This method has a drawback - there is no way to delete the data , so Kafka will not delete data, it will all the data retained, each consumer (Consumer) for each Topic has a offset is used to indicate read the first few data .
上图中有两个消费者，Consumer1有两个offset分别对应Partition0、Partition1（假设每一个Topic一个Partition）；Consumer2有一个offset对应Partition2。这个offset是由客户端SDK负责保存的，Kafka的Broker完全无视这个东西的存在；一般情况下SDK会把它保存到zookeeper里面。(所以需要给Consumer提供zookeeper的地址)。
如果不删除硬盘肯定会被撑满，所以Kakfa提供了两种策略来删除数据。一是基于时间，二是基于partition文件大小。具体配置可以参看它的配置文档。
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没关系！！）
消费者（读取数据）
Kafka使用磁盘文件还想快速？这是我看到Kafka之后的第一个疑问，ZeroMQ完全没有任何服务器节点，也不会使用硬盘，按照道理说它应该比Kafka快。可是实际测试下来它的速度还是被Kafka“吊打”。“一个用硬盘的比用内存的快”，这绝对违反常识；如果这种事情发生说明——它作弊了。
没错，Kafka“作弊”。无论是顺序写入还是mmap其实都是作弊的准备工作。
如何提高Web Server静态文件的速度 ?
仔细想一下，一个Web Server传送一个静态文件，如何优化？答案是zero copy。传统模式下我们从硬盘读取一个文件是这样的
先复制到内核空间（read是系统调用，放到了DMA，所以用内核空间），然后复制到用户空间(1,2)；从用户空间重新复制到内核空间（你用的socket是系统调用，所以它也有自己的内核空间），最后发送给网卡（3、4）。
Zero Copy中直接从内核空间（DMA的）到内核空间（Socket的），然后发送网卡。
这个技术非常普遍，The C10K problem 里面也有很详细的介绍，Nginx也是用的这种技术，稍微搜一下就能找到很多资料。
Java的NIO提供了FileChannle，它的transferTo、transferFrom方法就是Zero Copy。
Kafka是如何耍赖的?
想到了吗？Kafka把所有的消息都存放在一个一个的文件中，当消费者需要数据的时候Kafka直接把“文件”发送给消费者。这就是秘诀所在，比如：10W的消息组合在一起是10MB的数据量，然后Kafka用类似于发文件的方式直接扔出去了，如果消费者和生产者之间的网络非常好（只要网络稍微正常一点10MB根本不是事。。。家里上网都是100Mbps的带宽了），10MB可能只需要1s。所以答案是——10W的TPS，Kafka每秒钟处理了10W条消息。
可能你说：不可能把整个文件发出去吧？里面还有一些不需要的消息呢？是的，Kafka作为一个“高级作弊分子”自然要把作弊做的有逼格。Zero Copy对应的是sendfile这个函数（以Linux为例），这个函数接受
out_fd as an output (typically in a timely manner the socket handle)
in_fd handle as the input file
off_t represents in_fd offset (where to start reading)
size_t represents the number of read
Yes, Kafka used to live with mmap as file reading and writing, which is a file handle, so a direct pass it on to sendfile; offset Ye Hao resolved, users can keep themselves this offset, each request will be sent to this offset. (Remember zookeeper put in?); The amount of data easier to solve, and if consumers want faster, throw on all consumers. If this is done under normal circumstances consumers will definitely direct was crushed to death; so Kafka offers two ways --Push, I throw all of you, you're dead no matter what I do; Pull, Okay, you tell me how many you need, I'll give you the number.
to sum up
Kafka secret of speed is that it put all messages into a file. Improved I / O speed by mmap, writing data when it is added at the end so the optimum speed; when reading data directly output with sendfile violence . Ali RocketMQ is this model, but is written in Java.
Simply to test the speed of MQ does not make sense, Kafka that "violence", "rogue", "shameless" approach has been off the MQ underpants, violence is more like a "data transmitter." So for the evaluation of a MQ only at a speed of Heroes, no people in the world capable of Kafka too, when we design can not listen to online gossip - "Kafka fastest, we are using, so we did MQ with Kafka wrong". Under the influence of this idea, you might not care about "loser"; in fact possible that these "loser" is more appropriate MQ your business.