应用程序在启动时将EventData.PartitionKey 的值设置为新的Guid。因此，对于每个新部署，分区密钥都会发生变化。
我了解事件中心利用散列机制将消息路由到特定分区。重新生成分区密钥是否会以任何有害的方式阻碍或影响此机制？
我不时注意到，在多次部署后，消息不会出现在事件中心（无论过去了多少时间），尽管底层的 EventHubClient.SendBatchAsync 方法不会引发 Exception。这种行为似乎可以任意纠正自己。
【问题讨论】：
标签： azure partitioning azure-eventhub
影响将是：每次您的应用重新启动时 - 消息可能会落在完全不同的分区中 - 因为新的 Guid 可能会散列到不同的 EventHub 分区。
这不会以任何方式损害 EventHub 的性能。您可以根据需要生成任意数量的 PartitionKey。
但是，使用这些事件的应用程序会受到影响：通常会有一个 Worker 处理来自单个分区的事件（EventHubs 分区是事件处理器处理事件的规模单位事件中心）。当您的应用程序以 Guid1 启动时 - 它可能会散列到由 ProcessorInstance1 处理的 Partition1，但是，当应用程序重新启动时 - 它会生成 Guid2，它可能会散列到由 ProcessorInstance10 处理的 Partition10。使用PartitionKey 的任何应用程序背后的原则是Correlation - 所有使用相同PartitionKey 的EventData 都将落在相同的EventHub 分区上。但是，这把钥匙正在被重置——这违背了整个目的。
如果操作不成功，所有SendBatch 操作都会抛出。这是基本保证和不可能的 SLA 违反 - 如果它不抛出。我相信，从您解释的症状来看，在应用程序部署之后，由于新的 Guid 将导致事件登陆不同的分区 - 您可能会收到来自特定分区的事件并且可能会看不到它们并且它可能会自动更正如果您生成另一个映射到旧分区的 Guid... 我强烈建议将 partitionKey 的 Map 修复为 randomGuid。
【讨论】：
Stream 和 Event Hubs 运行了多长时间，任何给定的静态值（例如 IP 地址）都将始终映射到相同的基于底层哈希机制的分区？
Event Hub Throughput-Unit 计数是否可能必须等于 Stream Analytics Streaming Unit 计数才能正确同步？我可以断定消息丢失的唯一情况是，如果 Stream Analytics 明确连接到特定的 Event Hub Partitions。
Stream Analytics 专家.. 但是，从描述 - 朝那个方向调查 - 配置 Stream Analytics 以从所有 Partitions 中提取？。