Kafka面试精讲 Day 14：集群扩容与数据迁移

【Kafka面试精讲 Day 14】集群扩容与数据迁移

在“Kafka面试精讲”系列的第14天，我们将深入探讨 Kafka 运维中最关键的操作之一：集群扩容与数据迁移。随着业务增长，原始 Kafka 集群可能面临磁盘不足、吞吐瓶颈或节点负载不均等问题，如何在不影响线上服务的前提下安全地扩展集群规模，并将数据平滑迁移到新节点，是每一位中高级工程师必须掌握的核心技能。

本篇文章将系统解析 Kafka 的副本重分配机制（Replica Reassignment）、分区迁移流程、kafka-reassign-partitions.sh 工具使用、ZooKeeper 与 KRaft 模式下的差异，结合真实生产案例与可执行代码示例，帮助你全面理解 Kafka 扩容背后的原理与最佳实践。这些内容不仅是面试中的高频考点，更是保障系统稳定演进的关键能力。

一、概念解析：什么是集群扩容与数据迁移？

在 Kafka 中，集群扩容指的是向现有集群中添加新的 Broker 节点，以提升整体存储容量、吞吐能力和容错性。而数据迁移则是指将原有 Topic 的分区副本从旧节点迁移到新节点的过程，目的是实现负载均衡和资源再分配。

核心术语说明：

💡 类比理解：可以把 Kafka 集群看作一个“快递分拣中心”，当订单量增加时，需要扩建仓库（扩容），并将部分包裹路由到新区域（数据迁移），整个过程不能中断派送。

二、原理剖析：数据迁移的底层实现机制

1. 数据迁移的基本流程

Kafka 的数据迁移通过三步完成：

1. 生成迁移计划（Generate Plan）
   • 使用工具自动生成或手动编写 JSON 文件，描述每个分区的新副本分布。
2. 执行迁移（Execute Reassignment）
   • Kafka 启动后台线程，Follower 从原副本拉取数据进行同步。
3. 验证结果（Verify Completion）
   • 检查所有副本是否已完成同步，确认迁移成功。

📌 迁移过程中，Producer 和 Consumer 不受影响，仍可正常读写。

2. 副本角色变化与同步机制

• 在迁移期间，目标 Broker 上会创建新的 Follower 副本；
• 该 Follower 通过 FetchRequest 从当前 Leader 拉取消息，追赶到最新 LEO；
• 当 ISR 中所有副本都同步完成后，Controller 更新元数据；
• 原副本被删除，释放磁盘空间。

3. Throttling 限流机制

为避免迁移占用过多网络带宽导致线上服务抖动，Kafka 提供了带宽限制功能：

✅ 实际操作中建议设置合理 throttle，如 --throttle 100 表示 100MB/s。

三、代码实现：关键操作示例

示例 1：使用 kafka-reassign-partitions.sh 自动生成迁移计划

# 步骤1：准备待迁移的 Topic 列表
cat > topics-to-move.json << EOF
{
  "version": 1,
  "topics": [
    { "topic": "orders" },
    { "topic": "logs" }
  ]
}
EOF

# 步骤2：生成候选分配方案（自动选择目标 Broker）
bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-broker1:9092 \
  --topics-to-move-json-file topics-to-move.json \
  --broker-list "101,102,103,104" \  # 新增 Broker ID
  --generate

输出示例：

Proposed partition reassignment configuration:
{"version":1,"partitions":[{"topic":"orders","partition":0,"replicas":[101,102],"log_dirs":["/kafka-logs","/kafka-logs"]}]}

📌 建议将输出保存为 reassignment-plan.json 用于后续执行。

示例 2：执行数据迁移并设置限流

# 步骤3：执行迁移（启用限流）
bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-broker1:9092 \
  --reassignment-json-file reassignment-plan.json \
  --throttle 100 \
  --execute

⚠️ 注意：首次运行后需等待一段时间再验证，否则可能误判未完成。

