很多使用过 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读写文件时,它用于缓存文件的逻辑内容,从而加快对磁盘上映像和数据的访问)。