【kafka】kafka 查看 GroupCoordinator 以及 kafka Group dead 消费组死掉 以及 GroupCoordinatorRequest 使用

已于 2024-01-17 20:29:01 修改
阅读量1.1k 收藏
点赞数
分类专栏： 大数据-kafka 文章标签： kafka group 消费组 死掉
于 2021-10-21 23:22:37 首次发布
本文为博主九师兄（QQ:541711153 欢迎来探讨技术）原创文章，未经允许博主不允许转载。
本文链接：https://blog.csdn.net/qq_21383435/article/details/120771140
版权
大数据-kafka 专栏收录该内容
403 篇文章 641 订阅 ¥99.90 ¥299.90
订阅专栏
本文探讨了如何使用Kafka的GroupCoordinatorRequest来检查消费组的状态。作者发现，无论消费组是否运行，请求总是返回集群的第一台机器作为GroupCoordinator，这并不意味着消费组正在运行。文章通过实例分析了请求的乌龙测试、正常情况和小结，得出结论：GroupCoordinatorRequest只能获取分配的协调器，而不能确认消费组是否活跃。
摘要由CSDN通过智能技术生成

本文为博主九师兄（QQ:541711153 欢迎来探讨技术）原创文章，未经允许博主不允许转载。

文章目录


在这里插入图片描述

1.概述

因为这篇博客：kafka通过java api 获取当前消费组offset/logsize/lag信息，实现消费延迟监控 我看到了，客户端可以发送 OffsetFetchResponse 请求。

然后追踪这个代码的时候发现构建BlockingChannel的时候，其实是一个SocketChannel.

然后实际生产中，我经常遇到消费组死掉。然后消费组死掉的话，经常有以下几个问题。

【kafka】消费组 死掉 kafka Marking the coordinator dead for group

【FLin

了解本专栏 订阅专栏 解锁全文
九师兄
关注
专栏目录
订阅专栏
【kafka】消费组 死掉 kafka Marking the coordinator dead for group
九师兄
12-13 3576
java kafka consumer不消费，报错marking the coordinator (id rack null) dead for groupStructedStreaming Kafka 排错（AbstractCoordinator: Marking the coordinator *dead for grou调整Spark Streaming的日志输出级别，解决Spark Streaming的代码报错：Marking the coordinator * dead for group。
【kafka】kafka 判断消费组死掉方案 group dead
九师兄
11-28 871
文章目录1.概述2.低版本2.1 zk存在offset2.高版本3. GroupCoordinator4. 监控currentOffset5. 监控日志6.重写kafka客户端 本文为博主九师兄（QQ:541711153 欢迎来探讨技术）原创文章，未经允许博主不允许转载。 1.概述 本文章想测试如何判断消费组死掉方案。消费组死掉可能会造成很多问题，比如下面的几种。 【kafka】kafka 查看 GroupCoordinator 以及 kafka Group dead 消费组死掉 以及 GroupCoord
【kafka】kafka 查看 GroupCoordinator 和 ConsumerCoordinator
九师兄
11-27 821
因为消费组死掉，然后我想用这个获取消费组状态。消费组死掉可能会造成很多问题，比如下面的几种。【kafka】kafka 查看 GroupCoordinator 以及 kafka Group dead 消费组死掉 以及 GroupCoordinatorRequest 使用【Flink】Flink Kafka 消费卡死 消费组卡死 topic无写入 实际有数据 topic正常。
java kafka consumer不消费，报错marking the coordinator (id rack null) dead for group
赶路人儿
07-06 8414
问题描述：在linux系统，通过 kafka 命令行客户端测试消费正常，但通过Java consumer客户端无法正常接收队列消息，启动后输出如下日志信息： 15:21:34.864 [concurrentMessageListenerContainer-0-kafka-consumer-1] INFO org.apache.kafka.clients.consumer.internals.AbstractCoordinator - Marking the coordinator platform-0
【kafka】Group coordinator xx is unavailable or invalid, will attempt rediscovery
九师兄
12-23 9589
kafka报错，但是这个环境，从监控上看一切正常。9092端口正常，zk正常，服务正常，查看topic正常，但是控制台消费异常。代码消费异常。kafka 相应的hostname 和ip 对应关系没有配置Kafka 消息无法接收(group coordinator is not available)
Kafka-Spark Streaming 异常： dead for group td_topic_advert_impress_blacklist
迎难而上
11-01 4707
  最近在编写Spark Streaming 作业的时候，遇到了一个比较奇怪的问题，表现如下：   在本地连接Kafka 集群执行作业： 18/10/31 17:42:58 INFO AbstractCoordinator: Discovered coordinator kafka1:9092 (id: 2147483574 rack: null) for group td_topic_...
