第一个问题：
问题是这样的，线上kafka集群设置ack=0，每隔一段时间，kafka集群某个broker（固定是这个broker出问题，非kafka controller节点）链接数会突然增大，从几千增加到几万，直到超过65535，然后broker挂掉，这个链接数增加的过程会持续几个小时。
出问题的broker会一直滚动报错，Too many open files。之前有一次，正好经历这个错误发生过程（这个错误过程很难预料，大多发生在半夜）通过观察到，涉事broker链接数在逐渐增加，与单个flume所在节点连接数就将近3000（大概8个flume加载点），与8个flume总的连接数就超过2w4，与此同时，其他broker报复制线程无法连接到该涉事broker。
更主要的是，一旦发生上述错误，flume将无法发送数据导致数据堆积。我现在无法确定是flume导致还是kafka导致的，现在kafka所使用的版本为0.10。是因为ack=0设置有问题吗？
上传不了图片，所以错误只能打字了。
第二个问题：
在broker挂掉重启后，该broker总会报ERROR
kafka.server.ReplicaFetcherThread:[ReplicaFetcherThread-xx-xxxx],Error for partition[topic,partition-id]:org.apache.kafka.common.errors.NotLeaderForPartitionException:This server is not the leader for that topic-partition。
这个错误会刷一会才正常，不知是什么原因？
1、ack=0是正常的，无需等待broker响应。
2、broker重启后，刷这些日志是正常的，在恢复。
第一个问题，我怀疑是flume新建的大量连接，你可以检查下连接到该broker节点的连接是来自哪里。
这些连接我看了ip，均来自flume所在服务器，从进程号也可以确认是与flume链接。
第一个问题，即使出问题的broker无法连接，topic分布在这个问题broker上的分区leader为-1，但为什么会导致所有数据均无法发送。关于第二个问题，为什么正常会刷这些错误呢？
很多旧连接并未及时关闭的情况下，flume新建了大量的新连接。
可以考虑换升级flume里的kafka客户端，或换成logstash。
我印象中当集群中的大部分节点失效了，无法发送新的消息，但是可以正常消费。
kafka客户端？是指kafka-client jar包吗？这个jar报已经和kafka版本一样了。
但是只有一个节点失效，其他broker均正常。
那就降client吧。降到0.8.2，用老的。
确实现在觉得kafka低版本很稳定。和一个大厂的人聊过，他说他们kafka集群版本很低，很稳定，一致没出过事。现在kafka升到最新反而总出毛病。
还有，您有没有关于详细介绍leader触发选举以及选举流程还有消费者管理机制方面的文章。如果有的话，放不方便提供下。
https://www.orchome.com/22 这里。
你的答案