分区是Kafka中最小的并行操作单元，对于生产者而言，对于每一个分区的数据写入是完全可以并行化的；对于消费者而言，Kafka只允许单个分区中的消息被一个消费者线程所消费，一个消费组的消费并行度完全依赖于所消费的分区数。如此看来，如果一个主题中的分区数越多，理论上所能达到的吞吐量就越大，那么事实真的如预想的一样么？
不妨我们使用kafka-producer-perf-test.sh脚本和kafka-consumer-perf-test.sh脚本这两个性能测试工具来实际地测试一下。首先我们分别创建分区数为1、20、50、100、200、500、1000的主题，对应的主题名称分别为topic-1、topic-20、topic-50、topic-100、topic-200、topic-500、topic-1000，所有主题的副本因子都设置为1。
消息中间件的性能一般是指吞吐量。抛开硬件资源的影响，消息写入的吞吐量还会受到消息大小、消息压缩方式、消息发送方式（同步/异步）、消息确认类型（acks）、副本因子等参数的影响，消息消费的吞吐量还会受到应用逻辑处理速度的影响。本次案例中暂不考虑这些因素的影响，所有的测试除了主题的分区数不同之外，其余的因素都保持相同。
本次案例中所使用的测试环境为一个由3台普通云主机组成的3节点的Kafka集群，每台云主机内存8G、磁盘40GB、4核CPU主频为2600MHz。JVM版本为1.8.0_112，Linux系统版本为2.6.32-504.23.4.el6.x86_64。
使用kafka-producer-perf-test.sh脚本分别往这些主题中发送100万条消息体大小为1KB的消息，相对应的测试命令如下：
bin/kafka-producer-perf-test.sh --topic topic-xxx
--num-records 1000000 --record-size 1024
--throughput 100000000 --producer-props
bootstrap.servers=localhost:9092 acks=1
相对应的测试结果如下图所示。对于不同的硬件环境，甚至不同批次的测试得到的测试结果也不会完全相同，但是总体趋势还是会保持和图中的一样。
在这里插入图片描述
在上图中，我们可以看到分区数为1时吞吐量最低，随着分区数的增长，相应的吞吐量也跟着上涨。一旦分区数超过了某个阈值之后整体的吞吐量是不升反降的，也就是说并不是分区数越多吞吐量也就越大。这里的分区数临界阈值针对不同的测试环境也会表现出不同的结果，实际应用中可以通过类似的测试案例来找到一个合理的临界值区间。
上面针对的是消息生产者的测试，对于消息消费者而言同样也有吞吐量方面的考量。使用kafka-consumer-perf-test.sh脚本分别消费这些主题中的100万条消息，相对应的测试命令如下：
bin/kafka-consumer-perf-test.sh --topic topic-xxx
--messages 1000000 --broker-list localhost:9092
消费者性能测试的结果如下图所示。与生产者性能测试相同的是，对于不同的测试环境或者不同的测试批次所得到的测试结果也不尽相同，但总体趋势还是会保持和图中的一样。
在这里插入图片描述
在上图中，开始随着分区数的增加相应的吞吐量也会有多增长。一旦分区数超过了某个阈值之后整体的吞吐量也同样是不升反降的，同样说明了分区数越多并不会使得吞吐量一直增长。
分区数越多吞吐量也就越高？很多资料都认可这一观点，但实际上很多事情都会有一个临界值，当超过这个临界值之后，很多原本符合既定逻辑的走向又会变得不同。读者需要对此有个清晰的认知，懂得去伪求真，而实地测试验证不失为一座通向真知的桥梁。
欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。
image
网友评论