kafka選擇分區(qū)數及kafka性能測試

1、簡言

​ 如何選擇合適的分區(qū)，這是我們經常面臨的問題，不過針對這個問題，在網上并沒有搜到固定的答案。因此，今天在這里主要通過性能測試的工具來告訴如何選擇相對應的kafka分區(qū)。

2、性能測試工具

​ kafka本身提供了比較的性能測試工具，我們可以使用它來測試適用于我們機器的kafka分區(qū)。

① 生產者性能測試

分別創(chuàng)建三個topic，副本數設置為1。

bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 15 --topic test1
bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 150 --topic test2
bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 100 --topic test3

采用生產者性能測試工具來測試：

• num-records 100萬條消息
• record-size 20480 每條消息是20K
• throughput 用來進行限流控制 當設置為0的時候不限流(盡量還是限流，否則很有可能kafka頂不住壓力)，所以這里設置為每秒鐘30000條消息數

bin/kafka-producer-perf-test.sh --topic topic --num-records 1000000 --record-size 20480 --throughput 30000 --producer-props bootstrap.servers="server01" acks=1

我們看實際的效果

15個分區(qū)結果

1000000 records sent, 6411.448282 records/sec (125.22 MB/sec), 253.02 ms avg latency, 1680.00 ms max latency, 108 ms 50th, 1026 ms 95th, 1173 ms 99th, 1650 ms 99.9th.

50個分區(qū)

1000000 records sent, 6274.549174 records/sec (122.55 MB/sec), 259.04 ms avg latency, 2163.00 ms max latency, 56 ms 50th, 1087 ms 95th, 1334 ms 99th, 2077 ms 99.9th.

100個分區(qū)

1000000 records sent, 6417.990912 records/sec (125.35 MB/sec), 253.42 ms avg latency, 2594.00 ms max latency, 38 ms 50th, 1154 ms 95th, 1331 ms 99th, 2537 ms 99.9th.

從中我們可以看出，分區(qū)數并不是越多越好，在吞吐量到達一定程度的時候，我們不一定要增大分區(qū)數，因為分區(qū)數過大，不會提升吞吐量（可以測試一下1000個分區(qū)甚至10000個分區(qū)，吞吐量會下降，這里就不一一演示），且會造成錯誤(后面解釋)

② 消費者性能測試

bin/kafka-consumer-perf-test.sh --topic test5 --messages 100000 --broker-list "kafka-node1,kafka-node2"

​ 消費者測試結果，我們知道kafka出來的數據單元為message，所以我們的messages就是kafka消費的條數

start.time（開始時間）, end.time（結束時間）, data.consumed.in.MB（消費的消息總量，單位為M）, MB.sec(消費吞吐量（MB/S）), data.consumed.in.nMsg（消費的消息總數）, nMsg.sec（按消息個數計算的吞吐量）, rebalance.time.ms（再平衡的時間，單位為ms）, fetch.time.ms（拉取消息的持續(xù)時間，單位為ms）, fetch.MB.sec（每秒拉取消息的字節(jié)大小，MB/S）, fetch.nMsg.sec（每秒拉取消息的個數） 2019-03-19 20:05:54:470, 2019-03-19 20:06:09:001, 1954.3359, 134.4942, 100062, 6886.1056, 3904, 10627, 183.9029, 9415.8276

​ 這是消費者拉取數據測試的結果，我們也可以多測不同分區(qū)的幾組數據，獲得一個合適的kafka分區(qū)數據，來保證我們集群的穩(wěn)定運行。

當然，如果想要測試其他參數，可以使用下圖的方式，同理我們的生產者壓測也可以通過此方式知道每個參數的含義

3、分區(qū)數決定吞吐量？

​ 分區(qū)是kafka中最小的并行操作單元，對生產者而言，每一個分區(qū)的數據寫入是完全可以并行化的；但是，對消費者而言，kafka只允許單個分區(qū)中的消息被一個消費者線程消費，一個消費組的消費并行度完全依賴于所消費的分區(qū)數。

