记录一次线上kafka故障及处理方式

最新推荐文章于 2025-09-04 22:01:40 发布
原创 最新推荐文章于 2025-09-04 22:01:40 发布 · 1.9k 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kafka #java #分布式 #程序人生 #开发语言

本文记录了一次线上kafka消息堆积、consumer掉线的故障排查过程。问题源于业务代码中的死循环导致消费者自我驱逐，通过修改kafka-client参数和检查消费逻辑找到解决办法。文章讨论了kafka客户端是否应有消费超时异常以及如何快速发现消费死循环，并提出了kafka使用最佳实践。

前言

线上kafka消息堆积，所有consumer全部掉线，到底怎么回事？

最近处理了一次线上故障，具体故障表现就是kafka某个topic消息堆积，这个topic的相关consumer全部掉线。

整体排查过程和事后的复盘都很有意思，并且结合本次故障，对kafka使用的最佳实践有了更深刻的理解。

好了，一起来回顾下这次线上故障吧，最佳实践总结放在最后，千万不要错过。

1、现象

  • 线上kafka消息突然开始堆积

  • 消费者应用反馈没有收到消息（没有处理消息的日志）

  • kafka的consumer group上看没有消费者注册

  • 消费者应用和kafka集群最近一周内没有代码、配置相关变更

2、排查过程

服务端、客户端都没有特别的异常日志，kafka其他topic的生产和消费都是正常，所以基本可以判断是客户端消费存在问题。

所以我们重点放在客户端排查上。

1）arthas在线修改日志等级，输出debug

由于客户端并没有明显异常日志，因此只能通过arthas修改应用日志等级，来寻找线索。

果然有比较重要的发现：