示例 3：验证迁移进度与完成状态

# 查看当前迁移进度
bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-broker1:9092 \
  --reassignment-json-file reassignment-plan.json \
  --verify

输出结果可能为：

Status of partition reassignment:
Reassignment of partition orders-0 is still in progress

待显示 completed 后方可继续下一步。

示例 4：清除限流配置（重要！）

迁移完成后必须清除 throttle，否则会影响正常副本同步：

# 清除 throttle 配置
bin/kafka-configs.sh \
  --bootstrap-server kafka-broker1:9092 \
  --entity-type brokers \
  --entity-name 101 \
  --alter \
  --delete-config leader.replication.throttled.rate,follower.replication.throttled.rate

对所有参与迁移的 Broker 执行相同操作。

示例 5：Java 代码调用 Admin API 实现自动化迁移（推荐生产使用）

import org.apache.kafka.clients.admin.*;
import org.apache.kafka.common.TopicPartition;

import java.util.*;

public class KafkaReassignment {
    public static void main(String[] args) throws Exception {
        Properties props = new Properties();
        props.put("bootstrap.servers", "kafka-broker1:9092");
        Admin admin = Admin.create(props);

        // 定义迁移映射：TopicPartition -> List<Broker ID>
        Map<TopicPartition, List<Integer>> reassignment = new HashMap<>();
        reassignment.put(new TopicPartition("orders", 0), Arrays.asList(101, 102));
        reassignment.put(new TopicPartition("orders", 1), Arrays.asList(102, 103));

        // 构建任务
        AlterPartitionReassignmentsResult result = admin.alterPartitionReassignments(reassignment);
        result.all().get(); // 等待提交成功

        System.out.println("数据迁移任务已提交，请通过 CLI 验证进度");

        admin.close();
    }
}

📌 优势：可集成到 CI/CD 或运维平台，实现可视化调度。

四、面试题解析：高频考点深度拆解

❓ 面试题 1：Kafka 如何实现集群扩容？会不会影响正在运行的服务？

✅ 结构化答题模板（PREP）

Point：Kafka 支持在线扩容，且不影响现有服务。

Reason：

• 扩容只需启动新 Broker 并加入集群（通过 broker.id 和 zookeeper.connect 或 KRaft 配置）；
• 数据迁移通过异步副本重分配完成；
• Producer/Consumer 基于元数据自动发现新节点；

Example：

• 使用 kafka-reassign-partitions.sh 工具迁移分区；
• 设置 --throttle 防止影响线上流量；
• 迁移完成后清除限流；

Point：整个过程零停机，体现了 Kafka 的高可用设计。

❓ 面试题 2：什么是 Preferred Replica？为什么要执行 Preferred Replica Election？

✅ 核心概念解释：

• Preferred Replica：分区副本列表中的第一个副本，通常作为初始 Leader。
• 当发生故障切换后，Leader 可能变为非 preferred 副本，导致负载不均。

Preferred Replica Election（优先副本选举） 的作用就是将 Leader 恢复为 preferred 副本，常用于以下场景：

• 集群扩容后希望恢复原始负载均衡；
• 故障恢复后重新优化访问路径。

# 触发所有 topic 的优先副本选举
bin/kafka-leader-election.sh \
  --bootstrap-server kafka-broker1:9092 \
  --all-topic-partitions \
  --election-type PREFERRED

✅ 生产建议：可在低峰期定期执行，避免长期偏离设计架构。

❓ 面试题 3：如果不设置 throttle，会发生什么问题？

✅ 风险分析表：

💡 回答技巧：强调“平稳过渡”的重要性，体现工程思维。

五、实践案例：生产环境中的扩容实战

案例 1：电商大促前紧急扩容

背景：某电商平台双十一大促前夕，监控显示 Kafka 集群磁盘使用率已达 85%，预计当天将突破 95%。

应对措施：

