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

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

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

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

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

二、問題描述

有一天我們突然收到一個問題反饋：producer側(cè)的業(yè)務(wù)產(chǎn)生消息后，consumer側(cè)并沒有得到預(yù)期的結(jié)果。經(jīng)過排查，排除了業(yè)務(wù)邏輯出現(xiàn)問題的可能性，我們判斷最有可能是因?yàn)閗afka消息沒有被消費(fèi)到。為了印證這個猜測，我們查看了consumer消費(fèi)日志，發(fā)現(xiàn)日志中存在這樣幾處問題：
（1）日志偶爾會打印出一條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對應(yīng)的Offset的變化情況，發(fā)現(xiàn)Offset一直沒有變化。

三、排查思路

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

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

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

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

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

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

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

廣告

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