Kafka 分区策略
简单来说：有 Key 就用 Key 哈希，没 Key 就用轮询（或粘性）。这是 Kafka 默认分区器 (DefaultPartitioner) 的核心逻辑。
在更具体的业务场景下，选择哪种策略，主要取决于你对消息顺序性和负载均衡的权衡。
为了帮你更清晰地理解，我将这两种策略的核心区别整理成了下表：
| 特性 | Key 哈希 (Key-Hashing) | 轮询 (Round-Robin) |
|---|---|---|
| 触发条件 | 消息指定了 Key | 消息未指定 Key（Key 为 null） |
| 核心逻辑 | 对 Key 进行哈希计算（如 Murmur2），然后对分区数取模 | 将消息依次、循环地分配到所有可用分区上 |
| 主要优点 | 保证相同 Key 的消息有序，满足业务逻辑 | 负载绝对均衡，能最大程度避免数据倾斜 |
| 主要缺点 | 若 Key 分布不均，可能导致热点分区（数据倾斜），影响整体吞吐 | 无法保证任何顺序性，因为消息被分散到不同分区 |
| 适用场景 | 强顺序性要求：如订单状态更新、用户行为轨迹追踪，需确保同一订单或用户的消息按顺序处理 | 无顺序要求的大流量场景：如海量日志采集、监控指标数据上报，首要目标是均匀写入 |
⚠️ 注意事项
- 版本差异：在 Kafka 2.4 版本之前，无 Key 消息默认使用纯粹的轮询策略。但从 2.4 版本开始，默认行为已升级为性能更优的粘性分区策略 (Sticky Partitioner)。它会在一个分区内"粘"着发送一批消息，直到批次填满再切换，以提升批处理效率。但它在负载均衡方面的表现与轮询策略类似。
- 自定义策略：如果上述策略都无法满足你的复杂业务需求（如按消息中的地域信息分区），你可以通过实现
Partitioner接口来创建自定义分区策略。
总而言之，选择哪种策略的核心依据是业务是否要求消息的顺序性。
- 需要保证顺序 → 使用 Key 哈希
- 不需要保证顺序 → 使用 轮询（或粘性）策略
如果你对如何自定义分区器，或者对"粘性分区"的具体工作原理感兴趣，我们可以继续探讨。