Kafka指定分区发送同Key消息后，后续同Key消息是否进同分区？

核心问题答案 #

Message2不一定会写入分区0。

Kafka生产者的分区选择逻辑是：

• 当手动指定分区时，生产者会直接将消息发送到该分区，不会触发默认分区计算逻辑。
• 当不指定分区时，会使用配置的分区器（默认是DefaultPartitioner），它通过Utils.murmur2(keyBytes) % numPartitions的规则，对Key的哈希值取模分区总数来确定目标分区。

手动指定分区的操作不会修改Key与分区的默认映射关系，后续不带分区指定的同Key消息，依然会按照默认规则计算分区。只有当Key"A"的哈希值取模主题分区数刚好等于0时，Message2才会进入分区0，否则会进入其他分区。

业务场景解决方案 #

针对你提到的「新旧ID消息需进入同一分区」的需求，原方案存在逻辑漏洞——手动指定一次新ID的分区后，后续新ID消息仍会按自身Key的哈希计算分区，无法自动沿用之前指定的分区。推荐以下几种可行方案：

方案一：自定义分区器 #

实现自定义分区器，在其中添加新旧ID的映射逻辑：

1. 维护新旧ID的映射关系（可存储在本地缓存或分布式存储中）。
2. 当处理新ID的消息时，从映射关系中获取旧ID对应的分区，直接将消息路由到该分区；对于无映射关系的ID，仍使用默认哈希规则。
3. 在生产者配置中指定该自定义分区器，替代默认分区器。

方案二：统一手动指定分区 #

后续所有发送新ID的消息时，都手动指定到旧ID对应的分区：

1. 预先获取旧ID对应的分区（可通过默认分区规则计算，或从元数据中查询）。
2. 发送新ID消息时，显式指定该分区，不再依赖Key的自动分区逻辑。

方案三：临时替换Key发送 #

如果新旧ID的映射是短期临时需求，可以临时将消息的Key设置为旧ID，同时在消息体中携带新ID信息：

• 发送时：用旧ID作为消息Key，消息内容中包含新ID及业务数据。
• 消费时：从消息体中解析新ID进行业务处理，同时利用旧ID的分区保证消息落在同一分区。

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