【Kafka踩坑系列之二】无限循环消费数据

本文介绍了在Kafka中遇到消费者无限循环消费同一批数据的问题,详细分析了问题背景,包括消费者配置、手动提交offset无效等情况。通过日志发现处理超时导致消费者被标记为dead。最终通过优化消费者程序性能,调整最大拉取字节数解决超时问题,成功修复了循环消费的bug。
摘要由CSDN通过智能技术生成

一、Bug背景

业务上线后,发现Kafka的消费者一直在重复拉取同一批数据。被消费的topic配置了10个分区,只有每个分区的第一批数据能够出队,并且无限循环。

因测试环境数据量比较小,一直无法复现问题。只能查生产环境的日志排查。

二、解决问题的思路

      初步猜测数据被消费之后,没有正常commit到Kafka服务端,导致Topic分区offset再消费完毕后未进行更新,下次取数据时还是从老offset开始取数据。

    1. 检查客户端配置
             自动提交已开启(enable.auto.commit的默认配置为true), 自动提交时间为5s(offsets.commit.timeout.ms的默认配置为5000)。
             既然默认已开启自动提交,按道理offset应该会被更新吖。然而并没有,Why?

    2. 添加手动提交代码
             每批数据处理完毕后,执行 consumer.commitSync(); 
             然并卵,why? 

    3. 只能添加日志埋点。
             发现消费者程序每批取出了6000多条数据,每批处理时间长达5分钟。
             另外一条关键日志,info级别,在每批数据处理完毕后打印出来:o.a.k.c.c.internals.AbstractCoordinator : Marking the coordinator 2147483646 dead.
             可以看出&#
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值