2022-10-25 17:36:17,774 DEBUG [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] - [Consumer clientId=consumer-1, groupId=xxxx] Disabling heartbeat thread 2022-10-25 17:36:17,773 DEBUG [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] - [Consumer clientId=consumer-1, groupId=xxxx] Sending LeaveGroup request to coordina
最低0.47元/天 解锁文章
Java_LingFeng
关注
【kafka】记一次线上kafka一直rebalance故障 消费慢 数据积压
九师兄
11-18 4286
文章目录1.背景2. 分析问题3.分析原因4.拉取偏移量与提交偏移量5.解决方案5.1.增加max.poll.interval.ms处理时长5.2设置分区拉取阈值5.3.poll到的消息，处理完一条就提交一条，当出现提交失败时，马上跳出循环，这时候kafka就会进行rebalance,下一次会继续从当前offset进行消费。6.场景再现27.场景再现3 1.背景 今天我司线上kafka消息代理出现错误日志，异常rebalance，而且平均间隔2到3分钟就会rebalance一次，分析日志发现比较严重。错误
大厂消息中间件高频面试题与知识点整理（RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ）
热门推荐
张彦峰的博客
04-07 172万+
互联网高频面试之消息中间件基本问题和知识点整理分析
Kafka消息堆积问题排查
Diligence is the mother of success.
09-15 1702
背景业务架构图根据 微服务重构：Mysql+DTS+Kafka+ElasticSearch解决跨表检索难题所描述，我们使用了Es解决微服务重构中遇到的Mysql库拆分问题，业务架构图如下所示：Kakfa消息堆积导致的数据一致性问题在下午14:15左右，收到用户反馈，短暂时间内，出现了业务数据一致性问题具体表现是：用户提交了一个页面操作，但是在查询接口里，没有返回最新的操作结果具体校验是：通过问题反...
Kafka消息堆积
Absosba的博客
10-22 1168
消息堆积顾名思义就是Kafka中消息太多，在Kafka中准确来说是日志太多，但其实我认为日志堆积主要想说明的是日志没有被及时消费，而且Kafka中日志本来就一直被保存，除非被日志清理策略清理掉。
Kafka——消息队列堆积
努力找工作呀
06-11 810
如何解决消息队列堆积几百万消息怎么办？ 这个造成的原因就是消费端出现了问题，不消费了或者消费速度变慢了。 消息堆积几小时在队列 先修复consumer的问题，确保其恢复消费速度，然后将现在的comsumer停掉 新建一个topic,partition是原来的10倍，临时建好原先10倍的queue数量 然后写一个临时的分发数据的consumer程序，这个程序部署消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建立好的10倍的queue中 接着临时征用10倍机器来部署consumer，每一
kafka消息堆积问题
weixin_44483048的博客
11-18 1339
问题原因 kafka的生产者产生了大量的消息，而消费者由于需要不断与数据库交互导致在指定的时间内一直无法完成对消息的消费，导致broker堆积了大量的消息，时间久了broker认为一直消费超时的consumer挂掉了，从而启动了rebanlance。 解决方法 消费者引入线程池来消费消息，这样可以提高消费效率。 调整消费者每次poll消息的数量，max.poll.records默认为500，可以改成50，具体数据看业务场景。 ...
线上故障分析-故障分级，原因，分类，混沌工程，排除方法
m0_46690280的博客
03-03 1万+
线上故障分析1 生产故障分级规范概要1.1 开篇三级目录 1 生产故障分级规范概要 1.1 开篇 计算机是当今世界的命脉，你能看到的任何地方，计算机都在改变着世界，不论是传统的制造生产，医疗通讯。还是新兴的虚拟现实，无人驾驶汽车 等领域。过去的几十年，计算机硬件飞速发展，软件领域也是不断刷新着人们的想象。可以说，计算机学科复杂而且庞大，甚至有人说，不亚于物理学。 三级目录 ...
Kafka在电商领域的应用：实时订单处理系统设计
最新发布
AI天才研究院
09-04 1110
在当今电商行业的激烈竞争中，实时性已成为核心竞争力。本文深入探讨Apache Kafka作为分布式流处理平台，如何彻底变革电商订单处理系统的架构范式。通过第一性原理分析，我们将解构订单处理的本质需求，构建基于Kafka的高性能、弹性扩展的实时订单处理架构。从理论基础到实践落地，本文提供了完整的知识框架：从Kafka的核心设计原理，到电商订单流的建模方法；从单节点实现到全球分布式部署；从性能优化到故障恢复策略。
kafka高并发消息堆积
咖啡的博客
04-29 3572
1、 使用Kafka时，消费者每次poll的数据业务处理时间不能超过kafka的max.poll.interval.ms，该参数在kafka0.10.2.1中的默认值是300s,所以要综合业务处理时间和每次poll的数据数量。 2、Java线程池大小的选择： （1）对于CPU密集型应用，也就是计算密集型，线程池大小应该设置为CPU核数+1； （2）对于IO密集型应用 ...
Kafka消费者不消费数据
fox_233的博客
09-08 8783
kafka消费者停止消费
Kafka查看消息是否堆积（服务器）
Li_games的博客
04-24 3855
kafka消息偏移量查看
kafka怎么查看消息堆积_Kafka 线上问题: 消息堆积一直不消费, 重启服务后开始消费...
weixin_36425412的博客
01-12 1242
消息堆积一直不消费，感觉消费者已经死掉一样。重启服务后开始消费，但是消费一段时间又停止。开始尝试增加消费者数量和增加 pod(节点)数，但是都不能完全解决，异常依然存在。通过 dump 出堆栈信息发现消费则全部处在 WAITING 状态，这个状态是挂起状态，并且是无限期等待："kafka-coordinator-heartbeat-thread | CID_alikafka_xxx" #125 d...
kafka一次消息堆积处理
天道酬勤
08-29 1055
kafka生产环境参数调整
记一次线上Kafka消息堆积踩坑总结
xiaoguozi0218的博客
05-31 3万+
年后上线的系统，与其他业务系统的通信方式采用了第三代消息系统中间件Kafka。由于是第一次使用，踩了很多坑，通过这篇博客和大家分享一下，也算是做个总结，以便以后温故而知新。一、线上问题 系统平稳运行两个多月，基本上没有问题，知道最近几天，突然出现Kafka手动提交失败，堆栈信息如下：通过堆栈信息可以看出，有两个重要参数： session.timeout 和 max.poll.reco...
kafka消息堆积原因解析
鸭梨的博客
02-04 2954
kafka消息堆积,可以调节如下两个参数 max.poll.records 一次调用poll（）返回的最大记录数。 默认值500 就是一次最多拉取500条记录 max.poll.interval.ms max.poll.interval.ms参数用于指定consumer两次poll的最大时间间隔（默认5分钟），如果超过了该间隔consumer client会主动向coordinator发起LeaveGroup请求，触发rebalance；然后consumer重新发送JoinGroup请求 The maxi
Kafka消息堆积如何处理？
iddlw75046的博客
07-23 1196
​​先诊断后治理​​：用Lag定位堆积程度和分区分布。​​监控优先​​：部署实时告警（如Prometheus+Grafana）早于故障发生。​​快速扩容​​：临时增加分区/消费者是见效最快的手段。​​长期优化​​：代码性能 > 资源配置 > 架构调整。
Kafka消息堆积处理方案
zhanghe_zht的博客
03-29 1988
3.如果是下游的数据处理不及时：提高每批次拉取的数量。每批次拉取的数据过少（拉取的数据/处理时间
Kafka重复消费
08-28
<think>我们正在处理用户关于Kafka重复消费的问题。用户提供了三个引用，这些引用讨论了Kafka重复消费的原因和解决方案。根据用户的问题，我们需要总结Kafka重复消费的原因及解决办法，并参考用户提供的引用内容。 引用[1]提到重复消费的原因包括： 1. 强行kill线程，导致offset没有提交（如消费系统宕机、重启等）。 2. 设置offset为自动提交，关闭kafka时，如果在close之前调用consumer.unsubscribe()，则可能部分offset没提交，下次重启会重复消费。 引用[2]提到解决方案： 1. 手动提交偏移量：确保消息处理完成后立即提交偏移量，避免重复消费。 2. 幂等性设计：消费者处理消息时设计为幂等操作，即使重复消费也不会影响结果。 3. 事务支持：使用Kafka事务，确保消息处理和偏移量提交在同一个事务中，避免重复消费。 引用[3]则详细记录了线上问题解决及思考，包括重复消费的原因和解决方案，其中提到： - 重复消费的原因可能包括：消费超时、发生重平衡等。 - 解决方案：对批量消息进行去重（如使用Redis去重），生产者在发送消息前进行路由分区等。 结合以上引用和我们对Kafka的理解，整理重复消费的原因及解决方案如下： 原因： 1. 消费者未正确提交偏移量（如消费者崩溃、手动kill线程等）。 2. 自动提交偏移量时，在提交间隔内发生故障，导致部分已处理的消息偏移量未提交。 3. 消费者处理时间过长导致会话超时（session.timeout.ms）或轮询间隔超时（max.poll.interval.ms），触发重平衡，导致重复消费。 4. 消费者在拉取一批消息后，在处理过程中发生重平衡，这批消息会被其他消费者重新消费。 解决方案： 1. 使用手动提交偏移量（推荐使用同步提交，确保提交成功后再继续处理后续消息）。 2. 设计幂等消费者：无论同一条消息消费多少次，结果都一样（例如通过业务主键去重，或使用数据库唯一键等）。 3. 使用Kafka的事务机制（生产者端使用事务，消费者端设置隔离级别为read_committed）。 4. 优化消费者处理逻辑，避免处理时间过长，调整相关参数（如增加session.timeout.ms和max.poll.interval.ms，减少max.poll.records以控制每次拉取的消息数量）。 5. 在消费者端实现消息去重（例如使用Redis记录已处理消息的ID，或使用数据库唯一约束）。 注意：引用[3]中提到的poll(5000)中5000的含义是设置poll的超时时间为5秒，即如果没有可用的消息，消费者等待5秒。另外，如果poll处理时发生异常，应该捕获异常并确保偏移量不会提交，同时需要处理重试或死信队列。 我们将按照以下结构组织回答： 一、Kafka重复消费的常见原因 二、解决方案 三、最佳实践建议 同时，在回答末尾添加相关问题，以引导用户进一步探讨。 注意：在回答中，我们会在适当位置添加引用标记[^1][^2][^3]。</think>### Kafka重复消费原因及解决方案深度解析 以下基于Kafka核心机制和线上实践经验，系统分析重复消费的根源及解决方案： --- #### 一、重复消费的根本原因 1. **偏移量提交失败** - 消费者崩溃或强制Kill线程，导致处理后的消息偏移量未提交[^1] - 自动提交模式下关闭消费者，触发`consumer.unsubscribe()`时偏移量丢失 ```mermaid flowchart LR A[消费消息] --> B[处理完成] B --> C{提交偏移量} C -->|失败| D[下次重启重复消费] ``` 2. **重平衡触发（Rebalance）** | 参数 | 默认值 | 导致重复的场景 | |-----------------------|----------|-------------------------------| | `session.timeout.ms` | 10秒 | 消费者心跳超时 | | `max.poll.interval.ms`| 5分钟 | 消息处理超时 | | `max.poll.records` | 500 | 单批次消息过多处理超时[^3] | **机制**：重平衡时未提交偏移量的消息会被重新分配 3. **生产者重试机制** - 生产者未收到Broker ACK时自动重发 - 网络闪断导致消息重复写入分区 $$P_{dup} = P_{send} \times (1 + R_{retry}) \quad R_{retry} \text{为重试概率}$$ --- #### 二、系统级解决方案 ##### 方案1：精准偏移量控制 ```java // 同步提交（强一致） consumer.commitSync(); // 异步提交+重试机制 consumer.commitAsync((offsets, exception) -> { if (exception != null) { log.error("提交失败，启动重试", exception); retryCommit(offsets); // 自定义重试逻辑 } }); ``` **关键配置**： - 禁用自动提交：`enable.auto.commit=false` - 设置合理提交间隔：`auto.commit.interval.ms=0`（手动模式） ##### 方案2：幂等性设计 ```java // 使用Redis实现去重 public boolean processMessage(Message msg) { String msgId = msg.key(); if (redis.setnx(msgId, "1", 24*3600)) { // 24小时去重窗口 businessLogic(msg); return true; } return false; // 重复消息直接跳过 } ``` **适用场景**： - 订单状态变更 - 账户余额操作 - 唯一性约束操作 ##### 方案3：Kafka事务机制 ```java // 生产者端 producer.initTransactions(); try { producer.beginTransaction(); producer.send(record); producer.sendOffsetsToTransaction(offsets, groupId); // 提交偏移量 producer.commitTransaction(); } catch (Exception e) { producer.abortTransaction(); } ``` **消费者配置**： ```properties isolation.level=read_committed // 只消费已提交事务的消息 enable.auto.commit=false ``` --- #### 三、参数调优实践 | 参数 | 推荐值 | 作用 | |------------------------|--------------|-------------------------------| | `max.poll.records` | 10-100 | 控制单次拉取量 | | `session.timeout.ms` | 30000 (30s) | 避免网络抖动误判 | | `max.poll.interval.ms` | 300000 (5min)| 给处理逻辑充足时间 | | `request.timeout.ms` | 40000 (40s) | 大于session.timeout.ms | **处理超时场景优化**： ```java ExecutorService processor = Executors.newFixedThreadPool(4); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(5000)); for (ConsumerRecord record : records) { processor.submit(() -> { try { process(record); // 异步处理 } finally { consumer.commitSync(Collections.singletonMap( new TopicPartition(record.topic(), record.partition()), new OffsetAndMetadata(record.offset() + 1) )); // 逐条提交 } }); } } ``` --- #### 四、典型场景解决方案 1. **批量消息去重** ```mermaid graph LR A[拉取批量消息] --> B[提取消息ID] B --> C[Redis SADD去重] C -->|新消息| D[处理业务] C -->|重复消息| E[直接提交偏移量] ``` 2. **分区路由优化** ```java // 生产者确保相同key到固定分区 producer.send(new ProducerRecord<>("topic", orderId, message)); ``` **优势**：相同业务数据始终由同一消费者处理，避免跨消费者去重 3. **死信队列降级** ```mermaid flowchart LR Main[主消费者] -->|处理失败| DLQ[死信队列] DLQ --> Retry[专用重试消费者] Retry -->|成功| Commit Retry -->|多次失败| Alarm[告警人工介入] ``` --- > **核心结论**： > 1. 优先采用 **幂等设计+手动提交** 组合方案 > 2. 事务机制适用于金融级场景，但性能下降约20% > 3. 参数调优需满足： > $$T_{process} \times N_{poll.records} < T_{max.poll.interval}$$ > 4. 监控关键指标：重平衡次数、提交延迟、消息积压量 ---
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值