原文地址：http://www.infoq.com/cn/articles/kafka-analysis-part-5?utm_source=infoq&utm_campaign=user_page&utm_medium=link

性能測試及集群監(jiān)控工具

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項指標，總共發(fā)送消息量（以MB為單位），每秒發(fā)送消息量（MB/second），發(fā)送消息總數(shù)，每秒發(fā)送消息數(shù)（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的收集與報告（或者說發(fā)布）分離，可以根據(jù)需要自由組合。目前它支持的Reporter有Console Reporter，JMX Reporter，HTTP Reporter，CSV Reporter，SLF4J Reporter，Ganglia Reporter，Graphite Reporter。因此，Kafka也支持通過以上幾種Reporter輸出其Metrics信息。

使用JConsole查看單服務器Metrics

使用JConsole通過JMX，是在不安裝其它工具（既然已經(jīng)安裝了Kafka，就肯定安裝了Java，而JConsole是Java自帶的工具）的情況下查看Kafka服務器Metrics的最簡單最方便的方法之一。

首先必須通過為環(huán)境變量JMX_PORT設置有效值來啟用Kafka的JMX Reporter。如export JMX_PORT=19797。然后即可使用JConsole通過上面設置的端口來訪問某一臺Kafka服務器來查看其Metrics信息，如下圖所示。

使用JConsole的一個好處是不用安裝額外的工具，缺點很明顯，數(shù)據(jù)展示不夠直觀，數(shù)據(jù)組織形式不友好，更重要的是不能同時監(jiān)控整個集群的Metrics。在上圖中，在kafka.cluster->Partition->UnderReplicated->topic4下，只有2和5兩個節(jié)點，這并非因為topic4只有這兩個Partition的數(shù)據(jù)是處于復制狀態(tài)的。事實上，topic4在該Broker上只有這2個Partition，其它Partition在其它Broker上，所以通過該服務器的JMX Reporter只看到了這兩個Partition。

通過Kafka Manager查看整個集群的Metrics

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

• 管理多個集群
• 方便查看集群狀態(tài)
• 執(zhí)行preferred replica election
• 批量為多個Topic生成并執(zhí)行Partition分配方案
• 創(chuàng)建Topic
• 刪除Topic（只支持0.8.2及以上版本，同時要求在Broker中將delete.topic.enable設置為true）
• 為已有Topic添加Partition
• 更新Topic配置
• 在Broker JMX Reporter開啟的前提下，輪詢Broker級別和Topic級別的Metrics
• 監(jiān)控Consumer Group及其消費狀態(tài)
• 支持添加和查看LogKafka

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

這里要注意，此處添加Cluster是指添加一個已有的Kafka集群進入監(jiān)控列表，而非通過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功能監(jiān)控性能測試過程中的吞吐率。

本文主要測試如下四種場景，測試的指標主要是每秒多少兆字節(jié)數(shù)據(jù)，每秒多少條消息。

Producer Only

這組測試不使用任何Consumer，只啟動Broker和Producer。

Producer Number VS. Throughput

實驗條件：3個Broker，1個Topic，6個Partition，無Replication，異步模式，消息Payload為100字節(jié)。

測試項目：分別測試1，2，3個Producer時的吞吐量。

測試目標：如Kafka設計解析（一）- Kafka背景及架構介紹所介紹，多個Producer可同時向同一個Topic發(fā)送數(shù)據(jù)，在Broker負載飽和前，理論上Producer數(shù)量越多，集群每秒收到的消息量越大，并且呈線性增漲。本實驗主要驗證該特性。同時作為性能測試，本實驗還將監(jiān)控測試過程中單個Broker的CPU和內存使用情況

測試結果：使用不同個數(shù)Producer時的總吞吐率如下圖所示

由上圖可看出，單個Producer每秒可成功發(fā)送約128萬條Payload為100字節(jié)的消息，并且隨著Producer個數(shù)的提升，每秒總共發(fā)送的消息量線性提升，符合之前的分析。

性能測試過程中，Broker的CPU和內存使用情況如下圖所示。

(點擊放大圖像)

