一、分区迁移的具体过程 #

Kafka的分区迁移由集群的控制器（Controller Broker）主导完成，核心步骤如下：

• 生成迁移计划：控制器依据集群负载、副本分布规则（如同一分区的副本不共存于同一Broker、副本在Broker间均匀分布），计算出待迁移的分区副本列表，明确原Broker、目标新Broker及副本角色（默认先作为follower）。
• 启动副本同步：控制器向新Broker发送指令，使其成为目标分区的follower副本；同时通知原分区的leader副本，开始向新follower同步日志。新follower先拉取leader的全量日志快照，之后持续同步增量数据，直到两者日志的偏移量（offset）完全一致。
• 副本角色切换（若涉及leader迁移）：当新follower同步完成并处于in-sync状态后，控制器触发leader选举，将新Broker上的副本提升为leader。这个切换过程耗时极短，仅存在微秒级的不可用窗口。
• 清理旧副本：待新副本稳定运行后，控制器指令原Broker删除该分区的旧副本数据，完成迁移流程。

二、数据传输协议 #

分区迁移时的数据传输使用Kafka内部副本同步协议（Replica Fetch Protocol），和日常副本间的同步逻辑完全一致：

• 基于TCP协议传输，由新follower主动向leader发起FetchRequest请求；
• leader返回指定offset范围的日志数据，保证数据的顺序性和可靠性；
• 整个传输过程后台异步进行，不会占用业务读写的专用通道。

三、对并发读写/消费的影响 #

迁移过程对业务的影响极小，具体分场景来看：

• 写操作：仅在leader副本切换的瞬间，会出现极短暂的LeaderNotAvailable错误，但Kafka客户端会自动重试，业务几乎无感知；若仅迁移follower副本，写操作完全不受影响（写请求仅发送到leader，同步到follower是后台异步流程）。
• 读/消费操作：默认情况下读请求仅发送到leader副本，影响和写操作一致；若开启了副本读取（消费者配置replica.selector.class），只要被读取的follower处于in-sync状态，消费也不会受影响，仅在leader切换瞬间有短暂重试。

内容的提问来源于stack exchange，提问作者Jim