kafka 中查看所有的group列表信息
热门推荐
mhbsoft的博客
05-06 2万+
[root@kafkasitapp240 kafka_2.11-1.1.1]# bin/kafka-consumer-groups.sh --zookeeper 【zk的ip】:2181 --list
kafka 分组消费topic_Kafka消费组(consumer group)(转）
weixin_42494742的博客
12-24 1934
在开始之前，我想花一点时间先来明确一些概念和术语，这会极大地方便我们下面的讨论。另外请原谅这文章有点长，毕竟要讨论的东西很多，虽然已然删除了很多太过细节的东西。一、 误区澄清与概念明确1 Kafka的版本很多人在Kafka中国社区(替群主做个宣传，QQ号：162272557)提问时的开头经常是这样的：“我使用的kafka版本是2.10/2.11, 现在碰到一个奇怪的问题。。。。” 无意冒犯，但这里...
【FLink】Flink 消费 kafka 消费组 死掉 Marking the coordinator dead for group 造成数据重复消费
九师兄
07-28 1348
【Flink】Flink Kafka 消费卡死 消费组卡死 topic无写入 实际有数据 topic正常Kafka : kafka无法消费的情况在博客【kafka】消费组 死掉 kafka Marking the coordinator dead for group中消费组死掉，但是不会造成数据重复消费，但是这次却造成重复消费了。flink消费kafka的时候，出现了一个两个warn日志，后面flink继续运行。
spring boot整合kafka @KafkaListener日志输出dead for group解决办法
xiaoliuyiting的博客
09-06 6872
问题： 2018-09-06 11:43:41.508 |-INFO  [org.springframework.kafka.KafkaListenerEndpointContainer#1-7-C-1] org.apache.kafka.clients.consumer.internals.AbstractCoordinator [600] -| Marking the coordinator...
Kafka查看topic、consumer group状态命令
mhbsoft的博客
05-13 6253
bin/kafka-consumer-groups.sh --zookeeper 127.0.0.1:2181 --list
kafka查看分组、查看消费情况及重启
Sunlit_1101的博客
05-24 4424
1、查看分组 先cd到kafka安装目录 bin/kafka-consumer-groups.sh --bootstrap-server ip:端口 --list 2、查看消费情况 bin/kafka-consumer-groups.sh --describe --bootstrap-server p:端口 --group 分组名称 3、重启kafka 先重启zookeeper组件 ./bin/zookeeper-server-start.sh -daemon ./config/z.
SparkStreaming链接kafka异常 dead for group td_topic_advert_impress_blacklist
top8488.top大数据
11-06 460
Kafka-Spark Streaming 异常： dead for group td_topic_advert_impress_blacklist 很有可能是防火墙问题 或者是C:\Windows\System32\drivers\etc\hosts 文件的问题！！！ 18/10/31 17:42:58 INFO AbstractCoordinator: Discovered co...
Group coordinator lookup failed: The coordinator is not available.问题
地球人是我哈的博客
05-21 3399
背景：最近使用的项目中用到了kafka，并且需要集成kerberos.这边kerberos认证已经通过，但是在消费的时候一直拉不到数据，随后使用shell命令在服务器上消费数据，结果一样。 后面更改日志级别，发现一直循环打印如下日志: 2020-05-21 10:05:06.651 [ForkJoinPool-1-worker-5] DEBUG org.apache.kafka.clients.Metadata - Updated cluster metadata version 133 to Cluste
spring整合kafka时出现Group coordinator is unavailable or invalid, will attempt rediscovery错误
weixin_55174868的博客
05-27 7245
                                                                       .
kafka0.11版本消费报错Group coordinator is unavailable or invalid, will attempt rediscovery
gaofeng的博客
09-29 1万+
报错 消费单节点kafka 要么消费很缓慢 要么报错 Group coordinator ip:9092 (id: 2147483647 rack: null) is unavailable or invalid, will attempt rediscovery 重启节点也没用 分析 单节点情况下coordinator 压力太大了 __consumer_offsets这个元主题的历史消息量分配不均衡 有分区kb、M级别正常，有几个分区直接几十G，如果消费的主题在这些压力大的分区，就会消费阻塞 因为这个元主
kafka消费报错coordinator unavailable.Rediscovery will be attempt redisCovery
weixin_51656756的博客
07-18 2946
kafka消费报错coordinator unavailable.Rediscovery will be attempt redisCovery
消息中间件-kafka实战-第五章-kafka重复消费、顺序消费及死信队列
Blueeyedboy521的博客
08-22 1307
这个默认值是比较坑人的，如果你的消息处理逻辑比较重，比如需要查数据库，调用接口，甚至是复杂计算，那么你很难保证能够在5min内处理完500条消息，也就是说，如果上游真的突然大爆发生产了成千上万条消息，而平摊到每个消费者身上的消息达到了500的又无法按时消费完成的话就会触发rebalance, 然后这批消息会被分配到另一个消费者中，还是会处理不完，又会触发rebalance, 这样这批消息就永远也处理不完，而且一直在重复处理。，单次poll调用返回的最大消息记录数，如果处理逻辑很轻量，可以适当提高该值。
springboot项目连接虚拟机kafka服务器，消息发送、接收问题
sy_wb的博客
10-29 8888
错误信息：Group coordinator promote.localdomain:9092 (id: 2147483647 rack: null) is unavailable or invalid, will attempt rediscovery 2018-10-29 14:56:52.496  INFO 33656 --- [ntainer#0-0-C-1] o.a.k.c.c.inte...
kafka消费者重试机制
最新发布
12-08
Kafka消费者重试机制可以通过建立一个专门用于重试的topic（retry topic）来实现。当消费者没有正确消费一条消息时，将该消息转发（发布）到重试主题（retry topic）上，并提交消息的偏移量，以便继续处理下一个消息。这个时候，这个没有正确消费的消息，对于这个消费者来说，也算是消费完成了，因为也正常提交了偏移量，只不过是业务没有正确处理，而且这个消息被发布到另一个topic中了（retry topic）。之后再创建一个重试消费者，用于订阅这个重试主题，只不过这个重试消费者，跟之前那个消费者处理相同的业务，两个逻辑是一样的。如果这个重试消费者也无法消费这条消息，那就把这个消息发布到另一个重试主题上，并提交该消息的偏移量。循环，递归。最后，当创建了很多重试消费者的时候，在最终重试消费者无法处理某条消息后，把该消息发布到一个死信队列（DLQ）。 ```shell # 代码示例 # 创建一个专门用于重试的topic bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic retry_topic # 消费者处理消息时，如果出现异常，将消息转发到重试主题上 # 代码示例 try: # 处理消息的业务逻辑 except Exception as e: # 将消息转发到重试主题上 producer.send('retry_topic', value=message.value, key=message.key) # 创建一个重试消费者，用于订阅重试主题 # 代码示例 consumer = KafkaConsumer('retry_topic', bootstrap_servers=['localhost:9092'], group_id='retry_group') for message in consumer: try: # 处理消息的业务逻辑 except Exception as e: # 将消息转发到另一个重试主题上 producer.send('retry_topic_2', value=message.value, key=message.key) # 提交消息的偏移量 consumer.commit() # 将无法处理的消息发布到死信队列 # 代码示例 producer.send('dead_letter_queue', value=message.value, key=message.key) ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

九师兄

你的鼓励是我做大写作的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值