集群迁移时重新分区后Kafka消费者行为及相关技术疑问

1. 重新分区后消费者能否从源集群中断位置继续消费？ #

是的，这种情况下消费者无法直接复用源集群的__consumer-offsets数据继续消费。因为Offset是分区内的位置标识，重新分区后目标集群的分区数量、分区键的哈希映射逻辑都发生了变化，源集群的Offset与目标集群的消息完全没有对应关系。哪怕是相同的消息，在目标集群的分区和Offset位置都不一致，直接使用源集群的偏移量会导致消费位置错乱，要么重复消费大量消息，要么丢失消息。

2. Replicator的时间戳转换能否解决问题？非Java客户端如何处理？ #

Replicator基于时间戳的Offset转换确实能解决该问题——它会将源集群消费者的停止时间戳同步到目标集群，找到目标集群中对应时间点之后的消息开始消费，避开Offset不匹配的问题。
对于非Java客户端，可以通过以下方式处理：

• 迁移前，让源集群的消费者停止消费，记录每个分区最后消费消息的时间戳（而非Offset）。
• 目标集群重新分区完成、数据同步完毕后，非Java客户端调用对应语言的offsetsForTimes API（多数主流语言的Kafka客户端都实现了该接口），传入记录的时间戳，获取目标集群中对应分区的起始Offset，再从该位置开始消费。
• 如果客户端不支持offsetsForTimes，可以先启动一个临时Java消费者，用Replicator的逻辑转换出对应Offset，再将该Offset配置给非Java客户端使用。

3. Cluster Linking是否支持重新分区？MM2有相关配置覆盖吗？ #

Cluster Linking是逐字节精确复制，要求源与目标集群的主题分区数量、分区配置完全一致，不支持重新分区场景——如果目标集群主题分区数与源集群不同，Cluster Linking无法正常建立链接或同步数据，因为它是按分区一对一复制的。
MirrorMaker2（MM2）默认也是基于分区一对一镜像，同样不支持重新分区，但可以通过以下方式覆盖该场景：

• 先在目标集群手动创建好重新分区后的主题，禁止MM2自动创建主题。
• 配置sync.topic.configs=false，阻止MM2将源集群的分区配置同步到目标集群。
• 配合自定义消息转换逻辑，同步时根据目标集群的分区键规则，将源集群的消息分发到目标集群的对应分区中（可编写自定义转换类，或使用Kafka Connect的转换插件实现分区路由）。
• 另外，MM2也支持基于时间戳的Offset同步，和Replicator逻辑类似，可用于处理消费者起始位置问题。

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