大数据-64 Kafka 高级特性 分区Partition 分区重新分配 实机实测重分配 原创

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

• Hadoop（已更完）
• HDFS（已更完）
• MapReduce（已更完）
• Hive（已更完）
• Flume（已更完）
• Sqoop（已更完）
• Zookeeper（已更完）
• HBase（已更完）
• Redis （已更完）
• Kafka（正在更新…）

章节内容

上节我们完成了如下的内容，基本都是特性概念相关的：

• 分区相关介绍
• 副本机制
• 同步节点
• 宕机恢复
• Leader选举 基础概念、选举过程、为何不少数服从多数

Kafka 分区（Partition）概念

Kafka 分区是 Kafka 中一个非常核心的概念。每个 Kafka 主题（Topic）都可以被划分成多个分区。分区使得 Kafka 能够横向扩展，并提高数据的处理能力。

什么是分区

• 分区的作用：Kafka 通过将消息分发到多个分区中，实现数据的并行处理。每个分区都是一个有序的消息队列，消息在分区内按照写入的顺序存储，并且每条消息都具有唯一的偏移量（Offset）。
• 数据分布：分区可以分布在不同的 Kafka Broker 上，这使得 Kafka 可以通过增加分区数来扩展集群的吞吐量。

分区的优势

• 并行处理：多个分区可以在多个 Broker 上处理，消费者组内的多个消费者可以分别消费不同的分区数据，从而实现并行处理，提升系统的吞吐量。
• 容错性：每个分区可以有多个副本（Replicas），即使某个 Broker 出现故障，只要有其他副本存在，系统仍然可以继续运行，确保数据的高可用性。

分区重分配

向已经部署好的Kafka集群里添加机器，我们需要从已经部署好的Kafka节点中复制相应的配置文件，然后把里边的 BrokerID 修改为全局唯一的，最后启动这个节点即可让它加入到现有的Kafka集群中。

分区重新分配（Partition Reassignment）

分区重新分配是 Kafka 中用于重新平衡分区在不同 Broker 之间的机制。它主要用于以下场景：

• Broker 增加或减少：当集群中增加或减少 Broker 时，需要重新分配分区，以便新的 Broker 承担部分负载或将分区从离线的 Broker 中迁移出来。
• 分区数据不均衡：如果某些 Broker 上的分区过多，而其他 Broker 上的分区过少，可以通过重新分配来平衡负载。

当前问题

新添加的Kafka节点并不会自动的分配数据，无法分担集群的负载，除非我们新建一个Topic。
在重新分布Topic分区之前，我们先来看看现在Topic的各个分区的分布位置。

启动服务

如果你的Kafka服务还未启动，需要先启动，再进行后续的测试实验。
我这里启动：

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

启动结果如下图：

创建主题

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --create --topic wzk_topic_test --partitions 5 --replication-factor 1

我们的配置：

• 创建一个5个分区的主题
• Kafka此时的算法会保证所有分区都分配到现有的Kafka代理节点上

创建的结果如下：

查看主题

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic wzk_icu_test

创建的结果如下图，可以观察到5个分区。

新增Kafka

在新的机器上部署Kafka服务，记得修改BrokerID。
刚才我们是单节点的，Kafka在 h121 节点上。

# 配置内容参考 h121 中的配置
# 但是注意要修改 BrokerID
vim config/server.properties

• h121 broker 1
• h122 broker 2
• h123 broker 3 （暂时还不配置3节点）

此时我们来到 h122 用如下的命令启动Kafka，我启动的是临时的，如果你有需要，请用守护方式启动。

# 环境变量别忘了配置
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

启动过程如下图：

查看集群

# 先进入ZK 在ZK中进行查看
zkCli.sh 
get /cluster/id

执行的过程是：

WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0] get /cluster/id
{"version":"1","id":"DGjwPmfLSk2OKosFFLZJpg"}

重新分区

我们使用Kafka自带的：kafka-reassign-partitions.sh 工具来重新发布分区，该工具有三种使用模式：

• generate模式，给定需要重新分配的的Topic，自动生成 reassign plan （不会自动执行）
• execute模式，根据指定的 reassign plan重新分配 Partition
• verify模式，验证重新分配Partition是否成功

生成JSON

vim wzk_icu_test_to_move.json

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

当前结果如下：

执行如下的脚本，来对分区进行配置：

kafka-reassign-partitions.sh --zookeeper h121.wzk.icu:2181 --topics-to-move-json-file wzk_icu_test_to_move.json --broker-list "0,1" --generate

观察控制台的结果：

执行计划

Proposed Partition Reassignment Configuration 下面生成的就是将分区重新发布到 Broker 1上的结果，我们将这些内容保存到 result.json 中

vim result.json

{"version":1,"partitions":[{"topic":"wzk_icu_test","partition":0,"replicas":[1],"log_dirs":["any"]},{"topic":"wzk_icu_test","partition":1,"replicas":[0],"log_dirs":["any"]},{"topic":"wzk_icu_test","partition":2,"replicas":[1],"log_dirs":["any"]},{"topic":"wzk_icu_test","partition":3,"replicas":[0],"log_dirs":["any"]},{"topic":"wzk_icu_test","partition":4,"replicas":[1],"log_dirs":["any"]}]}

运行后的写入情况如下：

我们继续执行：

kafka-reassign-partitions.sh --zookeeper h121.wzk.icu:2181 --reassignment-json-file wzk_icu_test_to_move_result.json --execute

显示结果如下，已经完成分区：

校验结果

kafka-reassign-partitions.sh --zookeeper h121.wzk.icu:2181 --reassignment-json-file wzk_icu_test_to_move_result.json --verify

显示结果如下：

重新查看分区情况

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic wzk_icu_test 

显示的内容如下：

可以看到我们已经顺利的完成了重新分区分配！

实际应用中的分区设计与优化

在实际应用中，Kafka 分区的数量、分区副本因子、以及如何合理地重新分配分区，是保证 Kafka 集群高效运行的关键因素。

• 合理设置分区数量：分区数量不宜过多或过少，应根据系统的吞吐量需求和 Broker 的资源情况进行规划。
• 定期检查与调整：随着业务的发展，Kafka 集群的负载情况可能会发生变化，定期检查分区的分布情况，并根据需要进行调整，是保持系统稳定运行的重要手段。