kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常-創(chuàng)新互聯(lián)

最近遇到一個(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)公司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ù)背景

先簡(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”。
kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常

二、問題描述

有一天我們突然收到一個(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一直沒有變化。
kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常

三、排查思路

日志中的異常信息很明確的告知我們,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ù)消息。具體的異常流程如下圖:

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

根據(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)),因此要保證好消息處理的冪等性;

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

本文標(biāo)題:kafka故障排查-consumer處理超時(shí)導(dǎo)致的異常-創(chuàng)新互聯(lián)
網(wǎng)站鏈接:http://m.kartarina.com/article18/cdccdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供域名注冊(cè)服務(wù)器托管網(wǎng)站策劃企業(yè)建站定制開發(fā)ChatGPT

廣告

聲明:本網(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)

小程序開發(fā)
主站蜘蛛池模板: 国产av无码久久精品| 2020无码专区人妻系列日韩| 亚洲AV永久无码精品成人| 亚洲中文字幕无码一久久区| 亚洲动漫精品无码av天堂| 亚洲最大中文字幕无码网站| 无码精品人妻一区二区三区免费| 亚洲中文字幕无码一区| 日本无码一区二区三区白峰美| 亚洲一区二区三区无码影院| 99久久无码一区人妻a黑| 狠狠爱无码一区二区三区| 久久综合精品国产二区无码| 亚洲精品97久久中文字幕无码| 亚洲av无码电影网| 国产精品99精品无码视亚| 国产裸模视频免费区无码| 亚洲一区二区三区无码国产| 国产午夜精华无码网站| 国产精品va无码二区| 亚洲日韩国产AV无码无码精品| 午夜亚洲AV日韩AV无码大全| 亚洲AV无码乱码在线观看牲色| 精品无码综合一区二区三区 | 国精无码欧精品亚洲一区| 免费无码看av的网站| 亚洲成a人无码亚洲成av无码| 日韩亚洲AV无码一区二区不卡| 高潮潮喷奶水飞溅视频无码| 夜夜精品无码一区二区三区| 在线看片无码永久免费aⅴ| 精品人妻无码一区二区色欲产成人 | 天堂无码在线观看| 黄色成人网站免费无码av| 亚洲人片在线观看天堂无码| 精品无码AV无码免费专区| 人妻精品久久无码专区精东影业 | 人妻无码αv中文字幕久久琪琪布| 国产日产欧洲无码视频无遮挡| 国产高清无码视频| 亚洲中文字幕无码中文字在线|