1.概述

转载：http://791202.com/2020/02/01/bigdata/362/

2.详情

最近遇到一个问题，由于kafka集群升级导致每个broker.id出现了变动，但是topic的partition所在broker的信息依旧是原broker.id，这就造成了所有partition都丢失leader。

发现问题

通过kafka的命令发现topic的partition都没有leader，然后看了下集群监控和日志都没有明显的异常，但是日常显示的broker.id和通过kafka命令显示的有出入，进一步去zookeeper上查看了所有broker.id情况，发现是broker.id变了导致kafka controller无法通过partition依赖的broker.id找到对应的broker。

先说明一下自动生成broker.id的由来，kafka开启了broker.id.generation.enable，也就是自动生成broker.id功能，kafka在早期版本需要人为给每个broker分配一个broker.id，在server.properties配置里申明，从0.9.0版本开始，kafka支持并默认了自动生成broker.id功能。那么kafka是如何自动生成broker.id的呢？有一点是必须的，broker.id在这个kafka集群必须是全局唯一的，分布式下的全局唯一，那就联想到分布式锁了。kafka通过在zookeeper里写空字符串，触发该znode的版本自增，然后把获取的版本号和另一个配置reserved.broker.max.id相加，就得到了该broker节点的broker.id。

kafka查看topic所有partition依赖的broker，leader以及isr

kafka-topic.sh --describe --topic $topic --zookeeper $zkhost:port

zk查看当前kafka集群自增的broker序号

get /brokers/seqid

zk查看当前kafka集群所有的broker.id

ls /brokers/ids

zk查看topic所有partition的broker.id

get /brokers/topics/$topic

解决问题

手动删除错误broker.id的topic，删除完成后重启kafka集群