项目场景：

项目中，向kafka集群中生产消息，由下游系统进行消费处理。

问题描述：

在项目实际应用过程中，发现经常性的出现异常：

原因分析：

根据报错内容可知，发送消息时，broker已经不是对应分区的leader了，也就是说问题发生在leader重选举时，由于报错相对比较频繁，即重选举的动作发生的比较频繁，所以问题的重点就是分析是什么原因导致了leaderf发生了重选举。
关于kafka的leadert重选举以及都有哪些情况可能触发重选举，这里不在详细说明，具体可以参考：https://szzdzhp.blog.csdn.net/article/details/122455703，博主博文中介绍的很详细，现在我们结合实际来分析可能原因：
1、 因为是经常发生，所以首先想到的就是自动定时执行优先副本选举任务这个场景，但是经过对kafka集群及zk集群的日志内容进行排查，发现出现报错的时间并不是很有规律的，故排除了这个可能（排查时是先看的日志，实际上这个可以先看集群相应配置是否启用，在考虑是或否由此原因导致）
2、 由于是生产环境，并且集群及topic并未发生改动，而重选举发生频率较高，由此可排除一些固定因素，大致可猜测确定为由kafka的controller的相关动作引起的，而日志中的内容恰好也证明了这一点：

Broker连接zk的session超时导致 Controller挂掉重新选举，也即是leader的重选举
3、 那么对于超时的原因，大致可猜测几点：比如网络波动、机器的Full GC、磁盘IO压力大等原因，最后根据kafka的gc日志以及实际情况，排除前两种，大致猜测为磁盘IO压力大，同时kafka-eagle的监控也一定程度上证明了这一点：

由此确定此问题大概率为磁盘IO压力大,某时刻处于IO峰值时导致集群发生broker与zk的连接session短暂超时，从而引发controller挂掉触发重选举，并且达到这个界限的情况较为频繁发生。

解决方案：

我们可以围绕上述原因进行思考解决方案：
1、 既然是超时，那么我们可以考虑尝试增大超时时间（具体数值请根据实际情况）：
zookeeper.session.timeout.ms = 30000
或zookeeper.connection.timeout.ms = 30000
2、 IO压力大，我们可以增大磁盘IO线程数（具体数值请根据实际情况）：
num.io.threads =12
3、 或者增加log磁盘数(具体数值请根据实际情况）:
log.dirs= 路径1,路径2,路径3…

上述三种方案可按照实际情况，酌情采纳。
分析及解决方案参考，博主写的还是很清楚的：https://blog.csdn.net/jiecxy/article/details/53369173
解决方案缺陷：由于解决方案中所述，三个配置全都是broker的server.properties的属性配置，如果进行调整，均需要进行机器重启，并且由于是处于生产环境，由此需要考虑相关的影响

其他

问题排查记录，以上如有不准确的还望指正，期待与大神们一起学习研究~