kafka核心概念

Broker: 一個kafka服務(wù)端節(jié)點

cluseter: 集群，由多個Broker組合的集合

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

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

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

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

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

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

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

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

消費位點：分區(qū)被當前consumer消費了消息的最大位點

堆積量：當前分區(qū)下消息堆積的總量，即最大位點減去消費位點的值。堆積是一個關(guān)鍵指標，如果發(fā)現(xiàn)堆積量較大，則comsumer可能出現(xiàn)了阻塞，或者消費速度更不上生產(chǎn)的速度，此時需要分析consumer的運行狀況，盡力提升消費速度。可以清除所有的堆積消息，從最大位點開始消費，或者按照時間點進行點重置。

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

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

kafka版本

0.1x 早期孵化版本

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

2.X 性能提升，增強acl支持

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

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

Kafka Metric監(jiān)控

Producer指標

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

Broker指標

因為所有的消息必須通過kafka broker才能被使用，所以對集群中Broker的監(jiān)控是最核心。

Consumer指標

consumer是kafka消息終點

zookeeper指標

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

kafka典型問題和排查

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

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

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

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

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

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

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

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

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

排查

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

確認producer的平均壓縮率指標，確保要壓縮率符合預(yù)期

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

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

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

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

topic消息堆積

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

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

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

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

consumer數(shù)量不足

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

broker未收到consumer消息確認消息

排查

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

確認consumer的消息流量指標是否明顯下降

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

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

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

審核編輯：黃飛