kafka实现数据均衡分发关键在于生产者分区策略配置，而非单纯增加分区数；默认轮询策略（roundrobinpartitioner）在key为null时循环分配消息，天然均衡负载，推荐保持默认并确保key为空或合理加盐以避免倾斜。
Kafka 实现数据均衡分发，关键在于生产者端的分区策略配置，而非单纯增加分区数。配置得当，即使分区数量固定，也能让消息均匀落到各分区；配错了，哪怕分区很多，也可能出现“热点分区”或消费者空转。
生产者默认轮询策略（最常用且推荐）
Kafka 2.4+ 版本默认使用 RoundRobinPartitioner（轮询策略），适用于绝大多数无业务顺序要求的场景：
- 当消息 key 为 null 时，生产者自动按分区编号循环分配（0→1→2→…→n→0）；
- 不依赖 Broker 协调，纯客户端逻辑，开销低、效果稳；
- 能天然实现跨分区负载均衡，避免单点写入瓶颈。
✅ 建议保持默认，无需额外配置。
⚠️ 注意：确保你的消息 key 确实为空（或有意不设 key），否则会触发 Key-Hash 策略，可能破坏均衡。
按 key 分区时如何避免数据倾斜
如果你必须用 key（例如按用户 ID、订单号保证顺序），但又担心某些 key 出现高频写入导致倾斜：
-
加盐（salting）：对原始 key 拼接随机后缀（如
userId + "-" + random(1~10)），再哈希取模； -
预分桶：在业务层将 key 映射到固定桶 ID（如
hash(userId) % 100），再用该桶 ID 作为实际 key； - 检查 key 分布：上线前抽样统计 key 的频次分布，识别长尾 key 并做归一化处理。
这样既保留了“同 key 同分区”的有序性，又把流量打散到多个分区。
启用粘性分区器（Sticky Partitioner）
适用于高吞吐写入场景（如批量日志、指标上报）：
- 它不会严格轮询，而是优先填满当前批次所在的分区，等批次发完再换下一个；
- 减少小批次碎片，提升压缩率和网络效率；
- 仍能长期维持各分区写入量基本一致。
启用方式（Java 客户端）：
props.put("partitioner.class", "org.apache.kafka.clients.producer.internals.DefaultPartitioner");
// Kafka 2.4+ 默认已启用，无需显式设置；如需确认，可加：
props.put("enable.idempotence", "true"); // 配合粘性策略更稳定
避免使用随机策略
早期 Kafka 曾用 RandomPartitioner，但因概率性不均、不可复现、难排查，已被弃用：
- 即使统计上趋近均匀，单次运行仍可能出现某分区接收 60% 消息；
- 无法与幂等性、事务配合，容易引发重复或乱序；
- 当前版本不推荐，也不再作为默认选项。
消费端配合：选对分配策略
生产端均衡了，消费端也得跟上，否则会出现“有的消费者忙死，有的闲死”：
- 单 Topic 场景：
RangeAssignor（默认）够用； - 多 Topic + 多消费者：建议显式配置
RoundRobinAssignor或StickyAssignor； - 动态扩缩容频繁：必须用
StickyAssignor，减少重平衡时的分区迁移开销。
示例配置：
partition.assignment.strategy=org.apache.kafka.clients.consumer.StickyAssignor
不复杂但容易忽略。
