简单地说，当您更改正在处理的事件/消息的键时，kafka流中会发生重新分区。
重分区基本上是流处理的洗牌阶段。这可以发生在Kafka流、apachespark、flink、storm、hadoop等等。。。。这些是分布式流处理引擎（dspe），旨在并行执行任务以加快处理速度。然后，当你打电话给 map 转换dspe转换这个逻辑 map 变成一个实体 map 并行任务x（x通常是机器的内核数）。
所以，如果你用 mapValues 并且不更改密钥，Kafka流不会重新分区。但是如果你用 map ，Kafka流将重新分区。此外，如果您使用任何聚合转换（例如： reduce , join ，…）Kafka将执行重新分区，因为它基于密钥。
当存在聚合阶段时，会发生重新分区/洗牌阶段。假设您有一个逻辑管道：
... -> map -> reduce -> ...
引擎盖下的物理管道如下所示：

具有相同键的事件按 groupByKey 转换并发送到相同的 reduce 并行任务示例。这是洗牌阶段。
在kafka流的情况下，当发生聚合时，管道从 KStream 至 KTable 因为消息分布在kafka代理上，流引擎必须查找不同分区上的事件。如果您使用intellij，它会在管道更改时对您产生影响。在下图中，它正在发生一个单词计数和 count 转换是有状态的，就像 reduce .

这是一个很好的来源，阅读更多关于Kafka流重新分区。如我所说，其他dspe在洗牌阶段也依赖于重新分区。另一个好消息来源是Flink的消息。