揭秘Kafka的高性能吞吐

Kafka作为时下开源动静体系，被普及地应用在数据缓冲、异步通讯、搜集日记、体系解耦等方面。对较量于RocketMQ等其他常见动静体系，Kafka在保障了大部门成果特征的同时，还提供了读写机能。

本文将针对Kafka机能方面举办简朴说明，起首简朴先容一下Kafka的架构和涉及到的名词：

• Topic：用于分别Message的逻辑观念，一个Topic可以漫衍在多个Broker上。
• Partition：是Kafka中横向扩展和统统并行化的基本，每个Topic都至少被切分为1个Partition。
• Offset：动静在Partition中的编号，编号次序不跨Partition。
• Consumer：用于从Broker中取出/斲丧Message。
• Producer：用于往Broker中发送/出产Message。
• Replication：Kafka支持以Partition为单元对Message举办冗余备份，每个Partition都可以设置至少1个Replication(当仅1个Replication时即仅该Partition自己)。
• Leader：每个Replication荟萃中的Partition城市选出一个独一的Leader，全部的读写哀求都由Leader处理赏罚。其他Replicas从Leader处把数据更新同步到当地，进程相同各人认识的MySQL中的Binlog同步。
• Broker：Kafka中行使Broker来接管Producer和Consumer的哀求，并把Message耐久化到当地磁盘。每个Cluster傍边会推举出一个Broker来接受Controller，认真处理赏罚Partition的Leader推举，和谐Partition迁徙等事变。
• ISR(In-Sync Replica)：是Replicas的一个子集，暗示今朝Alive且与Leader可以或许“Catch-up”的Replicas荟萃。因为读写都是起首落到Leader上，以是一样平常来说通过同步机制从Leader上拉取数据的Replica城市和Leader有一些耽误(包罗了耽误时刻和耽误条数两个维度)，恣意一个高出阈值城市把该Replica踢出ISR。每个Partition都有它本身独立的ISR。

以上险些是我们在行使Kafka的进程中也许碰着的全部名词，同时也无一不是最焦点的观念或组件，感受到从计划自己来说，Kafka照旧足够简捷的。这次本文环绕Kafka优秀的吞吐机能，逐个先容一下其计划与实现傍边所行使的各项“黑科技”。

Broker

差异于Redis和MemcacheQ等内存动静行列，Kafka的计划是把全部的Message都要写入速率低容量大的硬盘，以此来调换更强的存储手段。现实上，Kafka行使硬盘并没有带来过多的机能丧失，“规行矩步”的抄了一条“近道”。

起首，说“规行矩步”是由于Kafka在磁盘上只做Sequence I/O，因为动静体系读写的非凡性，这并不存在什么题目。关于磁盘I/O的机能，引用一组Kafka官方给出的测试数据(Raid-5，7200rpm)：

Sequence I/O: 600MB/s

Random I/O: 100KB/s

以是通过只做Sequence I/O的限定，规避了磁盘会见速率低下对机能也许造成的影响。

接下来我们再聊一聊Kafka是怎样“抄近道的”。

起首，Kafka重度依靠底层操纵体系提供的PageCache成果。当上层有写操纵时，操纵体系只是将数据写入PageCache，同时标志Page属性为Dirty。当读操纵产生时，先从PageCache中查找，假如产生缺页才举办磁盘调治，最终返回必要的数据。现实上PageCache是把尽也许多的空闲内存都当做了磁盘缓存来行使。同时假若有其他历程申请内存，接纳PageCache的价钱又很小，以是当代的OS都支持PageCache。

行使PageCache成果同时可以停止在JVM内部缓存数据，JVM为我们提供了强盛的GC手段，同时也引入了一些题目不合用与Kafka的计划。

• 假如在Heap内打点缓存，JVM的GC线程会频仍扫描Heap空间，带来不须要的开销。假如Heap过大，执行一次Full GC对体系的可用性来说将是极大的挑衅。
• 全部在在JVM内的工具都难免带有一个Object Overhead(万万不行小视)，内存的有用空间操作率会因此低落。
• 全部的In-Process Cache在OS中都有一份同样的PageCache。以是通过将缓存只放在PageCache，可以至少让可用缓存空间翻倍。
• 假如Kafka重启，全部的In-Process Cache城市失效，而OS打点的PageCache依然可以继承行使。

PageCache还只是第一步，Kafka为了进一步的优化机能还回收了Sendfile技能。在表明Sendfile之前，起首先容一下传统的收集I/O操纵流程，概略上分为以下4步。

OS 从硬盘把数据读到内核区的PageCache。

用户历程把数据从内核区Copy到用户区。

然后用户历程再把数据写入到Socket，数据流入内核区的Socket Buffer上。

OS 再把数据从Buffer中Copy到网卡的Buffer上，这样完成一次发送。

整个进程共经验两次Context Switch，四次System Call。统一份数据在内核Buffer与用户Buffer之间一再拷贝，服从低下。个中2、3两步没有须要，完全可以直接在内核区完成数据拷贝。这也正是Sendfile所办理的题目，颠末Sendfile优化后，整个I/O进程就酿成了下面这个样子。

通过以上的先容不丢脸出，Kafka的计划初志是尽统统全力在内存中完成数据互换，无论是对外作为一整个动静体系，或是内部同底层操纵体系的交互。假如Producer和Consumer之间出产和斲丧进度上共同适合，完全可以实现数据互换零I/O。这也就是我为什么说Kafka行使“硬盘”并没有带来过多机能丧失的缘故起因。下面是我在出产情形中采到的一些指标。

(20 Brokers, 75 Partitions per Broker, 110k msg/s)

此时的集群只有写，没有读操纵。10M/s阁下的Send的流量是Partition之间举办Replicate而发生的。从recv和writ的速度较量可以看出，写盘是行使Asynchronous+Batch的方法，底层OS也许还会举办磁盘写次序优化。而在有Read Request进来的时辰分为两种环境，第一种是内存中完成数据互换。

Send流量从均匀10M/s增进到了到均匀60M/s，而磁盘Read只有不高出50KB/s。PageCache低落磁盘I/O结果很是明明。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!