Kafka报 IO Exception(many open files)

1 线上问题

kafka报错many open files，查看日志如下截取部分错误信息

2 问题分析

首先看kafka监控平台的一些监控指标，topic列表中关于topic的信息项如下所示：

（1）topic名称，Partitions分区数，该topic 队列分布的broker数量

（2）Brokers Spread %：该topic中队列在Broker中的使用率，例如集群中有5个broker，但topic只在４个broker上创建了队列，那使用率为80％

（3）Brokers Skew %：topic的队列倾斜率。如果集群中存在5个broker节点，topic的总分区数量为4,副本因子为2，但这些队列只分布在其中的４台broker中，那topic的broker使用率(Broker Spread)为80%。

引入多节点的目的就是负载均衡，队列在broker中的分配自然是希望越均衡越好，期望每台broker上存储2个队列(副本因子为2，总共８个队列)，表示没有发生倾斜，如果一台broker中的存在３个队列，而另外一个broker上１个队列，那说明发生了倾斜，计算公式为超过平均队列数的broker节点个数除以总所在Broker数量，其Brokers Skew等于(1/3)=33%。

（4）Brokers Leader Skew %：topic分区中Leader分区的倾斜率。在Kafka中，只有分区的Leader节点具有读写权限，真正影响性能读写性能的是Leader分区是否均衡，试想一下，如果一个topic有6个分区，但所有的Leader分区只分布在一两个Broker节点上，这个topic的写入、读取性能将受到制约，这个值建议维持在0％

（5）Replicas：副本数、副本因子，即一个分区数据存储的份数，该数值包含Leader分区。

（6）Under Replicated %：没有跟上复制进度的副本比例，在Kafka的复制模型中，主分区负责读写，该复制组内的其他副本从主节点同步数据，如果跟不上主节点的复制进度，将被提出ISR，被剔除ISR的副本不具备选举Leader的资格，这个数据如果长期或频繁高于0，说明集群一定出现了问题。

经过对Topic列表观察，发现开发环境存在大量的topic都只有一个队列，并且都分布在第一节点上，其截图如下：

在这里插入图片描述

从界面上对应的指标：Brokers Spread即Broker的利用率只有３分之一，抽取几个数据量大的主题，判断其路由信息，得知都分布在第一个Broker节点上，这样就导致其中一个节点大量出现文章开头部分提到的错误：Too many open files。

3.解决方案

（1）扩分区

问题定位出来了，由于Broker利用率不均匀，大量topic只创建了一个队列，并且还集中落到了第一个节点。

针对这种情况，首先想到的方案：扩分区。

（2）分区移动

由于存在大量的只有一个分区的topic，并且这些topic都分布到了第一个节点，是不是可以将某些topic的分区移动到其他节点呢？

准备需要执行迁移的topic信息，例如将如下信息保存在文件dw_kafka_040802-topics-to-move.json中。

{"topics":[{"topic":"dw_kafka_040802"}],"version": 1

}

使用kafka提供的kafka-reassign-partitions.sh命令生成执行计划

4. 分区进行迁移是否影响业务正常使用

作为一名运维人员，特别是对中间件做变更时，考虑对业务的影响范围是必备的一步，直接影响到实施的复杂度。

从源码实现机制分析：

只有在Leader选举期间会对消息发送、消息消费造成影响，但通过Zookeeper实现Leader选举可在秒级别响应，结合Kafka消息发送端的缓冲队列、重试机制，

在理论上可以做到对业务无影响