Kafak-扩容节点（Broker）和分区（Partition）

运维小路

发布于 2025-06-08 14:01:29

3900

代码可运行

文章被收录于专栏：运维小路运维小路

运行总次数：0

代码可运行

我们上一章介绍了中间件：Zookeeper，本章将介绍另外一个中间件：Kafka。目前这2个中间件都是基于JAVA语言的。

在一般的中小集群，我们如果前期的配置如何合理的情况下，是不太让容易出现需要扩容的问题。但是由于前期配置不合理或者架构调整（单AZ扩到多AZ），则需要经过调整配置。下面我们将模拟扩容操作。

前面是3个节点，我们这里增加了2个节点，模拟扩容Broker，然后再扩分区。如果前期我们配置的3副本，则副本是不需要扩容的。这里我们并没有考虑跨AZ（可以通过机架感知参数来实现）。

broker.rack=az2  # Broker 4
broker.rack=az2  # Broker 5

1.环境准备

同操作系统，同版本JDK，同版本Kafka，再确认网络互通。

2.配置

broker.id和其他区分开来，我们一般开始0，1，2，3，4，5这样,所以新加的节点的就是4和5。

# The id of the broker. This must be set to a unique integer for each broker.
broker.id=4
#换成本机的ip地址
listeners=PLAINTEXT://192.168.31.147:9092
#zk地址，也参考其他节点配置即可 
zookeeper.connect=192.168.31.143:2181/kafka

当两个Kafka节点启动以后，节点就算添加成功，但是这个时候这个节点是没有任何数据的。和我们前面提到的在Kafka的集群是以Topic的分区来实现，所以我们还需要对分区进行操作。

默认情况下，Kafka 使用 ReplicaAssignmentStrategy 来决定如何分配副本。我这个时候是新扩容Topic它也不会使用新的Broker，仅考虑创建 Topic 时集群中的 Broker，不会动态感知后续新增的 Broker。

bin/kafka-topics.sh \
--alter \
--bootstrap-server 192.168.31.143:9092 
--topic new-topic1 
--partitions 5

可以看到下面的分区，从3个分区扩容到5个分区，但是还是还是使用原先的3个Broker节点，并未使用新的Broker节点。

这个时候，我们手工控制分片，下面的文件就是我们手工指定某个Topic的分区，我们通过设置副本id，来实现使用其他几个节点（0，1，2是以前的3个broker节点，3，4则是后面扩容的2个节点）。

{
  "version": 1,
  "partitions": [
    {"topic": "new-topic1", "partition": 0, "replicas": [0, 1, 2]},
    {"topic": "new-topic1", "partition": 1, "replicas": [1, 2, 3]},
    {"topic": "new-topic1", "partition": 2, "replicas": [2, 3, 4]},
    {"topic": "new-topic1", "partition": 3, "replicas": [3, 4, 0]},
    {"topic": "new-topic1", "partition": 4, "replicas": [4, 0, 1]}
  ]
}

然后我们使用Kafka自带的脚本，来实现扩容

[root@localhost kafka_2.13-2.8.2]# bin/kafka-reassign-partitions.sh \
>   --bootstrap-server 192.168.31.143:9092 \
>   --reassignment-json-file reassignment.json \
>   --execute
OpenJDK 64-Bit Server VM warning: If the number of processors is expected to increase from one, then you should configure the number of parallel GC threads appropriately using -XX:ParallelGCThreads=N
Current partition replica assignment
{"version":1,"partitions":[{"topic":"new-topic1","partition":0,"replicas":[2],"log_dirs":["any"]},{"topic":"new-topic1","partition":1,"replicas":[1],"log_dirs":["any"]},{"topic":"new-topic1","partition":2,"replicas":[0],"log_dirs":["any"]},{"topic":"new-topic1","partition":3,"replicas":[0],"log_dirs":["any"]},{"topic":"new-topic1","partition":4,"replicas":[1],"log_dirs":["any"]}]}
Save this to use as the --reassignment-json-file option during rollback
Successfully started partition reassignments for new-topic1-0,new-topic1-1,new-topic1-2,new-topic1-3,new-topic1-4

下面就是扩容以后的，副本情况，Leader都还是在原来的节点，但是副本节点已经有新的节点，如果前面的节点宕机，则后面新扩容的可以当选Leader分区。