Kafka 设计解析（五）：Kafka Benchmark

性能测试及集群监控工具

Kafka 提供了非常多有用的工具，如 Kafka 设计解析（三）- Kafka High Availability （下）中提到的运维类工具——Partition Reassign Tool，Preferred Replica Leader Election Tool，Replica Verification Tool，State Change Log Merge Tool。本章将介绍 Kafka 提供的性能测试工具，Metrics 报告工具及 Yahoo 开源的 Kafka Manager。

Kafka 性能测试脚本

• $KAFKA_HOME/bin/kafka-producer-perf-test.sh 该脚本被设计用于测试 Kafka Producer 的性能，主要输出 4 项指标，总共发送消息量（以 MB 为单位），每秒发送消息量（MB/second），发送消息总数，每秒发送消息数（records/second）。除了将测试结果输出到标准输出外，该脚本还提供 CSV Reporter，即将结果以 CSV 文件的形式存储，便于在其它分析工具中使用该测试结果
• $KAFKA_HOME/bin/kafka-consumer-perf-test.sh 该脚本用于测试 Kafka Consumer 的性能，测试指标与 Producer 性能测试脚本一样。

Kafka Metrics

Kafka 使用 Yammer Metrics 来报告服务端和客户端的 Metric 信息。Yammer Metrics 3.1.0 提供 6 种形式的 Metrics 收集——Meters，Gauges，Counters，Histograms，Timers，Health Checks。与此同时，Yammer Metrics 将 Metric 的收集与报告（或者说发布）分离，可以根据需要自由组合。目前它支持的 Reporter 有 Console Reporter，JMX Reporter，HTTP Reporter，CSV Reporter，SLF4J Reporter，Ganglia Reporter，Graphite Reporter。因此，Kafka 也支持通过以上几种 Reporter 输出其 Metrics 信息。

使用 JConsole 查看单服务器 Metrics

使用 JConsole 通过 JMX，是在不安装其它工具（既然已经安装了 Kafka，就肯定安装了 Java，而 JConsole 是 Java 自带的工具）的情况下查看 Kafka 服务器 Metrics 的最简单最方便的方法之一。

首先必须通过为环境变量 JMX_PORT 设置有效值来启用 Kafka 的 JMX Reporter。如export JMX_PORT=19797。然后即可使用 JConsole 通过上面设置的端口来访问某一台 Kafka 服务器来查看其 Metrics 信息，如下图所示。

使用 JConsole 的一个好处是不用安装额外的工具，缺点很明显，数据展示不够直观，数据组织形式不友好，更重要的是不能同时监控整个集群的 Metrics。在上图中，在 kafka.cluster->Partition->UnderReplicated->topic4 下，只有 2 和 5 两个节点，这并非因为 topic4 只有这两个 Partition 的数据是处于复制状态的。事实上，topic4 在该 Broker 上只有这 2 个 Partition，其它 Partition 在其它 Broker 上，所以通过该服务器的 JMX Reporter 只看到了这两个 Partition。

通过 Kafka Manager 查看整个集群的 Metrics

Kafka Manager 是 Yahoo 开源的 Kafka 管理工具。它支持如下功能：

• 管理多个集群
• 方便查看集群状态
• 执行 preferred replica election
• 批量为多个 Topic 生成并执行 Partition 分配方案
• 创建 Topic
• 删除 Topic（只支持 0.8.2 及以上版本，同时要求在 Broker 中将delete.topic.enable设置为 true）
• 为已有 Topic 添加 Partition
• 更新 Topic 配置
• 在 Broker JMX Reporter 开启的前提下，轮询 Broker 级别和 Topic 级别的 Metrics
• 监控 Consumer Group 及其消费状态
• 支持添加和查看 LogKafka

安装好 Kafka Manager 后，添加 Cluster 非常方便，只需指明该 Cluster 所使用的 Zookeeper 列表并指明 Kafka 版本即可，如下图所示。

这里要注意，此处添加 Cluster 是指添加一个已有的 Kafka 集群进入监控列表，而非通过 Kafka Manager 部署一个新的 Kafka Cluster，这一点与 Cloudera Manager 不同。

Kafka Benchmark

Kafka 的一个核心特性是高吞吐率，因此本文的测试重点是 Kafka 的吞吐率。

本文的测试共使用 6 台安装 Red Hat 6.6 的虚拟机，3 台作为 Broker，另外 3 台作为 Producer 或者 Consumer。每台虚拟机配置如下：

• CPU：8 vCPU， Intel® Xeon® CPU E5-2680 v2 @ 2.80GHz，2 Sockets，4 Cores per socket，1 Thread per core
• 内存：16 GB
• 磁盘：500 GB

开启 Kafka JMX Reporter 并使用 19797 端口，利用 Kafka-Manager 的 JMX polling 功能监控性能测试过程中的吞吐率。

本文主要测试如下四种场景，测试的指标主要是每秒多少兆字节数据，每秒多少条消息。

Producer Only

这组测试不使用任何 Consumer，只启动 Broker 和 Producer。

Producer Number VS. Throughput

实验条件：3 个 Broker，1 个 Topic，6 个 Partition，无 Replication，异步模式，消息 Payload 为 100 字节。

测试项目：分别测试 1，2，3 个 Producer 时的吞吐量。

测试目标：如 Kafka 设计解析（一）- Kafka 背景及架构介绍所介绍，多个 Producer 可同时向同一个 Topic 发送数据，在 Broker 负载饱和前，理论上 Producer 数量越多，集群每秒收到的消息量越大，并且呈线性增涨。本实验主要验证该特性。同时作为性能测试，本实验还将监控测试过程中单个 Broker 的 CPU 和内存使用情况

