故障表现

线上多个sparkstreaming消费kafka时失败，报错信息：

User class threw exception: org.apache.kafka.common.errors.TimeoutException: Timeout of 60000ms expired before the position for partition xxx-20 could be determinedUser class threw exception: org.apache.kafka.common.errors.TimeoutException: Timeout of 60000ms expired before the position for partition xxx-20 could be determined

故障分析过程

起初怀疑是coordinator有问题，参考了一篇博客

(华为云社区:bbs.huaweicloud.com/blogs/28607…)

如果一个topic别的消费者没问题，只有这一个出问题，排查下coordinator。

kafka-consumer-groups.sh  --bootstrap-server x.x.x.x:21007  --describe  --group <groupid> --
command-config /opt/client/Kafka/kafka/config/consumer.properties

根据文中的过程我们排查了__consumer_offsets topic发现并没有分区异常。之后联系kafka那边的运维人员，发现有台机器请求队列阻塞

后续联系运维下掉机器维修，故障恢复。

故障原因分析

因为在 kafka 集群长时间运行中，broker 的宕机或崩溃是不可避免的，leader 就会发生转移，即使 broker 重新回来，也不会是 leader 了。在众多 leader 的转移过程中，就会产生 leader 不均衡现象，可能一小部分 broker 上有大量的 leader，影响了整个集群的性能，所以就需要把 leader 调整会最初的 broker 上，这就需要 preferred leader 选举。

故障机作为leader负载过大，切换到follower，之后负载降低，由于preferred leader选举机制，后续leader又会分配到这台机器上，导致每隔一段时间就会有大量请求阻塞。

auto.leader.rebalance.enable

是否开启leader自动平衡，默认值为true。后台会有线程进行定期检查leader的分布情况

kafka中有一个被称为优先副本（preferred replicas）的概念(通常分区会有主分区和副本分区的概念，主分区先写入，然后push到其他副本分区)。

如果一个分区有3个副本，且这3个副本的优先级别分别为0,1,2，根据优先副本的概念，0会作为leader 。

当0节点的broker挂掉时，会启动1这个节点broker当做leader。

当0节点的broker再次启动后，会自动恢复为此partition的leader。不会导致负载不均衡和资源浪费，这就是leader的均衡机制(前提是第一次partition在分配的时候，它本身就是一个相对平均的分配) 源浪费，这就是leader的均衡机制(前提是第一次partition在分配的时候，它本身就是一个相对平均的分配) 线上应该是开启了这个参数

#对应影响的其他两个参数
# leader.imbalance.per.broker.percentage : 每个broker允许leader不平衡比例(如果每个broker上超过了这个值，controller将会>执行分区再平衡)，默认值10.
# leader.imbalance.check.interval.seconds: 主分区再平衡的频率，默认值为300s