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

🚀 AI 篇持续更新中！（长期更新）

AI 炼丹日志-31- 千呼万唤始出来 GPT-5 发布！“快的模型 + 深度思考模型 + 实时路由”，持续打造实用 AI 工具指南！📐🤖

💻 Java 篇正式开启！（300 篇）

目前 2025 年 08 月 11 日更新到：Java-94 深入浅出 MySQL EXPLAIN 详解：索引分析与查询优化详解 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解

章节内容

上一节我们完成了如下的内容：现实业务中我们会遇到：当 Kafka 集群中有一个节点宕机了，比如 Broker0、Broker1 中，Broker1 宕机了，此时由于我们配置了副本数为 2，Kafka 集群正常工作，提供生产和消费能力。但是当我们修好 Broker1 之后，恢复宕机之后，发现 Leader 都是 Broker0，不会再平衡到 Broker1 上，所以我们需要用脚本来让 Kafka 集群进行自动再平衡。

• Kafka 自动再平衡

• 新建主题

• 查看主题

• 模拟宕机

• 重启节点

• 编写 JSON

• 测试运行

分区（Partition）

Kafka 中的每个主题（Topic）都可以分为多个分区。分区是 Kafka 实现可扩展性和高吞吐量的关键机制，它通过以下方式提升系统性能：

1. 并行处理能力：分区允许消息被并行处理，不同的分区可以由不同的消费者同时处理，从而提高整体吞吐量。

2. 数据分布：每个分区可以分布在不同的服务器（Broker）上，实现数据的分布式存储和处理。

3. 水平扩展：通过增加分区数量，可以线性提升主题的吞吐量。

每个分区可以看作是一个有序的、不可变的消息队列，具有以下核心特性：

• 消息顺序性保证：消息在分区内严格按写入顺序进行存储，并且每个消息都会分配一个唯一的递增偏移量（Offset）。这种设计保证了同一分区内的消息顺序性，但不同分区之间的消息顺序则无法保证。

• 持久化存储：分区中的消息会被持久化到磁盘，并可以根据配置的保留策略（retention policy）保留一定时间（如 7 天）或达到一定大小。

• 副本机制：每个分区可以有多个副本（Replicas），其中一个作为领导者（Leader）负责处理读写请求，其他作为跟随者（Follower）用于故障转移。

应用场景示例：

• 电商订单处理系统可以将不同用户的订单分配到不同分区，既保证同一用户订单的顺序处理，又实现系统的水平扩展。

• 日志收集系统可以按日志来源设备 ID 进行分区，确保同一设备的日志顺序性。

实际操作中，创建主题时就需要指定分区数量（如bin/kafka-topics.sh --create --topic my_topic --partitions 3），后续虽然可以增加分区数，但需要谨慎操作以避免影响现有消息的键到分区映射。

分区优势

• 并行处理：通过将主题分为多个分区，Kafka 可以在多台服务器上并行处理消息，从而提高系统的吞吐量。

• 负载均衡：消费者组中的不同消费者可以消费不同的分区，从而实现负载均衡。

• 水平扩展：当需要处理更多的消息时，可以通过增加分区来扩展 Kafka 集群的容量。

副本因子（Replication Factor 或者 Replicas）

副本因子是 Apache Kafka 中一个重要的配置参数，它定义了每个分区在 Kafka 集群中的副本数量。这个参数决定了数据在集群中的冗余程度和系统的高可用性。

副本的角色与职责

每个分区的副本由以下两种角色组成：

1. 首领副本（Leader）

• Leader 是分区的主要副本，承担着核心的数据处理职责

• 负责处理所有客户端的读写请求（包括生产者和消费者的请求）

• 维护 ISR（In-Sync Replicas）列表，跟踪哪些 Follower 处于同步状态

• 当有新的消息写入时，Leader 会将这些消息同步给 Follower 副本

• 示例：假设一个分区有 3 个副本（副本因子为 3），其中 1 个是 Leader，2 个是 Follower

2. 追随者副本（Follower）

• Follower 是 Leader 的备份副本，主要用于数据冗余和故障恢复

• 定期从 Leader 拉取消息保持数据同步（这个过程称为"fetch"操作）

• 正常情况下不直接处理客户端的任何请求

• 在 Leader 失效时，通过 Kafka 的控制器（Controller）选举机制，其中一个 Follower 会被提升为新的 Leader

• 示例：在网络分区或节点故障时，Follower 可以接管成为 Leader，确保服务不中断

