一. 简述：
当业务增加时，服务瓶颈，我们需要进行扩容。当业务量下降时，为成本考虑。自然也会涉及到缩容。假设集群有 15 台机器，预计缩到 10 台机器，那么需要做 5 次缩容操作，每次将一个节点下线，那么现在问题就是如何正确、安全地从 Kafka 集群中移除一台 broker？搞定这个之后，重复 5 次即可(也可以根据实际情况，一次多台)。
一个 broker 下线，它上面的所有 partition 都会处于副本不足的状态，并且 Kafka 集群不会在其它的 broker 上生成这些副本，因此，在将一个 broker 从集群中移除之前，需要将这个 broker 上的 partition 副本都转移到最终会保留的 10 台机器上，怎么实现这个呢？Kafka 自带的分区重分配工具。
在集群数据量较大的情况下，分区的转移可能会花费较长时间，那么在转移过程中最好不要创建新 topic，不然新的 topic 有可能又创建到要被移除的 broker 上，当然如果实在无法避免的话，可以再对新的 topic 进行一次额外的转移。
二. 缩容步骤：
需要先获取所有 broker 的 broker id，选择待移除的 broker。 使用 kafka-reassign-partitions 脚本将待移除 broker 上的 partition 均匀地转移到最终会留在集群的 broker 上。确认待移除 broker 上没有任何 partition 之后，在 对这个 broker 进行停止和删除。其中重点是 partition 的转移或者说重分配。
- 获取brokerID ：
可以通过管理工具，或者命令行，配置文件，都可以。 命令行的话：
./kafka-broker-api-versions.sh --bootstrap-server localhost:9092
工具的话，cmak ：
可以看到 broker list，broker id 分别为 141，142，145，146 ....
- 确定topic 数据量大小。
在重分区过程中，很耗节点资源的(cpu，内存，IO)，所以如果数据量大，需要按批次进行多次操作。如果没有监控指标的话， 可以通过配置文件中，log.dir查看具体数据路径。通过指令(du -sh )判断topic的数据存储大小。
- 重分区 (和扩容方式一样，也可以参考： kafka-集群扩容-CSDN博客 )：
将涉及到的topic，以json方式，写入临时文件：
{
"version": 1,
"topics": [
{
"topic": "topic1"
},
{
"topic": "topic2"
},
...
]
}
获取当前 partition 分配方案
使用 kafka-reassign-partitions 脚本的 --generate 来获取当前的 partition 分配方案。
# bin/kafka-reassign-partitions.sh --bootstrap-server logkafka-1:9092 --topics-to-move-json-file topics-to-move.json --broker-list "141,142,143。。。" --generate
将新的分配规则保存在json文件（例如，保存在 reassignment.json这个文件下）然后，用--execute选项来执行它：
bin/kafka-reassign-partitions.sh --bootstrap-server logkafka-1:9092 --reassignment-json-file reassignment.json --execute
可通过--verify 参数查看进度。
- 观察没问题后，直接下线空数据节点即可。
深耕运维行业多年，擅长linux、容器云原生、运维自动化等方面。
承接各类运维环境部署、方案设计/实施、服务代运维工作，欢迎沟通交流！
（V： xiaoxiangbj2013 ） ！
