90%的Kafka新手都会踩这个坑：消息发出去了，要么分区负载严重不均（有的分区消息堆成山，有的空着），要么同一类消息乱序（列如同一个用户的操作日志散落在不同分区）。

实则问题出在“分区策略”没选对——轮询和按key分区，看似简单，选错了可能直接影响系统性能和业务逻辑。

3分钟看懂两者区别，附实操代码，再也不用纠结！

一、先搞懂：分区策略到底是啥？

简单说，分区策略就是“消息分配规则”——当生产者发送消息到一个多分区的Topic时，Kafka根据什么规则把消息放到哪个分区（列如Topic有3个分区，消息1放分区0？消息2放分区1？）。

核心作用有两个：

1. 决定消息的存储位置，影响负载均衡（避免单分区压力过大）；
2. 决定消息的顺序性（同一分区内消息有序，不同分区无全局顺序）。

最常用的两种策略：轮询（Round-Robin） 和按key分区（Key-Based）。

二、轮询策略：像“发扑克牌”一样平均分（默认策略）

通俗理解

就像发扑克牌，你一张、我一张、他一张——消息按顺序依次分配到各个分区，每个分区轮流接收消息。

实操表现（以3个分区为例）

消息1 → 分区0  
消息2 → 分区1  
消息3 → 分区2  
消息4 → 分区0  
消息5 → 分区1  
...（循环往复）

代码示例（Kafka默认就是轮询，无需额外配置）

// 生产者配置（默认轮询策略）
Properties props = new Properties();
props.put("bootstrap.servers", "broker0:9092,broker1:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);
// 发送消息时不指定key，触发轮询策略
producer.send(new ProducerRecord<>("log-topic", null, "用户A登录")); // 分区0
producer.send(new ProducerRecord<>("log-topic", null, "用户B下单")); // 分区1
producer.send(new ProducerRecord<>("log-topic", null, "用户C支付")); // 分区2

优点

• 负载绝对均衡：每个分区接收的消息数量基本一致，不会出现某个分区积压的情况；
• 无需额外配置：Kafka默认就是这种策略，新手直接用也不会出错。

缺点

• 同一类消息会分散：列如“用户A”的登录、下单、支付消息可能分到不同分区，消费时无法保证顺序（如果业务需要按用户操作顺序处理，就会出问题）。

适用场景

• 日志收集（如应用日志、监控数据）：只需要存储和批量处理，不要求同一类消息的顺序；
• 消息量均匀的场景：各类型消息占比差不多，轮询能最大化利用分区资源。

三、按key分区：像“按部门归档文件”一样归类（指定key时触发）

通俗理解

就像公司归档文件，“技术部”的文件全放1号柜，“市场部”的全放2号柜——消息会根据指定的“key”（如用户ID、订单号）分配到固定分区，同一key的消息必定在同一个分区。

实操原理

Kafka会对key做哈希计算（hash(key) % 分区数），得到分区编号，因此同一key的哈希值一样，必然分到同一个分区：

key=用户A → hash(A)=100 → 100%3=1 → 分区1  
key=用户A → hash(A)=100 → 100%3=1 → 分区1（同一用户消息在同一分区）  
key=用户B → hash(B)=200 → 200%3=2 → 分区2  

代码示例（指定key即可触发）

// 其他配置同上，发送消息时指定key
Producer<String, String> producer = new KafkaProducer<>(props);
// key=用户ID，同一用户的消息会到同一分区
producer.send(new ProducerRecord<>("order-topic", "user100", "用户100下单")); // 分区X
producer.send(new ProducerRecord<>("order-topic", "user100", "用户100支付")); // 分区X（和上一条同分区）
producer.send(new ProducerRecord<>("order-topic", "user200", "用户200下单")); // 分区Y

优点

• 同一key消息绝对有序：同一用户/订单的消息在同一分区，消费时能按发送顺序处理（列如先下单后支付，不会颠倒）；
• 业务关联性强：方便按key做聚合处理（列如统计某个用户的所有操作）。

缺点

• 可能出现热点分区：如果某个key的消息量特别大（列如“爆款商品”的订单），对应的分区会积压，其他分区空闲，导致负载不均；
• 需手动指定key：如果key设置不合理（如全是null），会退化为轮询。

适用场景

• 业务有顺序要求的场景：如订单流程（下单→支付→发货必须按顺序）、用户操作轨迹（登录→浏览→购买）；
• 需要按key聚合的场景：如统计每个用户的订单量、分析某类商品的销售数据。

四、关键对比表：30秒选对策略

维度	轮询策略（无key）	按key分区（有key）
负载均衡	✅ 优秀（绝对平均）	⚠️ 可能失衡（依赖key分布）
消息顺序	❌ 同一类消息无序	✅ 同一key消息有序
适用场景	日志、监控等无顺序需求场景	订单、用户轨迹等有顺序需求场景
配置难度	✅ 零配置（默认）	⚠️ 需要合理设计key
典型问题	无法保证同类消息顺序	热点分区（需优化key）

五、实操避坑指南

1、按key分区如何避免热点？

1. 对热点key做“加盐”处理：列如“爆款商品ID”→“商品ID_随机数”，让消息分散到多个分区；
2. 提前预估key分布：如果某类key消息量特别大，可单独创建Topic并增加分区数。

2、需要全局顺序怎么办？

1. 两种策略都做不到！全局顺序只能用“单分区Topic”（但会失去并行能力，谨慎用）。

3、新手提议

1. 不确定选哪种时，先试轮询（简单不出错）；
2. 涉及业务流程顺序时，必用按key分区，同时做好key的负载均衡设计。

互动话题

你项目中用的哪种分区策略？有没有遇到过热点分区或消息乱序的坑？评论区分享你的解决方案，帮更多人避坑～

（下一篇讲“Kafka重平衡”，关注不迷路！）