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

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

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

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的文件描述符:

image-20190320202019338

當我們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ū)數。

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

相關文章

  • 關于idea中ssm框架的編碼問題分析

    關于idea中ssm框架的編碼問題分析

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

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

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

    Spring?Boot?打包如何將依賴全部打進去

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

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

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

    Spring啟動時實現初始化的幾種方案

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

    Spring3.1.1+MyBatis3.1.1的增、刪、查、改以及分頁和事務管理

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

    java selenium操作彈出對話框示例講解

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

    @Slf4j?如何實現日志輸入到外部文件

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

    SpringMVC自定義消息轉換器的使用其實很簡單

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

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

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

最新評論