Kafka 生产者的分区策略（Partitioner）有哪些？

知识点图片

Kafka 生产者（Producer）在发送消息时，必须决定将消息发送到 Topic 的哪个分区（Partition）。这个过程由 分区器（Partitioner） 来完成。

选择合适的分区策略对于 Kafka 的 负载均衡、消息顺序性 和 吞吐量 至关重要。

以下是 Kafka 生产者常见的分区策略：

1. 默认分区策略 (DefaultPartitioner)

这是 Kafka 生产者默认使用的策略（如果没有显式配置其他策略）。它的行为取决于消息是否指定了 Key。

A. 如果指定了 Key (Key != null)

策略：Hash 取模。
原理：Kafka 对 Key 进行 Hash 计算（使用 MurmurHash2 算法），然后对总分区数取模。
结果：具有相同 Key 的消息总是会被发送到同一个分区。
适用场景：需要保证消息顺序的场景（例如：同一个订单 ID 的状态变更必须有序）。

B. 如果没有指定 Key (Key == null)

这里的行为在 Kafka 2.4 版本前后发生了重大变化：

Kafka 2.4 之前：轮询策略 (Round Robin)。
- 消息会以轮询的方式均匀地分布到所有可用分区中。
- 缺点：会导致生成的 Batch（批次）很小，因为消息过于分散，增加了网络请求次数，降低了吞吐量。
Kafka 2.4 及之后：粘性分区策略 (Sticky Partitioning)。
- 原理：生产者会随机选择一个分区，并尽可能地坚持使用该分区，直到该分区的 Batch（批次）已满（默认 16KB）或者 linger.ms 时间到达。一旦触发发送，生产者会随机选择一个新的分区，并重复此过程。
- 优点：这就好比“装满一辆车再发车，而不是每辆车装一个人就发车”。这极大地提高了消息的批处理效率，减少了请求延迟，提升了整体吞吐量。

2. 轮询策略 (RoundRobinPartitioner)

如果你显式配置了 RoundRobinPartitioner，无论消息是否有 Key，生产者都会忽略 Key 的 Hash 逻辑，强制进行轮询。

原理：将消息依次发送到 Partition 0, Partition 1, Partition 2 ... 然后回到 0。
配置：props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, "org.apache.kafka.clients.producer.RoundRobinPartitioner");
优点：绝对的负载均衡，所有分区的数据量非常均匀。
缺点：
1. 破坏顺序性：相同 Key 的消息会被分散到不同分区。
2. 性能较低：无法利用“粘性”特性，导致 Batch 较小，频繁触发网络请求。

3. 统一粘性分区策略 (UniformStickyPartitioner)

这是 Kafka 2.4 引入的一个独立分区器。它的逻辑与 DefaultPartitioner 在“没有 Key”时的逻辑一致。

原理：纯粹的粘性分区。即使你指定了 Key，它也会忽略 Key 的 Hash 逻辑，而是使用粘性策略（装满一个 Batch 换一个分区）。
适用场景：当你确实有 Key，但你不关心顺序，只关心极致的吞吐量时（这种情况比较少见）。

4. 自定义分区策略 (Custom Partitioner)

如果上述策略都不能满足需求，你可以实现 org.apache.kafka.clients.producer.Partitioner 接口，自定义分发逻辑。

实现方法：重写 partition 方法。
常见场景：
- VIP 通道：将特定用户（Key）的消息发送到专属的高性能分区，其他用户发送到普通分区。
- 数据倾斜处理：如果某些 Key 的数据量特别大，可以通过自定义算法将其分散到多个特定分区，而不是集中在一个分区。
- 地域路由：根据消息内容将数据发送到特定的分区以供特定地区的消费者消费。

代码示例：

java

public class MyCustomPartitioner implements Partitioner {
    @Override
    public int partition(String topic, Object key, byte[] keyBytes, 
                         Object value, byte[] valueBytes, Cluster cluster) {
        // 获取该 Topic 的所有分区信息
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
        int numPartitions = partitions.size();

        // 自定义逻辑：如果 Key 是 "vip"，总是发到最后一个分区
        if ("vip".equals(key)) {
            return numPartitions - 1;
        }
        
        // 其他情况使用简单的 Hash
        return Math.abs(key.hashCode() % (numPartitions - 1));
    }

    @Override
    public void close() {}
    @Override
    public void configure(Map<String, ?> configs) {}
}

总结对比表

策略名称	是否有 Key	行为逻辑	优点	缺点
Default (默认)	有 Key	Hash(Key) % 分区数	保证相同 Key 的消息有序	数据可能倾斜
Default (默认)	无 Key	粘性分区 (Sticky) (2.4+)	高吞吐，减少请求次数	短时间内负载可能不绝对均匀
RoundRobin	任意	绝对轮询 (P0->P1->P2...)	绝对的负载均衡	批处理效率低，无顺序保证
Custom	任意	用户自定义代码	灵活，满足特殊业务需求	开发维护成本高

最佳实践建议

大多数情况下，使用默认策略（DefaultPartitioner）即可。
- 如果需要顺序，传 Key。
- 如果不需要顺序，不传 Key（自动享受粘性分区带来的高性能）。
避免数据倾斜：如果你使用 Key，要确保 Key 的分布是离散的。如果某个 Key 的数据量占了 90%，那么对应的分区就会被打爆，而其他分区空闲。
分区数变化警告：如果使用了 Key 进行 Hash 分区，一旦 Topic 的分区数量发生变化（扩容），原本发往 Partition 1 的 Key 可能会被 Hash 到 Partition 2，这会打破消息的顺序性。因此，在创建 Topic 时应预估好分区数，尽量避免后期调整。

右滑查看面试常问

播面