kafka核心概念

Broker: 一個(gè)kafka服務(wù)端節(jié)點(diǎn)

cluseter: 集群，由多個(gè)Broker組合的集合

message:消息，也叫Record，kafka中信息傳遞的載體，對于kafka

Producer:生產(chǎn)者，向kafka發(fā)送消息的應(yīng)用

Consumer:消費(fèi)者，從kafka接收消息的應(yīng)用

Consumer Group:消費(fèi)者組，一組具有相同Group ID的Consumer,當(dāng)一個(gè)topic被同一個(gè)group的多個(gè)consumer消費(fèi)的時(shí)候，每條消息都只會(huì)投遞到一個(gè)Consumer,實(shí)現(xiàn)消費(fèi)的負(fù)載均衡，通過group，可以確保一個(gè)topic消息被并行消費(fèi)，調(diào)高吞吐量

Topic:消費(fèi)的主題，用于分類消息，在每個(gè)Broker上都可以創(chuàng)建多個(gè)topic

Replica:副本，每一個(gè)分區(qū)都有多個(gè)副本，當(dāng)主分區(qū)故障的時(shí)候會(huì)選擇一個(gè)備分區(qū)，成為leader，kafka中默認(rèn)副本最大數(shù)量是10，副本的數(shù)量不能大于broker的數(shù)量

Partition：分區(qū)，一個(gè)有序不變的消息列隊(duì)，用于存儲(chǔ)消息，一個(gè)topic由一個(gè)或者多個(gè)分區(qū)組成，每個(gè)分區(qū)中的消息存儲(chǔ)于一個(gè)或者多個(gè)broker上，在一個(gè)分區(qū)中消息的順序就是producer發(fā)送消息的順序。

offset: 分區(qū)中每條消息位置的信息，是一個(gè)單調(diào)遞增且不變的值。

消費(fèi)位點(diǎn)：分區(qū)被當(dāng)前consumer消費(fèi)了消息的最大位點(diǎn)

堆積量：當(dāng)前分區(qū)下消息堆積的總量，即最大位點(diǎn)減去消費(fèi)位點(diǎn)的值。堆積是一個(gè)關(guān)鍵指標(biāo)，如果發(fā)現(xiàn)堆積量較大，則comsumer可能出現(xiàn)了阻塞，或者消費(fèi)速度更不上生產(chǎn)的速度，此時(shí)需要分析consumer的運(yùn)行狀況，盡力提升消費(fèi)速度?？梢郧宄械亩逊e消息，從最大位點(diǎn)開始消費(fèi)，或者按照時(shí)間點(diǎn)進(jìn)行點(diǎn)重置。

rebalance:重平衡，消費(fèi)組內(nèi)某個(gè)消費(fèi)者實(shí)例掛掉后，其他消費(fèi)者實(shí)例自動(dòng)重新分配訂閱的主題分區(qū)的過程，它是kafka消費(fèi)者端實(shí)現(xiàn)高可用的重要手段。

zookeeper: kafka集群依賴zookeeper來保存集群的元信息，以保證系統(tǒng)的可用性。

kafka版本

0.1x 早期孵化版本

1.x 優(yōu)化streams API,增強(qiáng)可觀測性和可調(diào)試性，支持java9,優(yōu)化SASL

2.X 性能提升，增強(qiáng)acl支持

3.x 去掉zookeeper依賴，支持java17,不再支持java8,不再支持v0和v1消息，性能大幅提升

推薦使用2,x和3.x版本

Kafka Metric監(jiān)控

Producer指標(biāo)

生產(chǎn)者將消息推送到Broker Topic的應(yīng)用，如果生產(chǎn)者失敗，消費(fèi)者將得不到新的消息。

Broker指標(biāo)

因?yàn)樗械南⒈仨毻ㄟ^kafka broker才能被使用，所以對集群中Broker的監(jiān)控是最核心。

Consumer指標(biāo)

