【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是客户端需要主动到服务端取数据,优点是客户端可以依据自己的消费能力进行消费,但拉取的频率也需要用户自己控制,拉取频繁容易造成服务端和客户端的压力,拉取间隔长又容易造成消费不及时。
相关推荐
starzy19905 小时前
SparkSQL 数据源与底层架构深度剖析
大数据·分布式·架构·spark
番茄炒鸡蛋加糖6 小时前
RabbitMQ 全套复盘 + Nacos+ES+MyBatis-Plus 梳理
分布式·rabbitmq
零域码客14 小时前
从 SQLite 到 PostgreSQL:轻量单机到分布式架构选型、避坑与迁移全解析
分布式·postgresql·sqlite·wal·架构设计·后端开发·数据库选型
ltl1 天前
2PC 的真实失败模式:阻塞、脑裂与恢复
分布式
霸道流氓气质1 天前
分布式系统设计:技术解析与实践
分布式
画中有画1 天前
分布式锁架构方案选型与实践
分布式·架构
ACP广源盛139246256731 天前
蚂蚁百灵 Ling‑3.0‑flash 开源 + 昇腾 0‑Day 原生适配@ACP#GSV9001E 在国产算力矩阵中的机会与落地场景
大数据·人工智能·分布式·单片机·嵌入式硬件
汽车仪器仪表相关领域1 天前
KRYPTON坚固型IP67 EtherCAT总线数据采集模块:工业级分布式采集方案
分布式·功能测试·汽车·压力测试·可用性测试
霸道流氓气质1 天前
Java中信号量(Semaphore):从本地到分布式
java·开发语言·分布式
naierfengdian1 天前
分布式风电助力乡村能源转型的技术路径
分布式·能源