解决 Kafka 分区不均衡和数据倾斜，关键在于从生产端控制消息落点：优先采用轮询或随机分区策略实现均匀写入；对需保序场景，通过哈希加盐或复合键改造热点 key；并协同优化分区数与集群拓扑。
解决 Kafka 分区不均衡和数据倾斜，关键在于从生产端控制消息落点，而不是等问题出现后再“救火”。核心思路是：让数据在写入时就均匀分布，同时兼顾业务有序性需求。
默认分区策略的适用边界
Kafka 默认使用 DefaultPartitioner，它按以下逻辑分配分区：
- 有 key 且未指定分区 → 对 key 做 Murmur2 哈希后取模，保证相同 key 进同一分区（用于顺序保障）
- key 为 null → 启用粘性分区（Sticky Partitioning），尽量复用前一个分区，提升批处理效率
- 显式指定分区 → 直接写入目标分区
这种策略在键分布天然均匀时很高效，但一旦出现高频 key（如热门用户 ID、固定订单类型），就会导致单一分区持续堆积，引发倾斜。
轮询与随机策略：适合无序场景的快速均衡
当消息无需按 key 保持顺序时，可直接启用更均衡的内置策略：
-
RoundRobinPartitioner：按顺序轮流写入各分区，负载最平均，配置只需一行：
partitioner.class=org.apache.kafka.clients.producer.RoundRobinPartitioner - RandomPartitioner（旧版本）或自定义随机逻辑：适用于对分区无任何语义要求的埋点、日志类数据
注意：轮询策略会打散 key 的局部性，若下游消费者依赖 key 顺序（如 Flink 的 keyed state），需评估影响。
热点 key 治理：加盐与复合键
对必须保留 key 语义但存在倾斜的场景（如订单号、用户 ID），不能简单弃用哈希，而要改造 key 本身：
-
哈希加盐（Hash Salting）：给原始 key 拼接随机或低频后缀，例如
"user_1001" + "_" + (int)(Math.random() * 16)，再哈希。盐值范围建议与分区数对齐，避免二次倾斜 -
复合键设计：将业务主键与时间戳、地域码、分片号等组合，例如
"user_1001#202607#sh"，扩大键空间，稀释热点 - 两层分区架构：外层用加盐 key 做粗粒度打散，内层消费者再按原始 key 做本地聚合，兼顾均衡与业务逻辑
分区数量与集群拓扑协同优化
再好的分区策略也受限于物理基础：
- 分区数应 ≥ Broker 数量，否则新扩容的节点无法承接流量；可通过
kafka-topics.sh --alter --partitions N动态扩容 - 扩容后需手动触发分区重分配（
kafka-reassign-partitions.sh），否则历史 topic 不会自动迁移至新节点 - 避免分区过多：单 topic 超过 200 分区会显著增加 ZooKeeper/KRaft 元数据压力和消费者组重平衡耗时
数据倾斜本质是资源分配问题，均衡不是靠单一策略，而是键设计、分区器选型、集群配置三者联动的结果。
