点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
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
我们的配置：
- 创建一个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 • 1
显示的内容如下：
可以看到我们已经顺利的完成了重新分区分配！
实际应用中的分区设计与优化
在实际应用中，Kafka 分区的数量、分区副本因子、以及如何合理地重新分配分区，是保证 Kafka 集群高效运行的关键因素。
合理设置分区数量：分区数量不宜过多或过少，应根据系统的吞吐量需求和 Broker 的资源情况进行规划。
定期检查与调整：随着业务的发展，Kafka 集群的负载情况可能会发生变化，定期检查分区的分布情况，并根据需要进行调整，是保持系统稳定运行的重要手段。
