今天在服務日志中觀察數據的消費情況時，發(fā)現(xiàn)了一個如下的警告，而且每隔幾秒就會出現(xiàn)一次，雖然只是個警告，

?

Auto offset commit failed for group order_group:Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member.This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms,which typically implies that the poll loop is spending too much time message processing.You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.

但是看到auto offset commit failed時我就不淡定了，不難看出是自動提交offset失敗了，我們都知道，kafka的數據更新消費都是通過在zookeeper中標記一個偏移量（offset）來記錄每個分區(qū)的消費位置，所以一旦offset更新失敗，不難想象肯定會出現(xiàn)重復消費數據的問題！

通過以上信息分析大概意思是：kafka消費者在處理消息時，在指定時間內（session.time.out）沒有處理完，consumer coordinator會由于沒有接受到心跳而掛掉，導致自動提交offset失敗，因此就會像日志中所說的發(fā)生rebalanced（重平衡即重新分配partition給客戶端），而之前提交的offset已經失敗了，所以重新分配的客戶端又會消費之前的數據，接著consumer重新消費，又出現(xiàn)了消費超時，無限循環(huán)下去。

解決方法：

將enable.auto.commit設置成false，即不采用自動提交方式；

?

由于使用了spring-kafka，禁止kafka-client自動提交offset，因為就是之前的自動提交失敗，導致offset永遠沒更新，從而轉向使用spring-kafka的offset提交機制。

1）如果auto.commit關掉的話，spring-kafka會啟動一個invoker，這個invoker的目的就是啟動一個線程去消費數據，他消費的數據不是直接從kafka里面直接取的，那么他消費的數據從哪里來呢？他是從一個spring-kafka自己創(chuàng)建的阻塞隊列里面取的。

2）然后會進入一個循環(huán)，從源代碼中可以看到如果auto.commit被關掉的話， 他會先把之前處理過的數據先進行提交offset，然后再去從kafka里面取數據。

3）然后把取到的數據丟給上面提到的阻塞列隊，由上面創(chuàng)建的線程去消費，并且如果阻塞隊列滿了導致取到的數據塞不進去的話，spring-kafka會調用kafka的pause方法，則consumer會停止從kafka里面繼續(xù)再拿數據。

4）接著spring-kafka還會處理一些異常的情況，比如失敗之后是不是需要commit offset這樣的邏輯

?

參考：https://www.jianshu.com/p/9b444d4b32c0

總結

以上是生活随笔為你收集整理的kafka自动提交offset失败：Auto offset commit failed的全部內容，希望文章能夠幫你解決所遇到的問題。

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