先说个大家都踩过的坑线上Kafka集群某个broker磁盘快满了另外几个broker负载却很低——看着分区数挺多、数据量挺大但流量压根没摊匀。这背后就是Kafka分区策略在起作用说白了分区策略决定了每条消息落到哪个分区而分区又直接决定了数据落在哪个broker、被哪个消费者拉取。所以搞懂Kafka的分区策略不只是面试时的加分项更是排查数据倾斜、消息延迟高、集群资源利用率低这些实际问题时绕不开的第一块砖。这篇文章我按自己的实践经验把分区策略从设计逻辑到落地实现拆开讲一遍先讲分区的本质和均衡分布的目标再看默认分区器到底怎么选路然后给出一套自定义分区器的完整示例和验证方法最后把生产环境里和分区强相关的几个疑难杂症——延迟高、大消息、UI排查、面试高频题——一并端上来。适合刚接触Kafka想系统理解分区的同学也适合被线上热点分区折磨过的运维和开发。1. 先把分区这层窗户纸捅破1.1 为什么Kafka非要有分区这一层很多人刚学Kafka时概念图看了一堆但心里一直有个疑问topic下面直接挂日志不就行了为什么非要切成多个分区这里我习惯用一个类比把一个topic当成一本大字典如果整本字典只有一个编委会所有词条都排队等着这一个编委会处理速度就锁死在这个编委会的单线程能力上了。Kafka也是一样topic只是逻辑上的分类一台broker上单个topic如果只有一个物理日志文件那吞吐量上限就被单盘IO锁死没法横向扩展。分区就是把这个物理日志按规则切开每个分区独立追加写入、独立被消费者拉取。分区数越多能并行写入的线程越多集群里能用上的broker也越多。更重要的是分区是Kafka并行度的最小单位——一个消费者组里同时消费某个topic的最大消费者数量等于这个topic的分区数。比如某个topic只有3个分区那你组里开5个消费者也会有2个消费者闲着因为3个分区最多被3个消费者瓜分。理解了这一层你就明白为什么分区策略不是小事了它不只是“消息放到哪个桶里”的简单路由而是决定了整个集群的流量分布、消费者的负载分配、甚至消息的顺序保证边界。1.2 均衡分布到底在解决什么问题数据均衡分布核心目标就一个让每个broker上的流量、磁盘占用、CPU开销尽量平均。一旦失衡就会出现我开头说的那种场景——某个broker磁盘已经90%了其他broker才30%你加多少磁盘都没用因为热点分区的写入压力都压在那一个broker上。这种倾斜带来的连锁反应很现实热点broker的网络带宽先打满接着磁盘IO排队然后这个broker上的分区写入延迟上升生产端的发送延迟也跟着涨消费者拉取也变慢。更隐蔽的问题是如果热点broker宕机大量分区的leader切换都集中在一起恢复期间整个topic的可用性都会受影响。所以设计分区策略时脑子里要时刻绷着“均衡”这根弦想清楚这三件事消息的key选什么会不会把流量聚到一小撮分区上分区数配多少够不够摊开生产者和消费者的并行度分区器和生产者的batch机制配合得好不好别让消息全挤在同一个分区上排队。这三件事里前两件最常见第三件容易被忽略我在后面的章节里逐个展开。2. 默认分区器的选路逻辑很多人以为分区器是必须自己写的其实Kafka默认自带的DefaultPartitioner已经能覆盖大多数场景。不过它内部虽然只有两条路——key为null走轮询key不为null走哈希取模——但这两条路背后各有值得深挖的细节。2.1 key为null时轮询和粘性分区是两回事当producer发消息时没指定key旧版的逻辑是每个分区轮流发一条消息落一个分区循环往复。这种简单轮询看着公平实际有个性能问题消息一条一条地分散到不同分区每个分区上的批次都攒不满producer就得频繁发起请求多分区间的网络连接也一直在空转。所以从Kafka 2.4版本开始默认分区器换成了粘性分区策略Sticky Partitioning。逻辑从“每条消息轮询一个分区”改成了“先盯住一个分区猛发攒够一批再换下一个分区”。这有点像地铁发车和出租车叫车的区别——轮询是每来一个人走一趟车永远坐不满粘性分区是排够一车人再发车车的满载率高很多。粘性分区的收益在两个指标上特别明显请求次数大幅下降吞吐量也跟着上来了。这个优化在实际压测里很直观同样是10万条无key消息粘性分区下的请求数可能只有轮询的几分之一。不过要注意粘性分区只在batch攒满或linger.ms超时时才切换分区如果你对消息延迟极度敏感可以适当调低linger.ms别让它一直压着消息不发。2.2 key不为null时哈希取模没那么简单key不为null时默认分区器用key的murmur2哈希值对分区数取模得到目标分区。这样设计的目的很明确相同key的消息永远进同一分区保证同一业务对象的消息有序。比如订单ID作为key同一个订单的所有状态变更一定被同一个消费者顺序处理。这里隐藏着一个常见的坑把用户ID、订单ID这些高基数字段直接拿来当key表面上哈希会很散但实际并不保证均衡。因为取模的结果是静态的如果key的分布本身有偏比如某几个热门用户的流量占了50%那对应那几个分区的负载就会明显高于其他分区。这就是经典的热点key问题在Kafka里表现成特定分区消息堆积、消费者组里某个成员Lag持续上涨。更隐蔽的是某些业务上看似不同的key哈希结果在取模后可能落在同一个分区。比如订单号前后缀有规律、customer_id尾号集中在几个数字上取模后极容易聚堆。我之前遇到过一家电商公司的订单topic分区数设了12结果流量集中在第3、第7分区原因就是订单号生成规则里有两个固定位导致哈希分布不均匀。2.3 分区数量只能加不能减扩容前先想清楚默认分区器的取模逻辑还有一个必须提前知道的背景Kafka分区数只支持增加不支持减少。因为分区一旦减少原来按模数3路由的数据没法按模数2回退Kafka干脆从设计上禁止了减少操作。这就带来一个实际困境如果你起初分区数配得少了后期只能加分区但加完分区之后历史消息的老分区不会自动重分布新消息的负载均衡也要从扩容那一刻才开始慢慢好转。换句话说扩容不是一锤子买卖它只是让后续数据有机会摊开之前堆积在热点分区的老数据还得靠别的手段处理。所以设置初始分区数时一定要往长远想。我个人的经验是按未来两年峰值吞吐量倒推再乘1.5到2的余量。宁可一开始多配几个分区也别等线上告警了才扩容。分区多了的上限风险很小单broker几千个分区没问题但分区少了带来的热点和并行度瓶颈代价要大得多。3. 自定义分区策略的落地实操默认分区器解决的是通用场景但真实业务里经常有“必须按特定规则路由”的需求这时候就得写自己的分区器。这块我做了一个完整示例从接口实现到验证方式一步步说。3.1 什么时候必须自写分区器自定义分区器不是炫技是有明确场景的。我总结了三类最典型的诉求。第一类是业务字段路由。比如日志系统有个tenant_id每个租户的数据量差异巨大如果按默认哈希分布大租户可能把某个分区打爆。这时可以让每个大租户独占分区小租户走哈希聚合把流量控制住。第二类是顺序保证的边界需要扩展。默认分区器保证相同key有序但有些业务的顺序要求是“同一类订单先按时间排跨类型无所谓”这类需求用固定字段做key搞不定必须自定义分区规则。第三类是机房亲和和生命周期管理。比如消息要跟某个计算节点本地聚合或者按数据冷热程度把消息分到不同保留策略的分区组这些都是默认分区器给不了的。3.2 一个完整的自定义分区器示例实现一个分区器非常简单Kafka留好了Partitioner接口只需要实现partition方法。下面这个例子解决的是“按订单金额分桶”的诉求import org.apache.kafka.clients.producer.Partitioner; import org.apache.kafka.common.Cluster; import org.apache.kafka.common.PartitionInfo; import org.apache.kafka.common.record.InvalidRecordException; import org.apache.kafka.common.utils.Utils; import java.util.List; import java.util.Map; public class OrderAmountPartitioner implements Partitioner { private int bigOrderPartition; private int normalPartitionCount; Override public void configure(MapString, ? configs) { // 从producer配置里读自定义参数避免硬编码 bigOrderPartition Integer.parseInt( (String) configs.getOrDefault(big.order.partition, 0)); normalPartitionCount Integer.parseInt( (String) configs.getOrDefault(normal.partition.count, 11)); } Override public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) { ListPartitionInfo partitions cluster.partitionsForTopic(topic); int numPartitions partitions.size(); if (keyBytes null || keyBytes.length 0) { throw new InvalidRecordException(Order message must have key); } String orderId (String) key; String amountStr orderId.split(_)[1]; double amount Double.parseDouble(amountStr); // 金额10000的订单进大订单分区保证独立并行处理 if (amount 10000) { return bigOrderPartition; } // 普通订单按订单ID哈希摊到其余分区 return Utils.toPositive(Utils.murmur2(keyBytes)) % normalPartitionCount; } Override public void close() { // 资源清理一般不用写 } }这里重点说两个实现细节。一是configure方法里读自定义参数比如big.order.partition这是在producer的properties里用分区器类名前缀加上的写死分区号会让扩缩容时非常痛苦从配置中心读就灵活得多。二是partition方法里一定要考虑numPartitions和normalPartitionCount的关系如果topic分区数比自定义的normalPartitionCount还小取模时会越界得加一层保护逻辑取min(numPartitions, normalPartitionCount)。生产端接入时在producer配置里指定props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, com.example.OrderAmountPartitioner); props.put(big.order.partition, 0); props.put(normal.partition.count, 11);3.3 配置与测试怎么证明均衡真的生效自定义分区器写完不能直接上线必须验证两件事路由结果是否符合预期消息分布是否均匀。这里我说一下自己的验证套路。最有用的工具是Kafka自带的kafka-console-producer和kafka-console-consumer但更直观的是写一个统计消费者把每条消息的partition、key、value都打出来脚本统计各分区消息数bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic order-events \ --from-beginning \ --property print.partitiontrue \ --property print.keytrue \ | awk -F[\t:] {print $2} | sort | uniq -c这条命令能清楚看到每条消息落在哪个分区以及各分区的消息条数。如果某个分区数量明显偏高先别急着改代码要确认是不是key本身分布有偏。这里有个经验判断标准假设topic有12个分区消息总数12000预期每条分区1000条上下如果某个分区超过1500基本可以断定路由规则或者key分布有问题。还有一类问题靠消息条数看不出来——消息大小差异。有的分区消息条数一样但单条消息体积差了几个量级导致磁盘占用和网络流量还是不均衡。这种场景我建议配合Prometheus和Kafka exporter看分区字节指标或者直接在消费者里统计字节总数条数和字节数两个维度一起看才全面。4. 与分区相关的生产环境疑难杂症分区策略能解释生产环境里一堆“莫名其妙”的现象。我挑了四个最常见的问题每个背后都能追溯到分区设计上。4.1 消息延迟高的排查链路线上说Kafka消息延迟高很多人第一反应是调producer的acks、重试次数但经常调了也没用因为根子可能卡在分区上。我把排查链路整理成三步。第一步看有没有热点分区。用consumer group的Lag指标如果某个分区的Lag明显高于其他分区说明消费者组里对应的消费者处理不过来而这个消费者负责的区域正好是消息集中打进来的分区。这时别急着加消费者因为同一分区只能被组内一个消费者处理加人是没用的得先解决分区路由均衡让热点分区的压力降下来。第二步看分区leader是否集中。可以用kafka-topics.sh --describe看每个分区的leader分布如果很多分区leader都挂在同一个broker上那这个broker的CPU和网络必然先被打满其他broker资源闲置。这种倾斜往往和分区创建时的broker分配策略、以及后续broker扩缩容有关需要靠分区重分配kafka-reassign-partitions.sh把leader打散。第三步看batch机制是否被分区打乱。前面说的粘性分区本来是为了攒批但如果你的key高度集中所有消息都进了同一个分区那其他分区的batch永远攒不满linger.ms一到就空发网络请求不少、消息却都堆在一个分区上排队延迟照样高。这一步的关键是看生产端的请求率和分区数、消息量是否匹配。4.2 单条消息接近1MB的配置连锁反应很多人第一次遇到“kafka接收1m”这个说法是在报错里看到RecordTooLargeException。Kafka默认单条消息最大是1MB由三个配置共同约束少配一个都会出问题。生产端要调max.request.size默认1MB它限制的是单个请求的最大字节数但一个请求里可以有多条消息所以它不是单条限制真正单条限制在broker端的message.max.bytes默认1MB还有replica.fetch.max.bytes默认10MB它管的是副本同步时单次拉取的最大字节如果broker间同步的消息超过这个值follower会报错。我遇到过最典型的翻车现场只改了broker端的message.max.bytes到10MB生产端max.request.size没动结果一压测就报RecordTooLargeException——因为生产端单请求上限还是1MB消息就卡在发送这一步了。所以调大消息上限时这三个参数必须同步调整我习惯把生产端max.request.size设成比message.max.bytes稍大的值给多条消息留点余量。单条消息变大还会连带影响分区均衡1MB的消息如果都hash到同一个分区那这个分区的磁盘IO和网络压力会极其夸张其他分区却很闲。如果业务里确实有这种大消息我建议单独开一个topic隔离别和常规消息混在一起不然一次大消息峰值就能把小消息的topic整体延迟拖垮。4.3 集群安装与UI排查工具的补充讨论分区策略时很多人想实践但不知道环境怎么搭这里补一段。Kafka集群安装现在比早期省事多了用KRaft模式也就是去掉ZooKeeper的那个版本最少三个节点就能组成一个可用的集群配置里只要指定controller和broker角色启动后集群自动选主。如果你在Windows上想快速体验我建议直接用Docker Desktop跑bitnami/kafka镜像或者下载官方二进制包后把config/server.properties里的log.dirs改成Windows路径bin目录下的脚本换成bin\windows\bat版本。Windows上最大的坑是路径分隔符和命令脚本后缀其他和Linux没区别。关于“kafka有没有ui界面”这个问题有而且选择不少。官方没有GUI但社区有几个成熟方案Kafka UI基于Web的界面支持查看topic、分区、消费组Lag适合日常巡检、Kafdrop轻量实用、还有偏向运维监控的Kafka Manager。我的习惯是日常看数据用Kafka UI看指标用PrometheusGrafana重分区和配置变更还是用命令行脚本因为UI对复杂操作的支持经常跟不上CLI。4.4 Kafka面试里的分区高频题最后把面试里经常被问到的分区题型归拢一下正好也是理解分区策略的检验清单。一是“Kafka为什么快”答案核心之一就是分区并行多个分区可以多个消费者并行消费、多个producer并行写入这是单队列做不到的。二是“一个消费者组里的消费者数量和分区数有什么关系”记住那句话分区是并行度上限消费者超过分区数时多余的消费者会空转。三是“如何保证消息有序”默认做法是相同key进同一分区单一分区内的消息是有序的但跨分区不保证全局有序——这个问题经常被追问“如果业务要求全局有序怎么办”答案往往是牺牲吞吐用单分区。还有两道稍微有难度的一是“key为null的消息如何路由”要能说出粘性分区和旧版轮询的区别二是“自定义分区器要注意什么”除了接口方法还要能说出配置加载、分区数量变化时的边界保护、以及和其他producer参数的联动。这些问题在原理解读章节已经全讲过了能答上来基本说明分区这块是真通了。回到开头那个场景我在排查完那个热点broker之后最终方案就是把分区数从6扩到24同时把用户ID里的渠道编码从key里去掉、改成纯用户ID哈希热点立刻摊开。这是我个人强烈建议的一个思路遇到分区不均先看key设计再看分区数量最后才考虑自定义分区器——大多数线上问题前两步就能解决一大半。
