点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka（正在更新…）
章节内容
上一节我们完成了如下的内容：
现实业务中我们会遇到：当Kafka集群中有一个节点宕机了，比如Broker0、Broker1中，Broker1宕机了，此时由于我们配置了副本数为2，Kafka集群正常工作，提供生产和消费能力。
但是当我们修好Broker1之后，恢复宕机之后，发现Leader都是Broker0，不会再平衡到Broker1上，所以我们需要用脚本来让Kafka集群进行自动再平衡。
Kafka自动再平衡
新建主题
查看主题
模拟宕机
重启节点
编写JSON
测试运行
分区（Partition）
Kafka 中的每个主题（Topic）都可以分为多个分区。分区是 Kafka 实现可扩展性和高吞吐量的关键机制。每个分区可以看作是一个有序的消息队列，消息在分区内按写入顺序进行存储，并且每个消息都会分配一个唯一的偏移量（Offset）。
分区优势
并行处理：通过将主题分为多个分区，Kafka 可以在多台服务器上并行处理消息，从而提高系统的吞吐量。
负载均衡：消费者组中的不同消费者可以消费不同的分区，从而实现负载均衡。
水平扩展：当需要处理更多的消息时，可以通过增加分区来扩展 Kafka 集群的容量。
副本因子（Replication Factor 或者 Replicas）
副本因子表示每个分区在 Kafka 集群中的副本数量。每个分区的副本包括一个首领副本（Leader）和多个追随者副本（Follower）。
Leader：Leader 是分区的主要副本，负责处理所有的读写请求。
Follower：Follower 是 Leader 的备份副本，它们会同步 Leader 的数据，但不会直接处理客户端的请求。只有当 Leader 出现故障时，Follower 才会成为新的 Leader。
副本因子作用
容错性：副本因子提供了容错能力。当一个节点发生故障时，Kafka 可以通过选举新的 Leader 来保证数据的可用性。
高可用性：即使集群中的部分节点不可用，Kafka 依然能够确保数据的可用性和持久性。
副本因子的选择：副本因子通常设置为 3，这意味着每个分区有 3 个副本。这样即使有一个副本节点宕机，系统仍然能保证数据的安全性和服务的连续性。
工作原理
在 Kafka 中，当一个消息写入到某个分区时，首先会写入到该分区的 Leader 副本中，然后 Leader 会将该消息同步到所有的 Follower 副本。当所有的 Follower 都成功同步后，该消息才被认为是提交成功的（即对消费者可见）。
通过分区和副本因子，Kafka 实现了数据的高可用性和高性能处理能力。在实际应用中，合理配置分区和副本因子对于 Kafka 集群的性能和稳定性至关重要。
修改分区副本
现实业务中与实际项目中，我们可能由于主题的副本因子设置问题，需要重新设置副本因子。
由于集群的扩展，需要重新设置副本因子。
Topic一旦使用又不能轻易删除重建，因此动态增加副本因子就成为最终的选择。
背景情况
假设我们有两个KafkaBroker分别为：Broker0、Broker1
当我们创建Topic有2个分区，并且replication-factor为1，基本一个Broker一个分区。
当一个分区宕机了，该Topic就无法使用了，因为两个分区中只有一个可以使用
当我们创建的Topic有3个分区时，replication-factor为2时，可能分区数据分布情况是：[broker0,partition0,partition1,partition2] 和 [broker1,partition1,partition0,partition2]
每个分区有一个副本，当其中一个Broker宕机了，Kafka集群还能完整的凑出该Topic的两个分区，例如当Broker0宕机了，可以通过Broker1组合出Topic的两个分区。
启动服务
确保你有两台节点是可以正常使用的：
我这里是h121和h122
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties • 1
h121
h122
创建主题
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --create --topic topic_test_02 --partitions 3 --
运行结果如下图：
查看主题
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_02
运行结果如下图：
可以看到跟我们的上一个实验的开头分配情况是一致的。
修改副本因子（不允许）
尝试修改
# 刚才 --create的时候 --replication-factor是1 kafka-topics.sh --zookeeper h121.wzk.icu:2181 --alter --topic topic_test_02 --replication-fa
我们可以观察到，是不允许我们这样操作的：
那如果我们业务上要求我们修改副本因子，我们该怎么办呢？
下面提供一个可行的方案。
修改副本因子
编写JSON
所以我们需要借助 kafka-reassign-partitions.sh
新建一个文件，这里的JSON在replicase里写入了多个：
vim topic_test_02_increment-replication-factor.json { "versions": "1", "partitions": [ { "topic": "topic_test_02", "partition": 0, "replicas": [0,1] }, { "topic": "topic_test_02", "partition": 1, "replicas": [0,1] }, { "topic": "topic_test_02", "partition": 2, "replicas": [1,0] } ] }
我们写入的内容如下：
执行JSON
kafka-reassign-partitions.sh --zookeeper h121.wzk.icu:2181 --reassignment-json-file topic_tes
观察执行的结果如下：
查看结果
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_02
执行的结果如下图所示：
可以看到，我们的副本数已经是 01、01、10了，此时就算 h121 或者 h122 中有一台节点挂掉了，我们也可以继续进行消费！
