摘要
本文主要介紹了如何利用Kafka自帶的性能測試腳本及Kafka Manager測試Kafka的性能，以及如何使用Kafka Manager監控Kafka的工作狀态，最後給出了Kafka的性能測試報告。
性能測試及叢集監控工具
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_HOME/bin/kafka-consumer-perf-test.sh
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(R) Xeon(R) 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時的叢集總吞吐量如下圖所示