欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

使用kafka如何選擇分區(qū)數(shù)及kafka性能測(cè)試

 更新時(shí)間:2021年08月09日 10:50:39   作者:引領(lǐng)時(shí)尚S  
這篇文章主要介紹了使用kafka如何選擇分區(qū)數(shù)及kafka性能測(cè)試,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

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

1、簡(jiǎn)言

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

2、性能測(cè)試工具

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

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

分別創(chuàng)建三個(gè)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)者性能測(cè)試工具來(lái)測(cè)試:

  • num-records 100萬(wàn)條消息
  • record-size 20480 每條消息是20K
  • throughput 用來(lái)進(jìn)行限流控制 當(dāng)設(shè)置為0的時(shí)候不限流(盡量還是限流,否則很有可能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個(gè)分區(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個(gè)分區(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個(gè)分區(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á)一定程度的時(shí)候,我們不一定要增大分區(qū)數(shù),因?yàn)榉謪^(qū)數(shù)過(guò)大,不會(huì)提升吞吐量(可以測(cè)試一下1000個(gè)分區(qū)甚至10000個(gè)分區(qū),吞吐量會(huì)下降,這里就不一一演示),且會(huì)造成錯(cuò)誤(后面解釋)

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

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

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

start.time(開(kāi)始時(shí)間), end.time(結(jié)束時(shí)間), data.consumed.in.MB(消費(fèi)的消息總量,單位為M), MB.sec(消費(fèi)吞吐量(MB/S)), data.consumed.in.nMsg(消費(fèi)的消息總數(shù)), nMsg.sec(按消息個(gè)數(shù)計(jì)算的吞吐量), rebalance.time.ms(再平衡的時(shí)間,單位為ms), fetch.time.ms(拉取消息的持續(xù)時(shí)間,單位為ms), fetch.MB.sec(每秒拉取消息的字節(jié)大小,MB/S), fetch.nMsg.sec(每秒拉取消息的個(gè)數(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ù)測(cè)試的結(jié)果,我們也可以多測(cè)不同分區(qū)的幾組數(shù)據(jù),獲得一個(gè)合適的kafka分區(qū)數(shù)據(jù),來(lái)保證我們集群的穩(wěn)定運(yùn)行。

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

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

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

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

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

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

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

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

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

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

java.io.IOException: Too many open files

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

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

image-20190320202019338

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

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

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

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

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

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

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

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

相關(guān)文章

  • 關(guān)于idea中ssm框架的編碼問(wèn)題分析

    關(guān)于idea中ssm框架的編碼問(wèn)題分析

    在實(shí)際開(kāi)發(fā)中需要將操作系統(tǒng)編碼、文件編碼、頁(yè)面編碼以及tomcat服務(wù)器編碼保持一致,而tomcat在默認(rèn)情況下是使用UTF-8,這就使得其打印的日志文件出現(xiàn)中文亂碼,因此在一般情況下,只需要將tomcat服務(wù)器的編碼改為GBK即可
    2021-06-06
  • Java實(shí)現(xiàn)利用圖片或視頻生成GIF并發(fā)送微信

    Java實(shí)現(xiàn)利用圖片或視頻生成GIF并發(fā)送微信

    這篇文章主要為大家詳細(xì)介紹了Java語(yǔ)言如何利用圖片或視頻實(shí)現(xiàn)生成GIF并發(fā)送微信的功能,文中的示例代碼講解詳細(xì),感興趣的小伙伴可以嘗試一下
    2022-11-11
  • Spring?Boot?打包如何將依賴(lài)全部打進(jìn)去

    Spring?Boot?打包如何將依賴(lài)全部打進(jìn)去

    這篇文章主要介紹了Spring?Boot?打包如何將依賴(lài)全部打進(jìn)去,在pom.xml中引入插件,需要在項(xiàng)目的pom.xml文件中,添加?Maven?插件??spring-boot-maven-plugin,本文結(jié)合實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2023-09-09
  • SpringBoot如何優(yōu)雅的處理全局異常

    SpringBoot如何優(yōu)雅的處理全局異常

    這篇文章主要給大家介紹了關(guān)于SpringBoot如何優(yōu)雅的處理全局異常的相關(guān)資料,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用SpringBoot具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2019-05-05
  • Spring啟動(dòng)時(shí)實(shí)現(xiàn)初始化的幾種方案

    Spring啟動(dòng)時(shí)實(shí)現(xiàn)初始化的幾種方案

    這篇文章主要介紹了Spring啟動(dòng)時(shí)實(shí)現(xiàn)初始化的幾種方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2024-06-06
  • Spring3.1.1+MyBatis3.1.1的增、刪、查、改以及分頁(yè)和事務(wù)管理

    Spring3.1.1+MyBatis3.1.1的增、刪、查、改以及分頁(yè)和事務(wù)管理

    這篇文章主要介紹了Spring3.1.1+MyBatis3.1.1的增、刪、查、改以及分頁(yè)和事務(wù)管理的相關(guān)資料,需要的朋友可以參考下
    2016-01-01
  • java selenium操作彈出對(duì)話(huà)框示例講解

    java selenium操作彈出對(duì)話(huà)框示例講解

    本文主要介紹java selenium操作彈出對(duì)話(huà)框,這里給大家整理了相關(guān)資料,并附示例代碼和實(shí)現(xiàn)效果圖,有興趣的小伙伴可以參考下
    2016-08-08
  • @Slf4j?如何實(shí)現(xiàn)日志輸入到外部文件

    @Slf4j?如何實(shí)現(xiàn)日志輸入到外部文件

    這篇文章主要介紹了@Slf4j?如何實(shí)現(xiàn)日志輸入到外部文件,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2021-12-12
  • SpringMVC自定義消息轉(zhuǎn)換器的使用其實(shí)很簡(jiǎn)單

    SpringMVC自定義消息轉(zhuǎn)換器的使用其實(shí)很簡(jiǎn)單

    這篇文章主要介紹了SpringMVC自定義消息轉(zhuǎn)換器的使用方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2024-07-07
  • 基于Idea+Jconsole實(shí)現(xiàn)線程監(jiān)控步驟

    基于Idea+Jconsole實(shí)現(xiàn)線程監(jiān)控步驟

    這篇文章主要介紹了基于Idea+Jconsole實(shí)現(xiàn)線程監(jiān)控功能,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2020-04-04

最新評(píng)論