consumer是kafka消息終點(diǎn)

zookeeper指標(biāo)

zookeeper是kafka的一個(gè)關(guān)鍵組件（v3.0）之前，zookeeper停機(jī)將使kafka停止運(yùn)行。

kafka典型問題和排查

topic消息發(fā)送慢，并發(fā)性能低

某個(gè)或者某幾個(gè)Topic的消息并發(fā)發(fā)送性能低，在指標(biāo)上體現(xiàn)為producer的平均請求延遲大，平均生產(chǎn)吞吐量小

通常消息發(fā)送慢如下幾種典型原因：

網(wǎng)絡(luò)帶寬不足，導(dǎo)致IO等待

消息未壓縮，導(dǎo)致網(wǎng)絡(luò)流量超負(fù)荷

消息未批量發(fā)送，或者批量閾值配置不恰當(dāng)，導(dǎo)致發(fā)送速率慢

topic分區(qū)數(shù)量不足，導(dǎo)致broker接收消息積壓

broker磁盤性能低，導(dǎo)致磁盤同步慢

broker分區(qū)總量過多，導(dǎo)致碎片化，磁盤讀寫過載‘

排查

確認(rèn)producer的平均IO等待時(shí)間指標(biāo)是否符合預(yù)期或者陡增，以便producer到broker之間的網(wǎng)絡(luò)帶寬是否滿足業(yè)務(wù)的流量要求

確認(rèn)producer的平均壓縮率指標(biāo)，確保要壓縮率符合預(yù)期

確認(rèn)producer的平均請求包大小是否過小，如果是的化，需要考慮增大producer發(fā)送消息的batchsize,同時(shí)調(diào)整linger.ms的閾值

查看topic分區(qū)數(shù)量，分區(qū)較小的時(shí)候，考慮增加分區(qū)數(shù)，以水平擴(kuò)展broker的并發(fā)接收消息容量

確認(rèn)borker磁盤IO使用率是否在安全范圍之內(nèi)，如果使用率已經(jīng)較高，則考慮垂直或者水平擴(kuò)容Broker，同時(shí)考慮增加topic分區(qū)數(shù)，提升topic并接收消息能力

查看集群的總分區(qū)數(shù)和單個(gè)boker的分區(qū)數(shù)量，確保在規(guī)劃的容量范圍之內(nèi)。

topic消息堆積

某個(gè)或者幾個(gè)topic的消息堆積持續(xù)增加，在指標(biāo)上直接體現(xiàn)為group消費(fèi)延遲數(shù)量持續(xù)增加

常見的消息堆積有如下幾種原因：

producer生產(chǎn)消息流量增大

consumer由于業(yè)務(wù)變化導(dǎo)致消費(fèi)延遲增加

consumer數(shù)量不足

consumer數(shù)量頻繁變化，導(dǎo)致group不斷做再平衡rebalance

broker未收到consumer消息確認(rèn)消息

排查

確認(rèn)producer的消息生產(chǎn)量指標(biāo)是否明顯增加

確認(rèn)consumer的消息流量指標(biāo)是否明顯下降

通過kafka broker提供的命令，確認(rèn)topic對應(yīng)consumer數(shù)量與實(shí)際的consumer數(shù)量是否一致，如果不一致，說明某些consumer未正確連接到broker，需要排查consumer是否正常運(yùn)行

觀察consumer的數(shù)量是否頻繁變化而觸發(fā)犯法再平衡

由于網(wǎng)絡(luò)或者其他原因，可能導(dǎo)致consumer與boker之間的連接不穩(wěn)定，consumer能持續(xù)消費(fèi)消息，但是broker卻始終認(rèn)為消息未確認(rèn)，導(dǎo)致消費(fèi)位點(diǎn)不變，此時(shí)可能需要確認(rèn)consumer與broker之間的網(wǎng)絡(luò)穩(wěn)定性，甚至重啟consumer

審核編輯：黃飛