Kafka通常以集群的方式進行部署使用，每一個Kafka節(jié)點稱為一個Broker。Kafka中會有很多個消息隊列，每個消息隊列稱為一個topic。每個Topic也會分成很多Partition，分別存儲在每個Broker上面。

Kafka的broker信息以及會話偏移量存儲在Zookeeper中，當某一topic配置replication屬性時，Zookeeper還會決定哪一個Broker成為特定Partition的Leader。

Kafka的架構(gòu)

性能測試內(nèi)容：

kafka的測試主要分為producer端的吞吐量，consumer端的吞吐量，以及判斷影響兩者的因素。在實際測試環(huán)境中，需根據(jù)具體情況調(diào)整測試的數(shù)據(jù)量與參數(shù)。

性能測試工具：

我們使用Kafka自帶的性能測試工具完成本次測試，當安裝了Apache 版本的Kafka時，該測試工具的位置在安裝目錄的bin目錄下；當安裝了CDH版本的Kafka時，該測試工具一般位于Kafka Parcel路徑下，默認位置為：/opt/cloudera/parcels/KAFKA/lib/kafka/bin。

這里我們用到的測試工具為：

kafka-producer-perf-test.sh  (生產(chǎn)端)

kafka-consumer-perf-test.sh  (消費端)

性能測試環(huán)境：

三臺同樣的虛擬機作為kafka broker，IP地址為192.168.1.81-192.168.1.83，配置如下：

CPU       內(nèi)存       磁盤

4core     16G       100G

a.Partition與速率的關(guān)系

方法：

建立兩個topic, 兩個topic除了partition數(shù)量不一致外其他參數(shù)*一致，使用kafka-producer-perf-test.sh進行測試。

過程：

首先建立兩個topic，分別為test_part1與test_part2:

test_part1進行測試跑批：

kafka-producer-perf-test.sh --topic test_part1 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092

運行結(jié)果：

2000000 records sent, 136211.945788 records/sec (25.98 MB/sec), 1002.59 ms avg latency, 2559.00 ms max latency, 801 ms 50th, 2271 ms 95th, 2538 ms 99th, 2553 ms 99.9th.

test_part2進行測試跑批：

kafka-producer-perf-test.sh --topic test_part2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092

運行結(jié)果：

2000000 records sent, 187529.301453 records/sec (35.77 MB/sec), 520.00 ms avg latency, 2196.00 ms max latency, 336 ms 50th, 1922 ms 95th, 2159 ms 99th, 2190 ms 99.9th.

結(jié)論：Producer端傳輸效率和partition數(shù)成正比。

b.Replication與速率的關(guān)系

方法：

首先建立兩個topic, 兩個topic除了replication數(shù)量不一致外其他參數(shù)*一致，使用kafka-producer-perf-test.sh進行測試。

過程：

首先建立兩個topic，分別為test_rep1與test_rep2:

test_rep1進行跑批測試：

kafka-producer-perf-test.sh --topic test_rep1 --num-records 2000000 --record-size

運行結(jié)果：

2000000 records sent, 217438.573603 records/sec (41.47 MB/sec), 610.43 ms avg latency, 1387.00 ms max latency, 497 ms 50th, 1284 ms 95th, 1341 ms 99th, 1386 ms 99.9th.

test_rep2進行跑批測試：

kafka-producer-perf-test.sh --topic test_rep2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092

運行結(jié)果：

2000000 records sent, 103423.311614 records/sec (19.73 MB/sec), 1353.03 ms avg latency, 4050.00 ms max latency, 1213 ms 50th, 3042 ms 95th, 3998 ms 99th, 4047 ms 99.9th

結(jié)論：Producer端傳輸效率和replication數(shù)量成反比。

C.傳輸?shù)臄?shù)據(jù)記錄大小與速率的關(guān)系

方法：

向一個topic寫入大小不同的數(shù)據(jù)記錄，檢驗是否對速率有影響。

過程：

首先建立一個test topic：

使用小數(shù)據(jù)塊跑批：

kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092

運行結(jié)果：

1000000 records sent, 149231.457991 records/sec (28.46 MB/sec), 814.24 ms avg latency, 1334.00 ms max latency, 810 ms 50th, 1290 ms 95th, 1327 ms 99th, 1333 ms 99.9th.

使用大數(shù)據(jù)塊跑批：

kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 2048 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092

運行結(jié)果：

1000000 records sent, 22161.155926 records/sec (43.28 MB/sec), 637.75 ms avg latency, 1598.00 ms max latency, 576 ms 50th, 959 ms 95th, 1547 ms 99th, 1580 ms 99.9th.

結(jié)論：Producer端傳輸數(shù)量和單條記錄大小成正比。

由于kafka-consumer-perf-test.sh返回結(jié)果并不像producer端那么簡潔易懂，這里解釋一下，這個命令會返回類似以下的結(jié)果：

總共六個參數(shù)：

個是開始時間；

第二個是結(jié)束時間；

第三個是本次消費了多少MB數(shù)據(jù)；

第四個是本次消費的速率MB/S；

第五個是總的消費數(shù)據(jù)條數(shù)；

第六個是每秒消費數(shù)據(jù)條數(shù)。

a.Partition與速率的關(guān)系

方法：

首先建立兩個topic, 兩個topic除了partition數(shù)量不一致外其他參數(shù)*一致，使用kafka-consumer-perf-test.sh進行測試。

過程：

建立topic，這里沿用Customer端測試過程中建立的test_part1和test_part2.

test_part1進行跑批測試：

kafka-consumer-perf-test.sh --topic test_part1 --messages 1000000 --threads 1  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181

運行結(jié)果：

2018-12-18 13:47:53:297, 2018-12-18 13:47:55:078, 190.7349, 107.0943, 1000000, 561482.3133

test_part2進行跑批測試：

kafka-consumer-perf-test.sh --topic test_part2 --messages 1000000 --threads 1  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181

運行結(jié)果：

2018-12-18 13:51:43:887, 2018-12-18 13:51:45:619, 190.7349, 110.1241, 1000000, 577367.2055

結(jié)論：Customer端消費效率和partitions數(shù)成正比（但影響不大）。

b.Threads與速率的關(guān)系

方法：

在一個topic中消費相同的數(shù)據(jù)，使用不同的threads，比較速率大小。

過程：

建立Topic，這里沿用Customer端測試過程中建立過的test。

使用一個線程消費時：

運行結(jié)果：

2018-12-18 14:11:32:106, 2018-12-18 14:11:32:951, 95.3671, 112.8604, 500000, 591715.9763

使用三個線程消費時：

運行結(jié)果：

2018-12-18 14:12:54:716, 2018-12-18 14:12:54:718, 95.3671, 47683.5270, 500000, 250000000.0000

使用六個線程消費時：

運行結(jié)果：

2018-12-18 14:14:12:935, 2018-12-18 14:14:12:938, 95.3671, 31789.0180, 500000, 166666666.6667

結(jié)論：Cumsomer端消費速率和thread成正比，但是達到一定數(shù)量(parttion數(shù)量)以后趨于平穩(wěn)，再增加也不會繼續(xù)變大。

由于每個kafka集群環(huán)境差異都很大，本文不代表所有情況。

但是一個通常的kafka生產(chǎn)集群以下特性是應該達到的：