博主，你好：
目前遇到一个问题就是一台kafka节点重启的时候如下的异常：
这个异常是在controller日志里面显示的，表示是在更新broker节点元数据的时候，连接失败。
目前由于开启了auto.leader.rebalance.enable，所以在重启节点的时候，就会出现某些分区数据少，先同步完，然后进行leader的切换。切换完成以后客户端就会来连接当前的broker。但是由于controller在更新这台节点元数据的时候是没有更新成功的，就会导致元数据不一致，客户端读写数据失败问题。
同时在broker的日志里面可以看到如下异常：
目前尝试调整network,io,fetcher等线程数量，但是没有作用。
博主是否有遇到过这样的异常
即使某个kafka节点持续down机，也不该影响你的生产与消费。
这些信息，只是当前broker从故障到恢复的状态日志，并不是重要。
所以，topic的副本数量和分布决定了你的读写，应该关注分区副本的高可用。
如果数据量特别庞大，某个border宕机时间比较久，恢复的时间周期就很长（追赶）。
博主，你好：现在是这样。
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流来说，这种问题就会导致流断。
你这么描述，这就是kafka的bug了，如果broker没有恢复成功，是不会选成leader的呀。
broker是已经恢复了，毕竟都已经被controller管控了，只是分区数据不一样，同步时间不一样，leader的选举时间点也不一样。controller在更新集群元数据的时候，更新失败了，其实从重启的这个broker日志：Remote broker is not the leader for partition xxx,说明集群元数据与当前节点元数据是不一致的。
kafka新启的broker首先要变成
isr，才有资格成为leader。可以看下：kafka副本和leader选举
bin/kafka-topics.sh --describe --zookeeper 127.0.0.1:2181看下报错topic分区副本情况，观察下broker恢复期间的变化。
你的答案