? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Kafka高性能相關(guān)

1?高性能原因

1.1 高效使用磁盤

（1）順序?qū)懘疟P，順序?qū)懘疟P性能高于隨機(jī)寫內(nèi)存

（2）Append Only 數(shù)據(jù)不更新，無記錄級(jí)的數(shù)據(jù)刪除（只會(huì)整個(gè)segment刪除）

（3）充分利用Page Cache，I/O Scheduler將連續(xù)的小塊寫組裝成大塊的物理寫從而提高性能，將一些寫操作重新按順序排好，從而減少磁盤頭的移動(dòng)時(shí)間

（4）充分利用所有空閑內(nèi)存(非JVM內(nèi)存)，應(yīng)用層cache也會(huì)有對(duì)應(yīng)的page cache與之對(duì)應(yīng)，直接使用page cache可增大可用cache，如使用heap內(nèi)的cache，會(huì)增加GC負(fù)擔(dān)

（5）讀操作可直接在page cache內(nèi)進(jìn)行。如果進(jìn)程重啟，JVM內(nèi)的cache會(huì)失效，但page cache仍然可用

（6）可通過參數(shù)強(qiáng)制flush

（7）支持多Directory

1.2?零拷貝

傳統(tǒng)模式下數(shù)據(jù)從文件傳輸?shù)骄W(wǎng)絡(luò)需要4次數(shù)據(jù)拷貝，4次上下文切換和2次系統(tǒng)調(diào)用。通過NIO的transferTo/transferFrom調(diào)用操作系統(tǒng)的sendfile實(shí)現(xiàn)零拷貝。總共2次內(nèi)核數(shù)據(jù)拷貝，2次上下文切換和1次系統(tǒng)調(diào)用，消除了CPU數(shù)據(jù)拷貝

1.3?批處理和壓縮

（1）Producer和Consumer均支持批量處理數(shù)據(jù)，從而減少了網(wǎng)絡(luò)傳輸?shù)拈_銷

（2）Producer可將數(shù)據(jù)壓縮后發(fā)送給broker，從而減少網(wǎng)絡(luò)傳輸代價(jià)。目前支持Snappy，Gzip和LZ4壓縮

1.4?Partitio

（1）通過Partition實(shí)現(xiàn)了并行處理和水平擴(kuò)展

（2）Partition是Kafka（包括kafka Stream）并行處理的最小單位

（3）不同Partition可處于不同的Broker，充分利用多機(jī)資源

（4）同一Broker上的不同Partition可置于不同的Directory，如果節(jié)點(diǎn)上有多個(gè)Disk Drive，可將不同的Drive對(duì)應(yīng)的Directory，從而是Kafka充分利用Disk Drive的磁盤優(yōu)勢(shì)

1.5?ISR

（1）ISR實(shí)現(xiàn)了可用性和一致性的動(dòng)態(tài)平衡

（2）ISR可容忍更多的節(jié)點(diǎn)失敗。Majority Quorum如果要容忍f個(gè)節(jié)點(diǎn)失敗，至少需要2f+1個(gè)節(jié)點(diǎn) ISR如果要容忍f個(gè)節(jié)點(diǎn)失敗，至少需要f+1個(gè)節(jié)點(diǎn)

（3）如何處理Replica Crach，Leader crash后，ISR中的任何replica皆可競(jìng)選稱為L(zhǎng)eader，如果所有replica都crash，可選擇讓第一個(gè)recover的replica或者第一個(gè)在ISR中的replica稱為leader

2?kafka性能影響因子

（1）producer ：producer和吞吐量成正比

（2）consumer：consumer數(shù)據(jù)量在沒有達(dá)到partition個(gè)數(shù)之前，和消費(fèi)的吞吐量成正比。

（3）partition：分區(qū)格式和生成的吞吐量，在一定范圍內(nèi)，先增長(zhǎng)，當(dāng)達(dá)到某一個(gè)值之后區(qū)域穩(wěn)定，在上下浮動(dòng)。

（4）message-size：隨著message size的增大，生產(chǎn)者對(duì)應(yīng)的每秒生成的記錄數(shù)在成下降趨勢(shì)，區(qū)里的數(shù)據(jù)體積成上升趨勢(shì)。

（5）replication：副本越大，自然需要同步數(shù)據(jù)的量就越多，自然kafka的生成的吞吐量就越低。

2.1?kafka腳本查看kafka集群性能

（1）kafka-producer-perf-test.sh：查看kafka生產(chǎn)者的性能。

bin/kafka-producer-perf-test.sh --topic perftest \ --num-records 100000 \ #測(cè)試生成多少條記錄 --throughput 10000 \ #生產(chǎn)這的吞吐量，約等于messages/sec --record-size 10 \ #每條消息的大小 --producer.config config/producer.properties

（2）kafka-consumer-perf-test.sh：查看kafka消費(fèi)者的性能。

bin/kafka-consumer-perf-test.sh --topic perftest \ --broker-list bigdata01:9092,bigdata02:9092,bigdata03:9092 \ --messages 100000 #總共要讀取多少條記錄

結(jié)果參數(shù)

start.time=2019-08-06 02:31:23:738 --->開始時(shí)間 end.time=2019-08-06 02:31:24:735 --->結(jié)束時(shí)間 data.consumed.in.MB=0.9534 --->總共消費(fèi)的數(shù)據(jù)體積 MB.sec=0.9562 --->每秒鐘消費(fèi)數(shù)據(jù)體積 data.consumed.in.nMsg=100000 --->總共消費(fèi)的數(shù)據(jù)記錄數(shù) nMsg.sec=100300.9027 --->每秒鐘消費(fèi)記錄數(shù) rebalance.time.ms=47 --->進(jìn)行rebalance的時(shí)間 fetch.time.ms=950 --->抓取這10w條數(shù)據(jù)總共花費(fèi)多長(zhǎng)時(shí)間 fetch.MB.sec=1.0035 --->每秒鐘抓取數(shù)據(jù)體積 fetch.nMsg.sec=105263.1579 --->每秒鐘抓取數(shù)據(jù)記錄數(shù)

?

總結(jié)

以上是生活随笔為你收集整理的Kafka高性能相关的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。