【Kafka】记录一次Kafka消费者重复消费问题

文章目录

现象

用户反馈消费者出现消息积压,并且通过日志看,一直重复消费,且没有报错日志。

业务背景

  1. 用户的消费者是一个将文件做Embedding的任务,(由于AI技术的兴起,大量文档需要做RAG);
  2. Embedding是一个比较耗时的过程,如果文件大,耗时会更长;
  3. 消费者使用的是push模式、手动提交offset的方式;
  4. 由于耗时比较长,将提交offset的超时时间改成了2小时;
  5. 服务运行一段时间,QPS不高(个位数),压力不大。

排查过程

  1. 从监控中看,消费者有了100多条积压,并且持续了很长时间;
  2. 从业务上,有一个用户同一时间上传了大量大文件;
  3. 只有一个消费者,服务端瞬间产生大量消息,同一时间推送给了消费者;
  4. 消费者处理Embedding任务超过两小时,导致这一批消息提交offset超时;
  5. 服务端认为客户端处理消息失败,一直进行重新推送,所以造成了没报错,但是一直重复消费的情况。

Push与Pull

MQ的消费模式可以大致分为两种,一种是推Push,一种是拉Pull。

  • Push是服务端主动推送消息给客户端,优点是及时性较好,但如果客户端没有做好流控,一旦服务端推送大量消息到客户端时,就会导致客户端消息堆积甚至崩溃。
  • Pull是客户端需要主动到服务端取数据,优点是客户端可以依据自己的消费能力进行消费,但拉取的频率也需要用户自己控制,拉取频繁容易造成服务端和客户端的压力,拉取间隔长又容易造成消费不及时。
相关推荐
罗四强7 分钟前
第10篇:打包上架:签名、打包 HAP、发布到华为应用市场
分布式·操作系统·harmonyos·arkts·鸿蒙系统
秋饼16 分钟前
Redis 全面解析:从数据结构到主从/哨兵/集群、分布式锁与面试高频考点,代码到原理一次讲透
数据库·redis·分布式·面试·后端开发
二月夜17 分钟前
Redis 高频面试题全解:缓存三大问题、大 key 治理与分布式锁之争(2026 招聘 JD 真题复盘)
redis·分布式·后端·缓存
后台模板学习34 分钟前
Kafka 与 RabbitMQ 在用户认证与权限管理场景
kafka·rabbitmq·linq
樱花落木兰35 分钟前
Redis 消息队列的可靠性演进:从 List、Pub/Sub 到 Stream 消费者组,以及 8.x 版本改变了什么
java·开发语言·经验分享·redis·分布式·python·软件工程
真上帝的左手3 小时前
12. 消息队列-Kafka进阶
分布式·中间件·kafka
Thanks_ks21 小时前
Cookie 和 Session 到底是什么关系——登录态是怎么维持的
分布式·http·jwt·cookie·session·后端开发·登录态
千里达景区票务系统1 天前
消息队列选型对比:RabbitMQ vs RocketMQ vs Kafka
kafka·消息队列·rabbitmq·rocketmq
Sayai1 天前
Kafka 跨数据中心日志同步实战:MirrorMaker 2 选型对比 + Flink 中继任务落地(双中心互备与消费者组隔离避坑)
大数据·运维·分布式·flink·kafka·消息队列·高可用
jianjinwssy1 天前
从零设计一个 Agent 安全沙箱:Docker 隔离、三级风控与 Kafka 审计
人工智能·docker·kafka