kafka hang 问题记录

发布时间:2024年01月20日

参考文档

https://cloud.tencent.com/developer/article/1821477

9092端口

端口9092通常与Apache Kafka关联。
Kafka是一个开源的分布式事件流平台,用于构建实时的数据管道和流应用。
它能够处理任意大小的数据,以容错的方式处理数据流。

在默认配置中,Kafka的代理(Broker)监听9092端口以接收来自生产者(Producers)、消费者(Consumers)以及其他Kafka代理的连接请求。
生产者将事件数据发送到Kafka,而消费者从Kafka读取这些数据。这些操作都通过9092端口完成。

注意
尽管9092是Kafka默认的端口,但它可以在Kafka的配置文件中进行修改。
这在多代理部署或网络策略需要其他端口时非常有用。

kafka-consumer-groups.sh

kafka-consumer-groups.sh 是 Apache Kafka 分发包中的一个 shell 脚本,用于列出所有消费者组
描述消费者组的详细信息,或者删除消费者组信息。

列出所有消费者组:
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

描述特定消费者组的详细信息:
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe

删除特定消费者组的信息:
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --delete

注意:–bootstrap-server 参数指定了 Kafka 集群的一个或多个 broker 地址
如果Kafka集群布署在别的主机或者端口,那么需要修改localhost:9092参数,指向真正的Kafka集群地址

只要命令中的 --bootstrap-server 参数正确地指向了 Kafka 集群中的任意一个可用的 Broker 地址
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list 命令就能够列出该 Kafka 集群中的全部消费者组。

topic的leader为-1

如果一个topic的leader为-1,那通常意味着这个topic的所有副本都不可用。
Kafka中每个partition都有一个leader副本,所有的读写操作都会通过这个leader副本进行。
每个partition还可以有一个或多个follower副本,它们会尽可能地同步leader副本的数据,以提供高可用性和故障转移。

如果leader副本宕机或者其他原因不可用,那么Kafka会从follower副本中选举一个新的leader。
但是如果没有可用的follower副本(比如所有副本都宕机或者消失),
那么这个partition就没有可用的leader,leader的id就会显示为-1。

此时,这个partition就无法正常工作,任何试图读取或写入这个partition的操作都会失败。
需要尽快恢复副本,使partition重新有可用的leader。
可以检查Kafka集群的健康状况,并查看为什么所有的副本都不可用。
可能的原因包括磁盘故障、网络故障、Kafka broker配置问题等。

kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic your_topic_name
在运行这个命令后,会输出一些列的信息
包括每个partition的ID,当前的leader,及副本和ISR(in-sync replica,同步副本)的列表

注意
Kafka集群的每个partition都有一个leader,所以一个topic可能有多个leader,分别负责不同的partition

HW采集程序,采集某个消费组下某个topic的情况

首先需要一个运行环境 (例如 Python) 并安装相应的库 (如 HW Python SDK)
然后需要连接到 Kafka 集群并订阅主题

from hwsdk import get_consumer
import time

# 定义消费组和相关主题
group_id = 'your_group_id'
topics = ['topic1', 'topic2']

# 创建消费者实例
consumer = get_consumer(group_id)

# 订阅多个主题
consumer.subscribe(topics)

# 采集数据
while True:
	# 在Python里面,消费者库会自动处理__consumer_offsets的读写
	# 只需要调用poll()或者consume()等方法就能读取到新的消息,并且库会自动更新偏移量
	# 如果想要手动控制偏移量,也可以使用commit()等方法
    msg = consumer.poll(1.0)

    if msg is None:
        continue
    if msg.error():
        print("Consumer error: {}".format(msg.error()))
        continue

    print('Received message: {}'.format(msg.value().decode('utf-8')))

    time.sleep(5)  # 每5秒采集一次数据

# 退出时关闭消费者连接
consumer.close()

hang住问题记录

前端时间debug问题时,消费侧hang住,积压严重,迁移了消费者还是会hang住
分区offset更新到最新后(直接丢弃业务数据用于止损),积压消除,但是后续又慢慢积压上来了

问题原因

消费侧的代码逻辑是个for循环,因为某些异常业务导致for循环5分钟以上仍未执行结束
单分区被hang住后,offset无法往前移动,导致该分区后续消息积压

解决办法

如果某个分区因为某个实例被hang住,重置某分区的offset到最新后,因为没有重启消费侧的服务
所以被hang住的消费实例还是会一直处理这个消息直到结束
处理完后提交offset时,Broker才会忽略该offset,因为offset已经重置到最新
因为处于配置封禁期,因此临时将for循环添加过滤和及时退出逻辑,才解决该问题

复线

创建一个topic,设置两个分区0和1
Broker配置滑动窗口限制为3,worker数量3,worker缓冲大小3
消费侧配置两个消费者,奇数key不阻塞,偶数key hang住10分钟(for循环20次,每次sleep 30秒)
单分区被hang住后,offset无法往前移动,导致该分区后续消息积压
发送消息,让单分区hang住,消息产生积压,当600秒执行完之后,后面的消息正常处理

__consumer_offsets

Kafka内部用于追踪消费者组对主题分区进行消费的偏移量的特殊topic。
每个消费者组对每个主题的每个分区都有一个偏移量,表示这个消费者组最后一次消费到这个分区的哪个位置。
这样在消费者重启或者其他故障恢复的时候,可以从这个位置开始接着读,不会丢失中间的消息。

__consumer_offsetstopic通常对用户是不可见的,因为它存储的是Kafka的内部数据。
对于一般的应用开发,不需要也不应该去直接操作这个topic。
但是对于理解Kafka的工作机制,以及进行一些底层的调整优化等工作,了解这个概念还是有帮助的。

文章来源:https://blog.csdn.net/wangkai6666/article/details/135708406
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。