测试结果：使用不同个数 Producer 时的总吞吐率如下图所示

由上图可看出，单个 Producer 每秒可成功发送约 128 万条 Payload 为 100 字节的消息，并且随着 Producer 个数的提升，每秒总共发送的消息量线性提升，符合之前的分析。

性能测试过程中，Broker 的 CPU 和内存使用情况如下图所示。

(点击放大图像)

由上图可知，在每秒接收约117 万条消息（3 个Producer 总共每秒发送350 万条消息，平均每个Broker 每秒接收约117 万条）的情况下，一个Broker 的CPU 使用量约为248%，内存使用量为601 MB。

Message Size VS. Throughput

实验条件：3 个 Broker，1 个 Topic，6 个 Partition，无 Replication，异步模式，3 个 Producer。

测试项目：分别测试消息长度为 10，20，40，60，80，100，150，200，400，800，1000，2000，5000，10000 字节时的集群总吞吐量。

测试结果：不同消息长度时的集群总吞吐率如下图所示:

由上图可知，消息越长，每秒所能发送的消息数越少，而每秒所能发送的消息的量（MB）越大。另外，每条消息除了 Payload 外，还包含其它 Metadata，所以每秒所发送的消息量比每秒发送的消息数乘以 100 字节大，而 Payload 越大，这些 Metadata 占比越小，同时发送时的批量发送的消息体积越大，越容易得到更高的每秒消息量（MB/s）。其它测试中使用的 Payload 为 100 字节，之所以使用这种短消息（相对短）只是为了测试相对比较差的情况下的 Kafka 吞吐率。

Partition Number VS. Throughput

实验条件：3 个 Broker，1 个 Topic，无 Replication，异步模式，3 个 Producer，消息 Payload 为 100 字节。

测试项目：分别测试 1 到 9 个 Partition 时的吞吐量。

测试结果：不同 Partition 数量时的集群总吞吐率如下图所示：

由上图可知，当 Partition 数量小于 Broker 个数（3 个）时，Partition 数量越大，吞吐率越高，且呈线性提升。本文所有实验中，只启动 3 个 Broker，而一个 Partition 只能存在于 1 个 Broker 上（不考虑 Replication。即使有 Replication，也只有其 Leader 接受读写请求），故当某个 Topic 只包含 1 个 Partition 时，实际只有 1 个 Broker 在为该 Topic 工作。如之前文章所讲，Kafka 会将所有 Partition 均匀分布到所有 Broker 上，所以当只有 2 个 Partition 时，会有 2 个 Broker 为该 Topic 服务。3 个 Partition 时同理会有 3 个 Broker 为该 Topic 服务。换言之，Partition 数量小于等于 3 个时，越多的 Partition 代表越多的 Broker 为该 Topic 服务。如前几篇文章所述，不同 Broker 上的数据并行插入，这就解释了当 Partition 数量小于等于 3 个时，吞吐率随 Partition 数量的增加线性提升。

当 Partition 数量多于 Broker 个数时，总吞吐量并未有所提升，甚至还有所下降。可能的原因是，当 Partition 数量为 4 和 5 时，不同 Broker 上的 Partition 数量不同，而 Producer 会将数据均匀发送到各 Partition 上，这就造成各 Broker 的负载不同，不能最大化集群吞吐量。而上图中当 Partition 数量为 Broker 数量整数倍时吞吐量明显比其它情况高，也证实了这一点。

Replica Number VS. Throughput

实验条件：3 个 Broker，1 个 Topic，6 个 Partition，异步模式，3 个 Producer，消息 Payload 为 100 字节。

测试项目：分别测试 1 到 3 个 Replica 时的吞吐率。

测试结果：如下图所示:

由上图可知，随着 Replica 数量的增加，吞吐率随之下降。但吞吐率的下降并非线性下降，因为多个 Follower 的数据复制是并行进行的，而非串行进行。

Consumer Only

实验条件：3 个 Broker，1 个 Topic，6 个 Partition，无 Replication，异步模式，消息 Payload 为 100 字节。

测试项目：分别测试 1 到 3 个 Consumer 时的集群总吞吐率。
测试结果：在集群中已有大量消息的情况下，使用 1 到 3 个 Consumer 时的集群总吞吐量如下图所示：

由上图可知，单个 Consumer 每秒可消费 306 万条消息，该数量远大于单个 Producer 每秒可消费的消息数量，这保证了在合理的配置下，消息可被及时处理。并且随着 Consumer 数量的增加，集群总吞吐量线性增加。

根据 Kafka 设计解析（四）- Kafka Consumer 设计解析所述，多 Consumer 消费消息时以 Partition 为分配单位，当只有 1 个 Consumer 时，该 Consumer 需要同时从 6 个 Partition 拉取消息，该 Consumer 所在机器的 I/O 成为整个消费过程的瓶颈，而当 Consumer 个数增加至 2 个至 3 个时，多个 Consumer 同时从集群拉取消息，充分利用了集群的吞吐率。

Producer Consumer pair

实验条件：3 个 Broker，1 个 Topic，6 个 Partition，无 Replication，异步模式，消息 Payload 为 100 字节。

测试项目：测试 1 个 Producer 和 1 个 Consumer 同时工作时 Consumer 所能消费到的消息量。

测试结果：1,215,613 records/second。

作者简介

郭俊（Jason），硕士，从事大数据平台研发工作，精通 Kafka 等分布式消息系统，Storm 等流式处理系统及数据仓库性能调优。
个人博客： http://www.jasongj.com
新浪微博：郭俊 _Jason
微信： habren
公众号：大数据架构

感谢郭蕾对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。