最近遇到一個(gè)kafka方面的問題，大致就是由于consumer處理業(yè)務(wù)超時(shí)，導(dǎo)致無法正常提交Offset，進(jìn)而導(dǎo)致無法消費(fèi)新消息的問題。下面我想從以下幾個(gè)方面對(duì)此次故障排查進(jìn)行復(fù)盤分析：業(yè)務(wù)背景、問題描述、排查思路、經(jīng)驗(yàn)教訓(xùn)。

創(chuàng)新互聯(lián)公司2013年至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元南澗做網(wǎng)站,已為上家服務(wù),為南澗各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

一、業(yè)務(wù)背景

先簡單描述一下業(yè)務(wù)背景吧。我們有個(gè)業(yè)務(wù)需要嚴(yán)格按順序消費(fèi)Topic消息，所以針對(duì)該topic設(shè)置了唯一的partition，以及唯一的副本。當(dāng)同一個(gè)消費(fèi)組的多個(gè)consumer啟動(dòng)時(shí)，只會(huì)有一個(gè)consumer訂閱到該Topic，進(jìn)行消費(fèi)，保證同一個(gè)消費(fèi)組內(nèi)的消費(fèi)順序。
注：消費(fèi)組的groupId名稱為“smart-building-consumer-group”，訂閱的Topic名稱為“gate_contact_modify”。

二、問題描述

有一天我們突然收到一個(gè)問題反饋：producer側(cè)的業(yè)務(wù)產(chǎn)生消息后，consumer側(cè)并沒有得到預(yù)期的結(jié)果。經(jīng)過排查，排除了業(yè)務(wù)邏輯出現(xiàn)問題的可能性，我們判斷最有可能是因?yàn)閗afka消息沒有被消費(fèi)到。為了印證這個(gè)猜測，我們查看了consumer消費(fèi)日志，發(fā)現(xiàn)日志中存在這樣幾處問題：
（1）日志偶爾會(huì)打印出一條Kafka的警告日志，內(nèi)容為：
org.springframework.kafka.KafkaListenerEndpointContainer#2-0-C-1 org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.maybeAutoCommitOffsetsSync:648 - Auto-commit of offsets {gate_contact_modify-0=OffsetAndMetadata{offset=2801, metadata=''}} failed for group smart-building-consumer-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.
（2）接著進(jìn)行了一次rebalance；
（3）consumer側(cè)輸出了Topic消費(fèi)者的業(yè)務(wù)日志，表明正常獲取到了Topic消息。
接著我們查看kafka 消費(fèi)組中該Topic對(duì)應(yīng)的Offset的變化情況，發(fā)現(xiàn)Offset一直沒有變化。

三、排查思路

日志中的異常信息很明確的告知我們，topic消息消費(fèi)完成后，由于group發(fā)生了一次rebalance，導(dǎo)致Commit沒有被提交，這表明兩次poll消息的間隔時(shí)間超過了max.poll.interval.ms定義的大間隔，這也意味著一次poll后處理消息的過程超時(shí)了，正是由于poll間隔時(shí)間超時(shí)，導(dǎo)致了一次rebalance。同時(shí)建議我們要么增加間隔時(shí)間，要么減少每次拉取的大消息數(shù)。
另外，由于Commit沒有被提交，導(dǎo)致OffSet值沒有變化，那么每次拉取到的消息都是同一批重復(fù)消息。具體的異常流程如下圖：

根據(jù)上述信息，我們進(jìn)一步檢查了consumer的max.poll.records配置、max.poll.interval.ms配置，并統(tǒng)計(jì)了每條Topic消息的處理耗時(shí)，發(fā)現(xiàn)max.poll.records使用了默認(rèn)配置值500，max.poll.interval.ms使用了默認(rèn)配置值為300s，而每條Topic消息的處理耗時(shí)為10S。這進(jìn)一步證實(shí)了我們的推論：
由于每次拉取的消息數(shù)太多，而每條消息處理時(shí)間又較長，導(dǎo)致每次消息處理時(shí)間超過了拉取時(shí)間間隔，從而使得group進(jìn)行了一次rebalance，導(dǎo)致commit失敗，并最終導(dǎo)致下次拉取重復(fù)的消息、繼續(xù)處理超時(shí)，進(jìn)入一個(gè)死循環(huán)狀態(tài)。
知道問題根源后，我們結(jié)合業(yè)務(wù)特點(diǎn)，更改了max.poll.records=1，每次僅拉取一條消息進(jìn)行處理，最終解決了這個(gè)問題。

四、經(jīng)驗(yàn)教訓(xùn)

這次故障排查，使我們對(duì)Kafka消息poll機(jī)制、rebalance和commit之間的相互影響等有了更深的理解。
（1）kafka每次poll可以指定批量消息數(shù)，以提高消費(fèi)效率，但批量的大小要結(jié)合poll間隔超時(shí)時(shí)間和每條消息的處理時(shí)間進(jìn)行權(quán)衡；
（2）一旦兩次poll的間隔時(shí)間超過閾值，group會(huì)認(rèn)為當(dāng)前consumer可能存在故障點(diǎn)，會(huì)觸發(fā)一次rebalance，重新分配Topic的partition；
（3）如果在commit之前進(jìn)行了一次rebalance，那么本次commit將會(huì)失敗，下次poll會(huì)拉取到舊的數(shù)據(jù)（重復(fù)消費(fèi)），因此要保證好消息處理的冪等性；

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

新聞標(biāo)題：kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常-創(chuàng)新互聯(lián)
URL地址：http://weahome.cn/article/cdccdp.html