kafka核心概念

Broker: 一個kafka服務端節點

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

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

Producer:生產者，向kafka發送消息的應用

Consumer:消費者，從kafka接收消息的應用

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

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

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

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

offset: 分區中每條消息位置的信息，是一個單調遞增且不變的值。

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

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

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

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

kafka版本

0.1x 早期孵化版本

1.x 優化streams API,增強可觀測性和可調試性，支持java9,優化SASL

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

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

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

Kafka Metric監控

Producer指標

生產者將消息推送到Broker Topic的應用，如果生產者失敗，消費者將得不到新的消息。

Broker指標

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

Consumer指標

consumer是kafka消息終點

zookeeper指標

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

kafka典型問題和排查

topic消息發送慢，并發性能低

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

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

網絡帶寬不足，導致IO等待

消息未壓縮，導致網絡流量超負荷

消息未批量發送，或者批量閾值配置不恰當，導致發送速率慢

topic分區數量不足，導致broker接收消息積壓

broker磁盤性能低，導致磁盤同步慢

broker分區總量過多，導致碎片化，磁盤讀寫過載‘

排查

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

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

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

查看topic分區數量，分區較小的時候，考慮增加分區數，以水平擴展broker的并發接收消息容量

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

查看集群的總分區數和單個boker的分區數量，確保在規劃的容量范圍之內。

topic消息堆積

某個或者幾個topic的消息堆積持續增加，在指標上直接體現為group消費延遲數量持續增加

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

producer生產消息流量增大

consumer由于業務變化導致消費延遲增加

consumer數量不足

consumer數量頻繁變化，導致group不斷做再平衡rebalance

broker未收到consumer消息確認消息

排查

確認producer的消息生產量指標是否明顯增加

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

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

觀察consumer的數量是否頻繁變化而觸發犯法再平衡

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

審核編輯：黃飛