歡迎跳轉到本文原文地址：https://honeypps.com/mq/is-that-the-more-partitions-in-kafka-topic-the-higher-throughout/

分區是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

消費者性能測試的結果如下圖所示。與生產者性能測試相同的是，對于不同的測試環境或者不同的測試批次所得到的測試結果也不盡相同，但總體趨勢還是會保持和圖中的一樣。

在上圖中，開始隨著分區數的增加相應的吞吐量也會有多增長。一旦分區數超過了某個閾值之后整體的吞吐量也同樣是不升反降的，同樣說明了分區數越多并不會使得吞吐量一直增長。

分區數越多吞吐量也就越高？很多資料都認可這一觀點，但實際上很多事情都會有一個臨界值，當超過這個臨界值之后，很多原本符合既定邏輯的走向又會變得不同。讀者需要對此有個清晰的認知，懂得去偽求真，而實地測試驗證不失為一座通向真知的橋梁。

歡迎跳轉到本文原文地址：https://honeypps.com/mq/is-that-the-more-partitions-in-kafka-topic-the-higher-throughout/

---

歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。

總結

以上是生活随笔為你收集整理的Kafka主题中的分区数越多吞吐量就越高？BULLSHIT!!!的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。