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

1、簡言

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

2、性能測試工具

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

① 生產(chǎn)者性能測試

分別創(chuàng)建三個topic，副本數(shù)設(shè)置為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

采用生產(chǎn)者性能測試工具來測試：

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

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

我們看實(shí)際的效果

15個分區(qū)結(jié)果

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ū)數(shù)并不是越多越好，在吞吐量到達(dá)一定程度的時候，我們不一定要增大分區(qū)數(shù)，因?yàn)榉謪^(qū)數(shù)過大，不會提升吞吐量（可以測試一下1000個分區(qū)甚至10000個分區(qū)，吞吐量會下降，這里就不一一演示），且會造成錯誤(后面解釋)

② 消費(fèi)者性能測試

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

​ 消費(fèi)者測試結(jié)果，我們知道kafka出來的數(shù)據(jù)單元為message，所以我們的messages就是kafka消費(fèi)的條數(shù)

start.time（開始時間）, end.time（結(jié)束時間）, data.consumed.in.MB（消費(fèi)的消息總量，單位為M）, MB.sec(消費(fèi)吞吐量（MB/S）), data.consumed.in.nMsg（消費(fèi)的消息總數(shù)）, nMsg.sec（按消息個數(shù)計(jì)算的吞吐量）, rebalance.time.ms（再平衡的時間，單位為ms）, fetch.time.ms（拉取消息的持續(xù)時間，單位為ms）, fetch.MB.sec（每秒拉取消息的字節(jié)大小，MB/S）, fetch.nMsg.sec（每秒拉取消息的個數(shù)） 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

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

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

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

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

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

我們可以使用我們生產(chǎn)者與消費(fèi)者測試工具進(jìn)行相應(yīng)的測試。(可以看根據(jù)上面的，多測幾組數(shù)據(jù))

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

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

實(shí)踐，是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

并且，一味的增加分區(qū)數(shù)并不能使我們的吞吐量得到提升，還會因?yàn)槌^系統(tǒng)的默認(rèn)值，引起kafka進(jìn)程崩潰。本人在生產(chǎn)環(huán)境中，將kafka分區(qū)數(shù)設(shè)置的過大，曾導(dǎo)致在實(shí)時流環(huán)境中，kafka進(jìn)程多次崩潰。迫不得已的修改系統(tǒng)參數(shù)。

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

java.io.IOException: Too many open files

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

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

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

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

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

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

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

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

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

以上為個人經(jīng)驗(yàn)，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論