如果按照這種方法看來，如果一個主題中的分區(qū)數越多，理論上所能達到的吞吐量就越大，那么事實真的如此么？

我們可以使用我們生產者與消費者測試工具進行相應的測試。(可以看根據上面的，多測幾組數據)

實際測試過程中，我們可以發(fā)現，開始的時候，隨著分區(qū)的增長，相應的吞吐量也跟著上漲，一旦分區(qū)數超過了某個閾值后，整體的吞吐量是不升反降的，也就是說，并不是分區(qū)數越多，吞吐量就越大。

因此我們在實際的選擇分區(qū)過程中，要盡量的多測幾組數據，找到一個合適的值，這也告訴我們，在實際生產者過程中，我們自己要去做好測試，而不是去想當然的得出結論。

實踐，是檢驗真理的唯一標準。

并且，一味的增加分區(qū)數并不能使我們的吞吐量得到提升，還會因為超過系統(tǒng)的默認值，引起kafka進程崩潰。本人在生產環(huán)境中，將kafka分區(qū)數設置的過大，曾導致在實時流環(huán)境中，kafka進程多次崩潰。迫不得已的修改系統(tǒng)參數。

我們可以試著在一臺普通的linux機器上創(chuàng)建包含10000個分區(qū)的主題，執(zhí)行完成后通過jps查看kafka進程是否還存在，一般情況下，會導致kafka進程崩潰，這個時候，我們可以打開kafka的日志服務文件，發(fā)現日志服務文件中出現大量的異常。

java.io.IOException: Too many open files

這是一種常見的linux系統(tǒng)錯誤，通常意味著文件描述符不足。這一般發(fā)生在創(chuàng)建線程，創(chuàng)建socket，打開文件的場景下，在linux的系統(tǒng)的默認設置下，它只有1024。

我們可以通過ulimit -n命令查看，當然，我們也可以查看kafka的文件描述符：

當我們kafka進程崩潰后，這里的文件描述符將是0，表明它已經達到了上限。當然，對于大數據集群來說，文件描述符太小也不太合適，我們可以適當增加這個參數的值。但是，我們并不能無限制的去增加kafka的分區(qū)數，這是沒有必要的。我們只需要通過壓測的方式尋找最適合自己kafka的分區(qū)數就OK了。

并且，kafka的分區(qū)數還會影響系統(tǒng)的可用性。

我們知道，kafka通過多副本機制來實現集群的高可用和高可靠性，每個分區(qū)都會有一至多個副本，每個副本存在于不同的broker節(jié)點，并且只有l(wèi)eader副本對外提供服務，在kafka集群內部，所有的副本都采用自動化的方式進行管理，并確保所有副本中的數據都能保持一定程度的同步。

當broker發(fā)生故障時，leader副本所屬宿主的broker節(jié)點上的所有分區(qū)都將暫時處于不可用的狀態(tài)，此時，kafka會自動在其他follwer副本中選舉出新的leader用于接收客戶端的請求。

整個過程由kafka控制器負責，分區(qū)在進行l(wèi)eader角色切換的過程中會變得不可用，對于單個分區(qū)來說，它是非常短暫的，但是如果集群中的某個broker節(jié)點宕機，那么就會有大量的分區(qū)需要進行l(wèi)eader角色切換，這個切換的過程中會消耗一筆可觀的時間。

分區(qū)數越多，也會讓kafka的正常啟動和關閉的耗時變得越長，與此同時，主題的分區(qū)數越多，不僅會增加日志清理的耗時，而且在被刪除的過程中也會耗費更多的時間，對舊版的kafka而言，分區(qū)數越多，也會增加他們的開銷，不過這個問題在新版的生產者和消費者的客戶端已經得到解決了。

如果我們的kafka集群數量比較少的話(小幾十臺)，假設我們有3臺broker節(jié)點，我們可以設定分區(qū)數為3，6，9。當然，最好的辦法還是結合我們的壓測去判斷，盡量選擇合適的kafka分區(qū)數。

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論