問題描述

??最近線上的一個數據服務(服務B)出現了一個比較詭異的問題 ，該服務消費上游服務(服務A)產生的kafka消息數據，上線后一直運行平穩，最近一周在兩次上線的時候出現了大量數據更新的情況，查看服務日志發現每次都從kafka的起始位置進行消費了，而kafka topic的數據一般是保留最近7天，但是這是不應該發生的，因為監控顯示服務B在重啟前是沒有什么延遲的，更加不可能說是有7天的延遲，而且在kafka的broker上理論上會保留每個consumer-group的信息,一般會有一定的保留時長，在業務B重啟后會接著原來提交的offset點位進行消費。

問題排查

??那為什么會出現這種問題呢，仔細排查服務B的啟動日志，確實在啟動后將offset放到了topic的earlist位置，然后排查kafka topic中的數據，發現有幾天沒有更新了，再往上追溯，原來服務A因為數據平臺的一些故障停止運行了幾天（新上的分布式計算任務，未來得及做全面的監控）。那這又為什么會導致B服務重啟后從頭消費呢。

??直觀感覺上應該是kafka的broker對consumer group的管理機制導致的，因為一直沒有新的數據產生，所以當服務B消費了topic末尾的時候不會再提交新的offset(服務B使用的是手動提交的模式)，只是有維持session 的心跳，這個時候broker端不會更新consumer-group的信息，所以consumer-group的有效時間在超過max.poll.interval.ms之后，server端會將對應的consumer踢除掉，在這個consumer-group里面沒有任何consumer之后，在經歷offsets.retention.minutes之后，kafka-server就會將相關的consumer-group的消費數據清理掉。在這之后，如果服務B對應的consumer進行重啟的話，如果設置的auto_offset_reset=earliest的話就會導致數據消費從頭開始。

回過頭來看線上服務B當時的表現也不是每次都從頭消費，兩次從頭消費都是超過了兩天的上線(因為沒有新的數據進來，所以等于有將近48h沒有進行commit)，仔細查找了一下kafka的相關設置，看到這個

offsets.retention.minutes: 默認值為1440， 是24h,
After a consumer group loses all its consumers (i.e. becomes empty) its offsets will be kept for this retention period before getting discarded.
For standalone consumers (using manual assignment), offsets will be expired after the time of last commit plus this retention period.

解決方案

手動提交的代碼調整，在每次poll下來之后不管是否有數據都進行一次手動的commit操作

在少量重復消費不影響服務的情況下可以嘗試使用自動提交

需要注意的時候，有時候測試環境確實可能出現長時間沒有數據的情況，這個時候也可以在kafka server端增大offsets.retention.minutes的設置。

總結

以上是生活随笔為你收集整理的kafka消息反复从头开始消费问题排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。