企业校园网站建设,专业做小程序公司有哪些,高端品牌网站建设兴田德润在那里,成都住建局官网电话查询参考文档
https://cloud.tencent.com/developer/article/1821477
9092端口
端口9092通常与Apache Kafka关联。 Kafka是一个开源的分布式事件流平台#xff0c;用于构建实时的数据管道和流应用。 它能够处理任意大小的数据#xff0c;以容错的方式处理数据流。
在默认配置…参考文档
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就没有可用的leaderleader的id就会显示为-1。
此时这个partition就无法正常工作任何试图读取或写入这个partition的操作都会失败。 需要尽快恢复副本使partition重新有可用的leader。 可以检查Kafka集群的健康状况并查看为什么所有的副本都不可用。 可能的原因包括磁盘故障、网络故障、Kafka broker配置问题等。
kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic your_topic_name 在运行这个命令后会输出一些列的信息 包括每个partition的ID当前的leader及副本和ISRin-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: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配置滑动窗口限制为3worker数量3worker缓冲大小3 消费侧配置两个消费者奇数key不阻塞偶数key hang住10分钟for循环20次每次sleep 30秒 单分区被hang住后offset无法往前移动导致该分区后续消息积压 发送消息让单分区hang住消息产生积压当600秒执行完之后后面的消息正常处理
__consumer_offsets
Kafka内部用于追踪消费者组对主题分区进行消费的偏移量的特殊topic。 每个消费者组对每个主题的每个分区都有一个偏移量表示这个消费者组最后一次消费到这个分区的哪个位置。 这样在消费者重启或者其他故障恢复的时候可以从这个位置开始接着读不会丢失中间的消息。
__consumer_offsetstopic通常对用户是不可见的因为它存储的是Kafka的内部数据。 对于一般的应用开发不需要也不应该去直接操作这个topic。 但是对于理解Kafka的工作机制以及进行一些底层的调整优化等工作了解这个概念还是有帮助的。
