kafka hang 问题记录

参考文档

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)# 采集数据whileTrue:# 在Python里面，消费者库会自动处理__consumer_offsets的读写# 只需要调用poll()或者consume()等方法就能读取到新的消息，并且库会自动更新偏移量# 如果想要手动控制偏移量，也可以使用commit()等方法
    msg = consumer.poll(1.0)if msg isNone:continueif msg.error():print("Consumer error: {}".format(msg.error()))continueprint('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的工作机制，以及进行一些底层的调整优化等工作，了解这个概念还是有帮助的。