【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 小时前
Agent 不再是“玩具”!AgentScope Java 2.0 GA 发布:构建企业级分布式智能体底座
java·开发语言·分布式·agentscope
时代的狂8 小时前
RabbitMQ 面试问答
分布式·面试·rabbitmq
hkNaruto9 小时前
【大数据】《传统Hadoop大数据技术入门:补充与进阶——从数据格式到智能决策的问答实录》
大数据·hadoop·分布式
ThanksGive10 小时前
TurboLock:从 v1 Redis 分布式锁到 v2 Go 并发控制中间件
分布式·后端
韩楚风1 天前
【参天引擎】事务生命周期 / MVCC / Undo / ACID / 分布式事务 功能域整体解析
数据库·分布式·mysql·架构·cantian
ACP广源盛139246256731 天前
GSV6155@ACP# 搭配 AI 服务器、AI PC 完整适配方案
大数据·服务器·人工智能·分布式·单片机·嵌入式硬件
ZENERGY-众壹1 天前
50MW分布式VPP接入实战:调度中心要求的1分钟频率如何不卡死API
运维·服务器·分布式·光伏运维
富士康质检员张全蛋1 天前
Kafka的操作 生产消息
分布式·kafka
ClickHouseDB1 天前
推出 CostBench:一个用于数据仓库成本性能的开放基准
大数据·分布式·spark
liulilittle1 天前
麻将系统架构
服务器·网络·分布式·游戏·系统架构·通信