Kafka如何处理压缩主题的分区添加？是否有合法扩容方式？

你的理解完全正确：默认分区器通过key.hashCode() % numPartitions计算分区，扩容后同一key的分区映射会改变，导致同一key的消息分散到不同分区，破坏日志压缩依赖的「单分区内key唯一性」规则，最终使压缩机制失效。但确实存在合法的扩容方式，核心原则是确保同一key的所有消息始终落在同一个分区，具体方案如下：

一、自定义分区器（推荐生产环境使用） #

实现自定义分区器，让key的分区映射不随总分区数变化而改变，保证旧key始终落在原分区，新key可分配到所有分区（包括新增的）。

示例Java实现：

public class CompactedTopicPartitioner implements Partitioner {
    private int originalPartitionCount;

    @Override
    public void configure(Map<String, ?> configs) {
        // 从配置中读取扩容前的原始分区数
        originalPartitionCount = Integer.parseInt(configs.get("compacted.topic.original.partitions").toString());
    }

    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        int totalPartitions = cluster.partitionCountForTopic(topic);
        int keyHash = Math.abs(key.hashCode());
        
        // 保留旧key的分区映射：用原始分区数计算的结果，若小于当前总分区数则直接使用
        int originalPartition = keyHash % originalPartitionCount;
        if (originalPartition < totalPartitions) {
            return originalPartition;
        }
        // 新key或超出范围的key，用当前总分区数计算（保证均匀分布）
        return keyHash % totalPartitions;
    }

    @Override
    public void close() {}
}

使用时，在生产者配置中添加：

partitioner.class=com.your.package.CompactedTopicPartitioner
compacted.topic.original.partitions=3  # 替换为扩容前的实际分区数

这种方式无需中断服务，扩容后各分区内的key依然保持唯一，日志压缩可正常工作。

二、数据迁移到新主题（适合大规模扩容） #

若不想修改生产者逻辑，可按以下步骤操作：

• 停止向原压缩主题生产新消息；
• 使用kafka-mirror-maker.sh或自定义消费者，将原主题的所有数据迁移到一个已创建好目标分区数的新压缩主题中；
• 验证迁移完成后，将生产者和消费者切换到新主题。

此方案能彻底避免分区映射问题，新主题的所有分区都满足「同一key单分区」的要求，压缩机制完全正常。

三、临时手动路由（不推荐长期使用） #

在扩容过渡期，可让生产者手动指定分区，或硬编码key到分区的映射规则，确保同一key始终发送到同一分区。但这种方式灵活性差，维护成本高，仅适合短期临时过渡。

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