背景

• 生產(chǎn)環(huán)境采用默認(rèn)5個分區(qū)的設(shè)置
• kafka已經(jīng)經(jīng)過一層封裝, 實現(xiàn)了自動增減consumer的邏輯

問題

• JVM進(jìn)程kill -15 無法自動退出, 需要-9殺掉, 導(dǎo)致連接層的Session數(shù)據(jù)不一致
• consumer中有一堆的無效consumer, 專門做探測用
• __offset_commit topic增長飛快

解決方案

通過網(wǎng)上查了好多別人的資料, 在kafka的topic的partition的設(shè)置和consumer的管理上, 沒有提到過, 可能大家已經(jīng)使用了我找到的方案.

去除自動探測consumer分配的邏輯

首先說下探測的邏輯:

• 監(jiān)聽partition分配的事件,
• 在分配事件觸發(fā)后, 獲取分配的分區(qū)數(shù)
• 如果比當(dāng)前機(jī)器里面的consumer多, 增加consumer, 反之減少

在分布式系統(tǒng)中, 也可以工作的不錯, 最終保證consumer數(shù)量和partition保持一致.問題有兩個:

1. 從數(shù)量不一致到數(shù)量一致, 需要增減多次, 可能會導(dǎo)致commit的offset出現(xiàn)問題, 導(dǎo)致重復(fù)消費(fèi)或者漏掉消息;
2. 需要單獨(dú)的consumer做探測, 和普通的消費(fèi)事件的分離開,在查看consumer列表時, 會看到一批探測的consumer

增加partition數(shù)量

不能自動管理consumer數(shù)量, 就換一個方案, 管理partition.

• 增加partition數(shù)量, 使之遠(yuǎn)大于消費(fèi)的jvm進(jìn)程,
• 每個進(jìn)程內(nèi)有固定個數(shù)的consumer

如partition數(shù)量為36, 每個進(jìn)程內(nèi)固定3個consumer,隨著機(jī)器的增加, 分配的情況如下:

這種配置下, 大于12個進(jìn)程的時候,就會存在有個機(jī)器上的consumer閑置的情況. 可以調(diào)整每個進(jìn)程consumer數(shù)量和partition的數(shù)量.

其他

1. consumer.poll(10000), 這個參數(shù)是拉取記錄時, 沒有記錄的等待時間, 我覺得不必設(shè)置太短, 比如100(ms), 可以適當(dāng)增加
2. kafka-manager是我用過最好的管理監(jiān)控工具