1. 新增 2 台高配 Broker（ID: 201, 202）；
2. 使用 kafka-reassign-partitions.sh 生成迁移计划，将 30% 的分区迁移到新节点；
3. 设置 --throttle 80 控制迁移速度；
4. 分批次迁移，每批间隔 2 小时，避免集中压力；
5. 迁移完成后执行 preferred-leader-election 恢复负载均衡。

结果：

• 集群总容量提升 40%；
• 大促当日峰值吞吐达 120 万条/秒，无异常；
• 迁移期间 P99 延迟稳定在 15ms 以内。

案例 2：未清除 throttle 导致副本同步缓慢

现象：某金融系统完成扩容后，发现部分 Follower 长时间处于 OSR 状态。

排查过程：

1. 检查 kafka.server:type=ReplicaManager MBean；
2. 发现 UnderReplicatedPartitions 持续大于 0；
3. 查看 Broker 配置：

   bin/kafka-configs.sh --describe --entity-type brokers --entity-name 101
   

4. 输出包含：

   leader.replication.throttled.rate = 104857600
   

5. 确认为迁移后未清除 throttle。

解决方案：

• 立即清除所有相关 Broker 的 throttle 配置；
• 监控 ISR 恢复情况。

✅ 经验总结：必须将“清除 throttle”纳入标准化运维 checklist。

六、技术对比：ZooKeeper vs KRaft 模式下的迁移差异

📊 结论：KRaft 架构下迁移更高效、延迟更低，是未来发展方向。

七、面试答题模板：如何回答“你们是怎么做 Kafka 扩容的？”

STAR-L 模板（Situation-Task-Action-Result-Learning）

• Situation：业务快速增长，原集群磁盘接近上限。
• Task：在不停机情况下完成扩容与数据迁移。
• Action：
  • 添加新 Broker；
  • 使用 Admin API 提交 reassignment 计划；
  • 设置 throttle 控制影响；
  • 迁移完成后清除限流并触发 preferred leader election；
• Result：成功扩容，服务无感知。
• Learning：必须规范操作流程，防止遗漏 throttle 清理。

八、总结与预告

今天我们系统学习了 Kafka 的 集群扩容与数据迁移机制，涵盖：

• 扩容流程与副本重分配原理
• kafka-reassign-partitions.sh 工具使用
• throttle 限流的重要性与清除时机
• Preferred Replica Election 的应用场景
• 生产环境中的典型问题与最佳实践

掌握这些知识不仅能让你从容应对面试官的技术追问，更能帮助你在实际项目中安全、高效地管理 Kafka 集群。

👉 明天我们将进入【Day 15：跨数据中心复制与灾备】，深入讲解 MirrorMaker 2 和 Multi-Cluster Replication（MCR）如何实现异地容灾与数据同步，敬请期待！

文末彩蛋：面试官喜欢的回答要点

✅ 高分回答特征总结：

• 能清晰描述迁移三步骤（generate → execute → verify）；
• 知道 throttle 必须手动清除；
• 理解 Preferred Replica 的意义；
• 提到 Admin API 可编程控制；
• 能结合生产案例说明注意事项；
• 不盲目说“直接改 metadata”，而是强调工具化与安全性。

参考资源推荐

1. Apache Kafka 官方文档 - Replica Assignment
2. Confluent 博客：Zero Downtime Kafka Cluster Expansion
3. KIP-455: Remove ZooKeeper Dependency

文章标签：Kafka, 集群扩容, 数据迁移, 副本重分配, throttle, 高可用, 运维, 面试精讲, Kafka Reassignment, 负载均衡

文章简述：本文深入讲解 Kafka 集群扩容与数据迁移的核心机制，涵盖副本重分配流程、throttle 限流配置、Preferred Replica 选举等关键知识点，结合 Shell 命令与 Java 代码示例，解析真实生产案例。帮助开发者掌握在线扩容的最佳实践，应对中高级岗位面试中的运维与架构设计难题。