https://www.hyperxu.com/2019/12/01/kafka-1/

生产环境的kafka集群扩容，是一个比较常见的需求和操作。然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后，自动将数据reblance到整个新集群中，因此这个过程需要我们手动分配。

分区重分配方案

扩容后的数据均衡，其本质就是对topic进行分区重分配，数据迁移的过程。
在执行分区重分配的过程中，对集群的影响主要有两点：

1. 分区重分配主要是对topic数据进行Broker间的迁移，因此会占用集群的带宽资源；
2. 分区重分配会改变分区Leader所在的Broker，因此会影响客户端。

针对以上两点，第一点可以在晚间业务低峰时操作，必要时还可以和业务沟通，临时缩短数据保存时间，加快迁移，减少带宽影响时间。
针对第二点，有两个方案：

1. 整个分配方案分成两个步骤：
   1）手动生成分配方案，原有分区Leader位置不改变，只对副本进行分区重分配；
   2）等待数据迁移完成后，再手动更改分区分配方案，目的是均衡Leader。
2. 直接用Kafka官方提供的分区重新分配工具生成分区重分配方案，直接执行分区重分配。

重分配方案分析

方案一

方案一理论对客户端影响最小，把整个分配方案分成了两个步骤，也就是将对集群的带宽资源与客户端的影响分开了，对过程可控性很高。但问题是，如果集群中的某些topic，比如有64个分区，3副本，共192个副本，就需要在保持原有分区Leader位置不变的情况下，手动均衡其余副本，这个人工步骤过度繁杂，稍微有一点偏差，就会造成副本不均衡。

方案二

针对方案二我特意去看了分区重分配的源码，并对其过程进一步分析。发现分区重分配的步骤是，将分区原有的副本与新分配的副本合并成一个新的副本集合，新分配的副本努力追上Leader的offset，最终加入ISR。待全部副本都加入ISR之后，就会进行分区Leader选举，选举完后删除原有副本。这里注意，由于是最后选举完成才删除原副本，所以重分配的过程中，日志存储量是会大幅增加的。具体细节我后续单独写一篇文章叙述。

根据以上分析，意味着在数据进行重分配过程中，Leader并没有发生变动，所以客户端不会阻塞，数据迁移完成后进行Leader选举时发生变更，生产者会及时拉取最新的元数据，并重新进行消息发送，影响并不大。

重分配步骤

其实官方文档关于集群扩容讲解很详细：Expanding your cluster ,整个过程分为三个步骤：获取kafka给出的建议分配方案、按照给出的分配方案执行分配、查看分配的进度以及状态。这三个步骤对应了kafka脚本提供的三个partition reassigment工具。

1. 生成需要执行分区重分配的topic列表json文件：

   1 2 3 4 5

   > cat topics-to-move.json {"topics": [{"topic": "foo1"}, {"topic": "foo2"}], "version":1 }

2. 使用kafka-reassign-partitions.sh脚本获取分配方案：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate 当前分区副本分配 {"version":1, "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2]}, {"topic":"foo1","partition":0,"replicas":[3,4]}, {"topic":"foo2","partition":2,"replicas":[1,2]}, {"topic":"foo2","partition":0,"replicas":[3,4]}, {"topic":"foo1","partition":1,"replicas":[2,3]}, {"topic":"foo2","partition":1,"replicas":[2,3]}] } 建议的分区重新分配配置 {"version":1, "partitions":[{"topic":"foo1","partition":2,"replicas":[5,6]}, {"topic":"foo1","partition":0,"replicas":[5,6]}, {"topic":"foo2","partition":2,"replicas":[5,6]}, {"topic":"foo2","partition":0,"replicas":[5,6]}, {"topic":"foo1","partition":1,"replicas":[5,6]}, {"topic":"foo2","partition":1,"replicas":[5,6]}] }

   保存当前分区副本分配情况，用作回滚操作用。保存建议的分区重新分配配置到expand-cluster-reassignment.json用于执行迁移。

3. 执行重分配，并验证。

   1 2 3 4 5 6 7 8 9 10

   > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --execute > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --verify Status of partition reassignment: Reassignment of partition [foo1,0] completed successfully Reassignment of partition [foo1,1] is in progress Reassignment of partition [foo1,2] is in progress Reassignment of partition [foo2,0] completed successfully Reassignment of partition [foo2,1] completed successfully Reassignment of partition [foo2,2] completed successfully

   is still in progress表示还在处理中，全部迁移成功后每个partition都会显示completed successfully。注意如果topic数据量大，这个过程可能会很长，在此期间不要进行敏感操作，可能会导致数据不一致。

自定义重分配

分区重新分配工具还可以将分区的副本移动到指定的一组broker。只需自定义修改分配配置文件，后续步骤同上。

例如，以下示例将topic foo1的分区0移到broker5,6中和将topic foo2的分区1移到broker2,3中：

json