副本因子的重要性

合理的副本因子设置需要考虑：

• 数据可靠性需求（副本越多，数据丢失风险越低）

• 集群资源开销（每个副本都需要存储空间和网络带宽）

• 读写性能影响（副本同步会带来一定的延迟）

典型的生产环境配置：

• 开发环境：副本因子=1（无冗余）

• 测试环境：副本因子=2（基本冗余）

• 生产环境：副本因子=3（高可用性配置）

副本同步机制

Kafka 使用 ISR（In-Sync Replicas）机制来管理副本同步：

1. Leader 维护一个 ISR 列表，包含所有与 Leader 保持同步的副本

2. 只有 ISR 中的副本才有资格在 Leader 失效时被选举为新的 Leader

3. 如果 Follower 长时间未同步（超过replica.lag.time.max.ms参数设置的时间），会被移出 ISR 列表

这种机制确保了在故障转移时，新选举的 Leader 拥有最新的数据。

副本因子作用

• 容错性：副本因子提供了容错能力。当一个节点发生故障时，Kafka 可以通过选举新的 Leader 来保证数据的可用性。

• 高可用性：即使集群中的部分节点不可用，Kafka 依然能够确保数据的可用性和持久性。

• 副本因子的选择：副本因子通常设置为 3，这意味着每个分区有 3 个副本。这样即使有一个副本节点宕机，系统仍然能保证数据的安全性和服务的连续性。

工作原理

在 Kafka 中，当一个消息写入到某个分区时，首先会写入到该分区的 Leader 副本中，然后 Leader 会将该消息同步到所有的 Follower 副本。当所有的 Follower 都成功同步后，该消息才被认为是提交成功的（即对消费者可见）。

通过分区和副本因子，Kafka 实现了数据的高可用性和高性能处理能力。在实际应用中，合理配置分区和副本因子对于 Kafka 集群的性能和稳定性至关重要。

修改分区副本的详细操作指南

业务背景与需求场景

在实际业务和项目开发过程中，我们经常会遇到需要调整 Kafka 主题(Topic)副本因子(replication factor)的情况。以下是几种典型场景：

1. 初始配置不足：新创建主题时可能低估了数据重要性，设置过小的副本因子(如 1)，随着业务发展需要增加冗余保障

2. 集群扩容：当 Kafka 集群规模扩大后，需要将原有主题的副本分布到新增节点上，充分利用集群资源

3. 故障容灾：发现某些主题数据丢失风险较高，需要提高容错能力

4. 性能优化：通过增加副本改善消费者读取性能，特别是跨地域部署场景

技术实现方案

由于生产环境中主题通常承载着关键业务数据，简单的删除重建方式不可行，因此需要通过 Kafka 提供的动态修改机制来完成：

详细操作步骤

1. 创建副本分配计划文件：

   {     "version": 1,     "partitions": [       {"topic": "your_topic", "partition": 0, "replicas": [0, 1, 2]},       {"topic": "your_topic", "partition": 1, "replicas": [0, 2, 3]},       {"topic": "your_topic", "partition": 2, "replicas": [1, 2, 3]}     ]   }

其中 replicas 数组应包含新的副本列表，包含原有副本加上新增副本

2. 执行副本重新分配：

   bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 \   --reassignment-json-file increase-replication-factor.json \   --execute

3. 验证分配进度：

   bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 \   --reassignment-json-file increase-replication-factor.json \   --verify

注意事项

1. 性能影响：副本重分配会引发大量数据传输，建议在业务低峰期操作

2. 监控指标：操作期间需密切关注以下指标：

3. 网络吞吐量

4. 磁盘 IO 使用率

5. 集群负载均衡情况

6. 回滚方案：提前准备回滚计划，包括：

7. 原有副本分配配置备份

8. 快速终止重分配的操作命令

9. 客户端适配：某些客户端可能需要重启才能感知新的副本分布

最佳实践建议

1. 预生产验证：在测试环境充分验证重分配方案

2. 分批次操作：对于大型集群，建议分批次处理不同主题

3. 文档记录：详细记录变更前后的配置和验证结果

4. 自动化工具：考虑使用 Ansible、Chef 等工具实现标准化操作流程

通过以上方法，可以在不影响业务连续性的前提下，安全地完成 Kafka 主题副本因子的动态调整。

背景情况

假设我们有两个 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是1kafka-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 中有一台节点挂掉了，我们也可以继续进行消费！