kafka的一个有趣问题（BUG）

这是我的第104篇原创文章

问题由来

在使用kafka时，创建topic，对某个topic进行扩分区的操作，想必大家肯定都使用过。尤其是集群进行扩容时，对流量较大的topic进行扩分区操作。一般而言，期望的效果是：新扩的分区分布到新的broker节点上，这样才能达到均衡流量分摊broker压力。

然而，我们在实际使用过程中发现，在一种场景下，原生的代码逻辑中，对topic分区进行扩容后，新增的分区并没有分配到新的节点上，即新增的分区和老的分区仍旧位于扩容前的broker节点上，导致这个节点压力反而变大，引发生产者发送超时等问题，本文就这个问题进行分析。

问题产生的步骤

我们先来看下问题出现的操作步骤与现象，在具有3个broker的集群环境中，分别通过自带脚本（kafka-topics.sh）和adminClient的接口创建一个分区数为2、副本因子为1的topic，然后再扩容到3分区，此后查看topic分区的分布情况。

通过接口操作的情况如下所示：

通过脚本操作的情况如下所示：

从图中可以直观的看到通过接口创建的topic，在扩容分区后，新增的2号分区的leader与老的1号分区的leader位于同一个broker节点上，而不是像脚本操作的一样，3个分区的leader分别位于3个broker节点上。

两种操作方式的区别

由于扩分区的操作都是一样的，那为什么不同的创建的方式，在进行扩容后就有了不同的结果呢？我们还是先来看下两种创建topic方式的逻辑。

对于通过脚本创建topic的处理逻辑为：

• 通过zk客户端获取当前集群的所有broker

• 根据