由上圖可知，在每秒接收約117萬條消息（3個Producer總共每秒發(fā)送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字節(jié)時的集群總吞吐量。

測試結果：不同消息長度時的集群總吞吐率如下圖所示:

由上圖可知，消息越長，每秒所能發(fā)送的消息數(shù)越少，而每秒所能發(fā)送的消息的量（MB）越大。另外，每條消息除了Payload外，還包含其它Metadata，所以每秒所發(fā)送的消息量比每秒發(fā)送的消息數(shù)乘以100字節(jié)大，而Payload越大，這些Metadata占比越小，同時發(fā)送時的批量發(fā)送的消息體積越大，越容易得到更高的每秒消息量（MB/s）。其它測試中使用的Payload為100字節(jié)，之所以使用這種短消息（相對短）只是為了測試相對比較差的情況下的Kafka吞吐率。

Partition Number VS. Throughput

實驗條件：3個Broker，1個Topic，無Replication，異步模式，3個Producer，消息Payload為100字節(jié)。

測試項目：分別測試1到9個Partition時的吞吐量。

測試結果：不同Partition數(shù)量時的集群總吞吐率如下圖所示：

由上圖可知，當Partition數(shù)量小于Broker個數(shù)（3個）時，Partition數(shù)量越大，吞吐率越高，且呈線性提升。本文所有實驗中，只啟動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數(shù)量小于等于3個時，越多的Partition代表越多的Broker為該Topic服務。如前幾篇文章所述，不同Broker上的數(shù)據(jù)并行插入，這就解釋了當Partition數(shù)量小于等于3個時，吞吐率隨Partition數(shù)量的增加線性提升。

當Partition數(shù)量多于Broker個數(shù)時，總吞吐量并未有所提升，甚至還有所下降。可能的原因是，當Partition數(shù)量為4和5時，不同Broker上的Partition數(shù)量不同，而Producer會將數(shù)據(jù)均勻發(fā)送到各Partition上，這就造成各Broker的負載不同，不能最大化集群吞吐量。而上圖中當Partition數(shù)量為Broker數(shù)量整數(shù)倍時吞吐量明顯比其它情況高，也證實了這一點。

Replica Number VS. Throughput

實驗條件：3個Broker，1個Topic，6個Partition，異步模式，3個Producer，消息Payload為100字節(jié)。

測試項目：分別測試1到3個Replica時的吞吐率。

測試結果：如下圖所示:

由上圖可知，隨著Replica數(shù)量的增加，吞吐率隨之下降。但吞吐率的下降并非線性下降，因為多個Follower的數(shù)據(jù)復制是并行進行的，而非串行進行。

Consumer Only

實驗條件：3個Broker，1個Topic，6個Partition，無Replication，異步模式，消息Payload為100字節(jié)。

測試項目：分別測試1到3個Consumer時的集群總吞吐率。
測試結果：在集群中已有大量消息的情況下，使用1到3個Consumer時的集群總吞吐量如下圖所示：

由上圖可知，單個Consumer每秒可消費306萬條消息，該數(shù)量遠大于單個Producer每秒可消費的消息數(shù)量，這保證了在合理的配置下，消息可被及時處理。并且隨著Consumer數(shù)量的增加，集群總吞吐量線性增加。

根據(jù)Kafka設計解析（四）- Kafka Consumer設計解析所述，多Consumer消費消息時以Partition為分配單位，當只有1個Consumer時，該Consumer需要同時從6個Partition拉取消息，該Consumer所在機器的I/O成為整個消費過程的瓶頸，而當Consumer個數(shù)增加至2個至3個時，多個Consumer同時從集群拉取消息，充分利用了集群的吞吐率。

Producer Consumer pair

實驗條件：3個Broker，1個Topic，6個Partition，無Replication，異步模式，消息Payload為100字節(jié)。

測試項目：測試1個Producer和1個Consumer同時工作時Consumer所能消費到的消息量。

測試結果：1,215,613 records/second。

轉載于:https://www.cnblogs.com/davidwang456/articles/7027750.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Kafka设计解析（五）：Kafka Benchmark--转的全部內容，希望文章能夠幫你解決所遇到的問題。

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