KafkaProducer 分区策略：一条消息怎么被分到正确的 Partition

为什么分区策略很重要前面几篇一直在讲消息进了 RecordAccumulator 之后怎么发。但有个问题没回答同一条消息为什么会被塞进 topic-A 的 P0 而不是 P1这个决定发生在partitioner.partition()这一步。它看起来简单——返回一个整数——但这个整数决定了三件事这条消息和哪些消息攒成一个 batch同分区才会攒批消费端谁来处理分区决定消费者分配消息的顺序性同 key 同分区才有序选错了轻则批次攒不起来、吞吐上不去重则某个分区被打爆、其他分区闲着。01 Partitioner 接口就三个方法自定义分区器要实现Partitioner接口核心是一个方法publicinterfacePartitionerextendsConfigurable,Closeable{intpartition(Stringtopic,Objectkey,byte[]keyBytes,Objectvalue,byte[]valueBytes,Clustercluster);voidclose();}configure(Map)继承自 Configurable拿到 Producer 全部配置。配置项partitioner.classcom.example.MyPartitioner默认实现是DefaultPartitioner2.4 内部用 StickyPartitioner。它的逻辑就两条分支02 带 keymurmur2 hash同 key 同分区消息带 key 时intpartitionUtils.toPositive(Utils.murmur2(keyBytes))%numPartitions;为什么用 murmur2 而不是String.hashCode()因为 JDK 的 hashCode 分布不均匀——连续 key 会扎堆。murmur2 是 Kafka 专门选的分布更均匀。这个策略保证了一件事同 key 的消息永远落同分区。所以 user_id12345 的所有事件一定在同一个分区里消费端按顺序处理。这就是按用户维度做顺序消费的基础。代价是热点 key如果某个 key比如一个大促活动 ID的数据量是其他 key 的 100 倍那它所在的分区就成了热点——该分区所在的 Broker 网络打满其他分区闲着。03 不带 keyStickyPartitioner先粘住再切消息不带 key 时老版本2.4 之前默认轮询——每条消息换一个分区。问题是攒批效果极差10 个分区每条消息换一个每个分区平均只有几条消息每个 batch 都是半满就发出去了。2.4 之后默认改成StickyPartitioner// 伪代码先随机选一个分区粘住intstickyPartitionrandom.nextInt(numPartitions);// 攒满 batch.size 之前所有无 key 消息都往这个分区塞// 攒满了随机切下一个分区短期看数据倾斜全粘在一个分区长期看均匀每个 batch 切一次。换来的好处是单批次更大——默认 16KB 的 batch.size 能真正攒满网络请求更少。这就是为什么第三篇讲 Sticky 分区器能提升吞吐——它牺牲了短期均匀换批次填满。04 四种策略对比策略分布顺序攒批问题带 key hash均匀强顺序中热点 key无 key 轮询均匀无差批次小无 key Sticky长期均匀无好短期倾斜自定义看实现可保看实现容易写歪选择原则很简单要顺序同一实体的事件要按序处理→ 带 key不要顺序日志、埋点流→ 用默认 Sticky别手动设轮询有业务路由需求按地域、灰度、租户隔离→ 自定义 Partitioner别为了看起来均匀去写自定义分区器——默认 Sticky 已经做得很好了。自定义分区器最常见的问题是上线前没压测分布结果某个分区被打爆。05 分区数怎么定分区数决定了两件事生产吞吐上限、消费并行度上限。经验公式分区数 ≈ max(目标吞吐 / 单分区吞吐, 消费并行度) × 2单分区生产吞吐经验值约 10MB/s压缩后更高消费端并行度不能超过分区数——10 个分区开 20 个消费者线程有 10 个闲着加分区只能加不能减而且加分区会改变 key 的 hash 路由——原来 hash 到 P3 的 key加了分区后可能落到 P7同 key 的消息乱序所以一开始就留余量。现在需要 10 个分区直接建 20 个。一个 Broker 上分区数别超过 2000集群总分区数别超过 20000——太多了 Leader 选举、元数据同步都会变慢。06 热点 key 怎么拆线上最常见的问题不是分区太少而是某个 key 太大。症状JMX 看某分区 BytesInPerSec 远高于其他分区kafka-lag 看某分区 lag 一直涨该分区所在 Broker CPU 打满。定位kafka-console-consumer--topicmy-topic\--bootstrap-server kafka:9092\--propertyprint.keytrue\--from-beginning|head-10000|awk{print $1}|sort|uniq-c|sort-rn|head哪几个 key 出现频率远超均值就是热点。常见元凶大促活动 ID、默认 key、空 key空 key 走 Sticky 不会热点别误判。拆法key 加随机后缀。// 原来所有大促消息都落到 P3producer.send(big-sale-2024,data);// 改成拆成 N 个子 key分散到多分区intbucketThreadLocalRandom.current().nextInt(10);Stringkeybig-sale-2024-bucket;producer.send(key,data);代价是同实体跨分区失去单 key 顺序性。如果业务能接受比如日志类这是最简单的拆法。如果不能接受顺序就得在消费端做归并或者换业务 key 设计。写在最后分区策略不是选一个算法这么简单——它是吞吐、顺序、负载三者的权衡。带 key 换顺序Sticky 换吞吐自定义换灵活性。线上出问题最多的两种带了 key 但 key 设计得太粗导致热点或者完全不带 key 但又想要顺序不可能。实际项目里90% 的场景用默认策略就够了要顺序带业务 ID 做 key不要顺序什么都别设。剩下 10% 有特殊路由需求的才考虑自定义 Partitioner——而且上线前一定要压测分布。