大数据-66 Kafka 高级特性 分区Partition 副本因子Replication Factor replicas动态修改 线上动态修改副本数

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

目前已经更新到了：

• 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

h121

h122

创建主题

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

运行结果如下图：

查看主题

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-factor 2

我们可以观察到，是不允许我们这样操作的：

那如果我们业务上要求我们修改副本因子，我们该怎么办呢？
下面提供一个可行的方案。

修改副本因子

编写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_test_02_increment-replication-factor.json --execute

观察执行的结果如下：

查看结果

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

执行的结果如下图所示：

可以看到，我们的副本数已经是 01、01、10了，此时就算 h121 或者 h122 中有一台节点挂掉了，我们也可以继续进行消费！