kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常

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

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比海州網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式海州網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋海州地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。

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

先簡(jiǎn)單描述一下業(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)過(guò)排查，排除了業(yè)務(wù)邏輯出現(xiàn)問題的可能性，我們判斷最有可能是因?yàn)閗afka消息沒有被消費(fèi)到。為了印證這個(gè)猜測(cè)，我們查看了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í)間超過(guò)了max.poll.interval.ms定義的最大間隔，這也意味著一次poll后處理消息的過(guò)程超時(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í)間又較長(zhǎng)，導(dǎo)致每次消息處理時(shí)間超過(guò)了拉取時(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í)間超過(guò)閾值，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)），因此要保證好消息處理的冪等性；

本文名稱：kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常
URL地址：http://muchs.cn/article40/ipigho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、云服務(wù)器、移動(dòng)網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)