很多使用过 Kafka 的网友都在鼓吹，Kafka 可以吊打一切其它 MQ。也造成了很多网友都觉得 Kafka 才是牛逼哄哄的存在，给很多在技术选型方面的人造成了误导。
在感慨 Kafka 快的同时，我觉得必要仔细分析一下它如此快速的原因。
Kafka 是分布式的消息系统，需要处理海量的消息，Kafka 的设计初衷是把所有消息都写入速度且低容量大的硬盘，以此来换取更强的存储能力，但是实际上，使用硬盘并没有带来过性能的损失，这究竟为何？
Kafka 主要使用以下几种方式实现了超高吞吐率。
顺序读写
Kafka 的消息是不断追加到文件中的，这个特性使它可以充分利用磁盘的顺序读写能力。
顺序读写降低了硬盘磁头的寻道时间，只需要很少的扇区旋转时间，所以速度远快于随机读写。Kafka 官方给出的测试数据(Raid-5, 7200rpm)
顺序I/O: 600MB/s
随机I/O: 100KB/s
零拷贝
先简单的了解下文件系统的操作流程，例如一个程序要把文件内容发送到网络。
这个过程发生在用户空间，文件和网络socket属于硬件资源，两者之间有一个
内核空间，在操作系统内部，整个过程为:
在Linux Kernal 2.2之后出现了一种叫做“零拷贝(zero-copy)”系统调用机制，
就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存空间的直接映射，数据不再复制到“用户态缓冲区”
系统上下文切换减少2次，可以提升一倍性能
文件分段
Kafka 的队列 topic 被分为了多个区 partition, 每个 partition 又分为了多个 segment，所以一个队列中的消息实际上是保存在 N 多个片段文件中。
通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力。
批量发送
Kafka允许进行批量消息发送，先将消息缓存在内存中，然后一次请求批量发送出去，
比如可以指定缓存的消息达到某个量的时候发送，或者缓存了固定的时间后发送
这种策略大大减少了服务器端的I/O次数
数据压缩
Kafka还支持消息压缩，Producer可以通过GZIP或者Snappy格式对消息集合进行压缩，
从而减少网络传输的压力
其实这些优化都是比较常用的手段，在自己的实际工作中都可以借鉴。
总结
Kafka 速度的秘诀在于，它把所有的消息都变成一个的文件。通过 mmap 提高 I/O 速度，写入数据的时候它是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。阿里的 RocketMQ 也是这种模式，只不过是用 Java 写的。
单纯的去测试MQ的速度没有任何意义，Kafka这种“暴力”、“流氓”、“无耻”的做法已经脱了MQ的底裤，更像是一个暴力的“数据传送器”。所以对于一个MQ的评价只以速度论英雄，世界上没人能干的过Kafka，我们设计的时候不能听信网上的流言蜚语——“Kafka最快，大家都在用，所以我们的MQ用Kafka没错”。在这种思想的作用下，你可能根本不会关心“失败者”；而实际上可能这些“失败者”是更适合你业务的MQ。
Kafka的消息是保存或缓存在磁盘上的，你可能会认为：在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间。事实上，磁盘读写的快慢取决于你怎么使用它了（顺序读写、随机读写）。
Kafka的设计目标是高吞吐量，它比其它消息系统快的原因体现在以下几方面：
1、Kafka操作的是序列文件I / O（序列文件的特征是按顺序写，按顺序读），为保证顺序，Kafka强制点对点的按顺序传递消息，这意味着，一个consumer在消息流（或分区）中只有一个位置。
2、Kafka不保存消息的状态，即消息是否被“消费”。一般的消息系统需要保存消息的状态，并且还需要以随机访问的形式更新消息的状态。而Kafka 的做法是保存Consumer在Topic分区中的位置offset，在offset之前的消息是已被“消费”的，在offset之后则为未“消费”的，并且offset是可以任意移动的，这样就消除了大部分的随机IO。
3、Kafka支持点对点的批量消息传递。
4、Kafka的消息存储在OS pagecache（页缓存，page cache的大小为一页，通常为4K，在linux读写文件时，它用于缓存文件的逻辑内容，从而加快对磁盘上映像和数据的访问）。