Kafka生产者消息均匀分发关键在于合理使用默认分区策略：key为null时启用轮询（2.4+），否则触发key-hash易倾斜；业务无需顺序时传null key；需保留顺序则加盐或哈希打散key；慎用粘性分区；分区数应匹配Broker数与消费者线程总数。
要在 Kafka 生产者中实现消息均匀分发，关键不是换分区器，而是理解默认行为并控制好 key 是否为空、分区数是否合理 和 是否需要强顺序保证。多数场景下，无需自定义，只需用对默认策略即可。
保持默认分区器（DefaultPartitioner），但确保 key 为 null
从 Kafka 2.4 开始，默认使用 RoundRobinPartitioner（轮询），但它只在 消息 key 为 null 时生效。一旦设置了 key，就会自动切换为 key-hash 策略——这容易导致倾斜。
- 若业务不要求相同 key 的消息进同一分区（如日志、埋点、告警等），发送时直接传
null作为 key - Java 示例：
new ProducerRecord<>(topic, null, "value") - 这样每条消息会按 0→1→2→…→n→0 循环分配，天然均衡，且不依赖 Broker 协调
业务必须带 key？那就做 key 加盐或哈希打散
当需保留顺序性（如用户订单状态变更），但原始 key 分布不均（例如大量小 ID 用户集中产生数据），直接 hash 取模会压垮个别分区。
- 避免用原始
user_id或order_no直接作 key - 改用加盐后哈希：比如
key = user_id + "-" + System.nanoTime() + new Random().nextInt(100)，再序列化 - 或预计算哈希分桶：
key = String.valueOf(Math.abs(user_id.hashCode()) % 100)，把热点分散到 100 个逻辑桶 - 注意：加盐后相同业务实体的消息可能不再进同一分区，需确认是否可接受
慎用粘性分区（Sticky Partitioner）——它不等于全局轮询
Kafka 默认的 DefaultPartitioner 在无 key 场景下实际用的是 粘性分区（KIP-480），而非严格轮询：它先随机选一个分区“黏住”，填满 batch 后再换一个。
立即学习“Java免费学习笔记（深入）”；
- 优点：提升吞吐，减少小 batch 延迟
- 缺点：单个 Producer 实例内短期可能不完全均匀；多实例之间更无全局顺序保障
- 如果你真需要严格轮询（比如压测验证分布），可显式配置：
props.put("partitioner.class", "org.apache.kafka.clients.producer.RoundRobinPartitioner");
配合 Topic 分区数与消费者组一起看
再好的分区策略也架不住分区数不合理：
- 分区数建议设为集群 Broker 数的整数倍（如 6 Broker → 12/18 分区），避免部分节点闲置
- 确保分区数 ≥ 消费者线程总数（例如 5 台机器 × 每台 4 线程 = 20 线程，则至少 20 分区）
- 扩容分区后，历史消息不会重分布，所以初始值要按峰值流量预估，预留 20%~50% 余量
