2022年10月份接到一個(gè)小功能，對(duì)接kafka將數(shù)據(jù)寫到數(shù)據(jù)庫(kù)，開始的需求就是無(wú)腦批量insert，隨著時(shí)間的推移，業(yè)務(wù)需求有變更，kafka的生產(chǎn)消息頻次越來(lái)越高，到今年7月份為止就每秒會(huì)有幾十條甚至上百條，然后消費(fèi)消息的代碼就報(bào)錯(cuò)：
Caused by: org.apache.kafka.clients.consumer.CommitFailedException: Offset commit cannot be completed since the consumer is not part of an active group for auto partition assignment; it is likely that the consumer was kicked out of the group.
剛開始就在網(wǎng)上查詢相關(guān)信息的解決辦法，有的是讓修改max-poll-records這個(gè)參數(shù)，網(wǎng)上查到的信息是，這個(gè)參數(shù)主要是消費(fèi)者每次獲取數(shù)據(jù)的大小，好像是這么解釋的，我修改完之后，發(fā)現(xiàn)還是報(bào)錯(cuò)，報(bào)同樣的錯(cuò)，因此我就去反查代碼，也沒(méi)有什么問(wèn)題。這個(gè)問(wèn)題持續(xù)了一段時(shí)間，每次都是重啟應(yīng)用來(lái)解決問(wèn)題。
后來(lái)被逼無(wú)奈，只能痛下決心來(lái)解決這個(gè)問(wèn)題，于是我就在網(wǎng)上查詢，出現(xiàn)這個(gè)錯(cuò)誤的原因，最后大概定位到：是因?yàn)橄M(fèi)程序的處理能力太慢。于是我就重新梳理了一下數(shù)據(jù)消費(fèi)成后的后續(xù)業(yè)務(wù)邏輯，發(fā)現(xiàn)有一步批量更新可以不需要，于是就把批量更新的操作去掉了，讓消費(fèi)消息的邏輯又變得簡(jiǎn)單了，后來(lái)就沒(méi)有出現(xiàn)這個(gè)問(wèn)題了。于是總結(jié)了一下，出現(xiàn)這個(gè)問(wèn)題的大數(shù)據(jù)原因可能是因?yàn)槲覀兿M(fèi)者的代碼邏輯牽扯太多或者業(yè)務(wù)邏輯太負(fù)責(zé)，導(dǎo)致速度很慢，從而導(dǎo)致消費(fèi)者與服務(wù)器之間發(fā)生超時(shí)的問(wèn)題。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-722187.html
后續(xù)如果再出現(xiàn)對(duì)接kafka，我會(huì)選擇通過(guò)多線程操作，或者將kafka消費(fèi)消息與業(yè)務(wù)邏輯進(jìn)行異步處理，不要同步實(shí)現(xiàn)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-722187.html
到了這里，關(guān)于kafka消費(fèi)者報(bào)錯(cuò)Offset commit ......it is likely that the consumer was kicked out of the group的解決的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
