kafka的partitioner是影响顺序性、吞吐量和负载均衡的核心机制；defaultpartitioner对带key消息用murmur2哈希保序，无key消息在2.4+启用sticky分区提升批处理效率；误选策略会导致数据倾斜、顺序丢失或延迟突增。
Kafka 的消息分区分配策略（Partitioner）直接决定每条消息写入哪个 Partition，它不是可有可无的配置项，而是影响顺序性、吞吐量和负载均衡的核心机制。
DefaultPartitioner：默认策略的行为与关键演进
未显式配置 partitioner.class 时，Kafka 自动使用 DefaultPartitioner。它的行为在 Kafka 2.4 版本前后有实质性优化：
- 带 Key 的消息：始终用 Murmur2 哈希算法对 Key 序列化后取模，确保相同 Key 落在同一分区，维持分区内有序
- 无 Key 的消息：
– Kafka – Kafka ≥ 2.4：启用 Sticky Partitioning（粘性分区），连续无 Key 消息优先塞满一个 Batch 再换分区，显著降低平均延迟、提升批处理效率（实测吞吐提升 15%~30%）
其他内置 Partitioner 的适用场景
需通过 partitioner.class 显式指定，不可混用：
- RoundRobinPartitioner：强制所有消息（含带 Key 的）轮询分发。会破坏 Key 的顺序性，仅适用于完全不关心顺序、且希望极致均匀打散的测试或日志类场景
- UniformStickyPartitioner（Kafka 3.3+）：在粘性基础上进一步优化可用分区选择逻辑，使无 Key 消息在多个可用分区间更均匀分布，缓解单点粘性过强导致的潜在倾斜
自定义 Partitioner 的核心要点
实现 org.apache.kafka.clients.producer.Partitioner 接口即可，关键注意：
- 必须重写 partition() 方法，接收 topic、key、value、序列化字节数组及 Cluster 元数据（含当前所有 Broker 和 Partition 状态）
- 若依赖集群状态（如按 Broker 负载选分区），务必在方法内做空值和异常防护，避免因元数据暂不可用导致发送失败
- 避免在 partition() 中执行阻塞或耗时操作（如远程调用、文件读写），否则会拖慢整个 Producer 的发送线程
分区策略选错的典型后果
看似简单的配置，一旦误用可能引发隐蔽但严重的问题：
- 数据倾斜：哈希 Key 设计不合理（如大量 null 或固定值），或自定义 Partitioner 逻辑缺陷，导致 80% 消息挤在 1~2 个分区，其余分区长期空闲
- 顺序性丢失：对需要按业务 ID 保序的场景误用 RoundRobinPartitioner，相同 ID 消息分散到不同分区，下游无法还原全局顺序
- 消费延迟突增：无 Key 场景下仍用旧版轮询，小流量时每个 Batch 都不满，只能等 linger.ms 超时才发，端到端延迟从毫秒级升至百毫秒级
