应用程序在启动时将EventData.PartitionKey的值设置为新的Guid。因此，对于每个新部署，分区密钥都将更改。
我了解事件中心利用散列机制将消息路由到特定分区。重新生成分区键是否会以任何有害的方式阻碍或影响这种机制？
我不时注意到，在多次部署之后，事件中心中没有出现消息（无论已经过了多少时间），尽管基础EventHubClient.SendBatchAsync方法没有抛出{{1 }}。这种行为似乎是任意纠正自己的。
答案 0 :(得分：3)
影响将是：每次你的应用程序重新启动时 - 消息可能落在一个完全不同的分区中 - 因为，新的Guid可以被散列到不同的EventHub分区。
这不会以任何方式损害EventHub的性能。您可以根据需要生成尽可能多的PartitionKey。
但是，消费这些事件的应用程序会受到影响：通常会有一个工作人员处理单个分区中的事件（ EventHubs分区是事件的规模单位 - 处理器处理EventHubs中的事件）。当您的应用程序使用Guid1启动时 - 它可能被分片1处理，正在由ProcessorInstance1处理，但是，当应用程序重新启动时 - 它将生成Guid2，它可能被分片处理到正在由ProcessorInstance10处理的Partition10。使用PartitionKey的任何应用程序背后的原则是关联 - 使用相同EventData的所有PartitionKey将落在Same EventHub分区上。但是，这个关键正在被重置 - 这违背了整个目的。
如果操作不成功，将抛出所有SendBatch操作。这是基本保证＆amp;一个不可能的SLA漏洞 - 如果它不扔。我相信，根据您解释的症状，在应用程序部署之后，由于新的Guid将导致事件登陆到不同的分区 - 您可能正在接收来自特定分区的事件。可能会失踪，看到他们＆amp;如果您生成另一个映射到旧分区的Guid，它可能会自动更正...我强烈建议您将partitionKey的地图修复为random Guid。