坏脾气先森

bin/kafka-topics.sh --describe --zookeeper 127.0.0.1:2181

看下报错topic分区副本情况，观察下broker恢复期间的变化。

kafka新启的broker首先要变成isr，才有资格成为leader。
可以看下：kafka副本和leader选举

broker是已经恢复了，毕竟都已经被controller管控了，只是分区数据不一样，同步时间不一样，leader的选举时间点也不一样。controller在更新集群元数据的时候，更新失败了，其实从重启的这个broker日志：Remote broker is not the leader for partition xxx,说明集群元数据与当前节点元数据是不一致的。

你这么描述，这就是kafka的bug了，如果broker没有恢复成功，是不会选成leader的呀。

博主，你好：现在是这样。

1、当前所有的topic都是多分区，三副本。高可用已经保证。

2、节点不重启，确实不影响使用，但是这样确实是会导致集群不健康，毕竟挂了一台节点。

3、现在是想重启节点，由于每一个broker节点当中，分区副本多，数据量大，所以在启动节点的时候就出现大量数据同步的过程，并且配置了auto.leader.rebalance.enable=true，所以当这个节点呗controller管控的时候，那么contraller就会定时的进行首选副本的选举，所以这个时候contraller会把元数据信息发送给所有的broker，但是在发送给重启这台broker的时候，元数据发送失败，导致这个节点的元数据没有更新。但是集群其他节点的元数据已经更新完毕了。所以客户端在进行数据读取的时候，从正常节点它访问到某一个topicA的分区0，它的leader是在当前重启的这个节点(由于已经被contraller进行首选副本切换了)，但是去连接重启的这个broker的时候，由于这个节点的元数据并没有成功更新，它并不认为topicA的分区0的leader在当前重启的这个broker，而是任务leader是在其他broker，就导致数据读写失败，这对于spark流来说，这种问题就会导致流断。