kafka问题总结

最新推荐文章于 2025-06-24 00:57:05 发布

原创最新推荐文章于 2025-06-24 00:57:05 发布 · 759 阅读

1 ·

CC 4.0 BY-SA版权

kafka 专栏收录该内容

12 篇文章

订阅专栏

本文总结了Kafka在重启后可能出现的两类问题及其解决办法。一是遇到LeaderNotAvailableException错误，解决方法包括检查Zookeeper和Broker上的leader信息，删除并重新创建topic。二是针对消费组lag堆积问题，提供了通过ConsumerOffsetChecker监控以及调整消费线程数或更换消费组的策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

kafka重启如果topic副本因子是一个的有可能导致以下两种问题：

1、
class kafka.common.LeaderNotAvailableException错误处理方案：
一般是zk上的leader信息和broker上的leader信息不一致
可以通过如下命令检查
zk上信息：
get /brokers/topics/profile-manual-x/partitions/0/state
broker上信息：
kafka-topics.sh -zookeeper 192.168.1.60:2181,192.168.1.61:2181,192.168.1.62:2181 -describe -topic profile-reformat-x、

kafka删除topic profile-reformat-x
rmr /config/topics/profile-reformat-x
rmr /brokers/topics/profile-reformat-x
rmr /admin/delete_topics/profile-reformat-x

删除完成后，在创建相应的topic
kafka-topics.sh -create -zookeeper 192.168.1.60:2181,192.168.1.61:2181,192.168.1.62:2181
--replication-factor 2 --partitions 1
--topic profile-reformat-x

2、
使用kafka-run-class.sh命令查询某个分组是,发现lag堆积的记录数消费不完
while true; do ./kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group reformat-click-group-new --zookeeper 192.168.1.60:2181,192.168.1.61:2181,192.168.1.62:2181; sleep 10; done;

不通过zk，消费的api监控

bin/kafka-consumer-groups.sh --new-consumer --bootstrap-server 192.168.1.60:9092,192.168.1.61:9092,192.168.1.62:9092 --describe --group reformat-request-new-group-x

a、确实是堆积数据消费不完
这种情况，在175机器上，开取更多的线程来
修改conf下相应配置文件
inner.processors.per.queue = 线程数
将224上相应的服务停止（224上有monitor定时监控启动的，需要暂时关闭）
b、lag值是个虚值,就是相应的组有问题，换个组消费
在zk上可以查询相应的topic分区的offset值get /consumers/reformat-click-group/offsets/click/0
zk上offset值是可以正常消费的，则验证是group出现的问题
换个组消费，修改相应服务配置：src.kafka.consumer.group = reformat-profile-fuck
在zk上删除有问题的组：rmr /consumers/reformat-profile-zhizi