例如，我有4个分区。当键101的msg1消息被放入分区1的(并且尚未被消耗时。同时，添加了一个新分区，总共5个分区。
然后键101的下一条消息msg2进入第四分区(例如(，因为hash(101)%no_of_partitions=4。
现在，在流API中，每当消息被其密钥消耗时，将访问分区4以获取该密钥，因为这是它在计算hash(101)%no_of_partitions时获得的分区，因此它在分区4中获得密钥101的msg2。
现在，分区1中键101的msg1
您不会丢失数据，但是，根据您的应用程序，添加分区可能不受支持，并且会破坏您的应用软件。
如果应用程序是无状态的，则只能添加分区。如果应用程序是有状态的，那么应用程序很可能会因异常而崩溃和死亡。
还要注意，Kafka Streams假设输入数据是按键分区的。因此，如果分区被更改，即使应用程序没有中断，它也很可能计算出不正确的结果，因为添加分区违反了分区假设。
解决此问题的一种方法是重置应用程序(cf(。但是，这意味着您放松了当前的应用程序状态。请注意，重置不会解决分区不正确的问题，您的应用程序可能会计算出不正确的结果。为了防止分区问题，可以插入一个伪map()操作，该操作只在从主题读取数据后转发数据，因为如果需要，这将导致数据重新分区，从而修复基于键的分区。
分区1中键101的 消息1在Kafka Streams中，您不会"通过密钥来消费消息"。每个分区中的每条消息都将被消耗掉。如果有人应该对密钥进行过滤，它就会出现在Kafka Stream应用程序的代码中。
它会被消耗，但订单不保证。请确保应用程序逻辑是幂等的。一种可能的解决方案是使用更多分区来完成中间主题。KStream#through将帮助您通过一条指令进行生产和消费。该方法执行完全相同的操作，并返回一个KStream。在伪代码中：
.stream(...)
// potential key transformation
.through("inner_topic_with_more_partitions")
.toTable(accountMateriazer)