我有不同类型的活动。例如，有些数据是遥测数据，有些是错误信息等。
我认为创建多个 IEventProcessor 实现是一个好主意，每个实现对应一种事件类型。因此每个实现都会以不同的方式处理事件。就像写入文件或数据库一样。
将事件路由到特定 EventProcessor 的最佳方法是什么？
- 我应该让 EventProcessor 监视特定的分区键吗？如果是，该怎么做？
- 我应该使用 EventProcessorHost 的构造函数来指定消费者组名称吗？如果是这样，我如何使用 EventHubClient 发送到特定的消费者组？我在那里没有看到指定消费者组的选项。
- 我是否应该不执行上述任何操作，只检查传入的事件数据中的特定属性，而忽略我不感兴趣的属性？
我必须说，我发现分区键和消费者组（如果有的话）之间的关系记录得很差。
我使用了选项 2，但到目前为止，每个 EventProcessor 都从所有消费者组名称获取消息，而不仅仅是 EventProcessorHost 构造函数中指定的消息。
好问题！
在回答之前 - 我想重申一下我们在构建 EventHub 时遵循的几个原则。
我们希望事件中心成为高度耐用、高吞吐量的事件摄取管道。虽然我们已经在 Azure 上拥有了现有的 pub-sub 服务，例如队列/主题（类似于 AWS SQS、Google Pub-sub），但提出新服务的主要差异化因素是提供更高吞吐量的变体（当然，具有低延迟）。我们能够实现这个目标 - 代价是 - 我们不执行任何每条消息的计算 - 例如在服务上执行过滤器等。当您需要每条消息的语义时 - 例如每条消息的重复数据删除、每条消息的确认接收，在您的情况下，基于每条消息的属性进行过滤- 并且吞吐量要求较低 - 队列/主题可能是您最好的选择。
我们还预计，发件人（或发布者）的规模要大得多，并且根据场景的不同而有很大差异。所以我们引入了 3 种发送模式（发送、使用 PartitionKey 发送、直接发送到分区）。
因此，在发送时，您会注意到 PartitionKey 的概念 - 它将依次转换为特定分区（将 PartitionKey 视为 EventHub 服务的线索，以计算具有相同 PartitionKey 的所有事件在同一分区上的放置）。但是，在使用事件时，EventHub 不直接公开 PartitionKey 的概念。ConsumerGroups 和 PartitionKey 之间没有关系.
接收者通常只是计算角色，数量有限。因此，我们公开了 1 个通用接收（消费）模式 - 从分区接收。现在，在消费事件时，根据不同的因素可能有不同类型的消费者 - 例如：消费速度（实时与历史），或数据类型 - 因此 - 我们暴露了多个消费者群体。虽然您可以创建 20 个 CG，但我们这里有一个有趣的限制 - 购买的每个吞吐量单位可以产生 1 MBPS 输入和 2 MBPS 输出 - 如果在发送端充分利用，将其限制为 2 个 CG。所以，如果您正在处理完全相同的流，并且有不同的方式来处理每个事件，但每个事件都需要相同的时间来处理 - 那么，使用相同的 ConsumerGroup 更有意义。
回答你的问题：这确实取决于。
以下是一些解决方案：
因为，您的场景中存在多种事件类型 - 您需要预见/决定是否有任何场景需要由单个使用者/处理器读取和处理所有类型的事件。一个例子：我们通常看到的是 - 使用一个 ConsumerGroup 您想要所有错误的计数，而其他消费者组实际上会针对每个错误类型执行特定操作。如果您不需要 - 将每个 EventType 发送到不同的 eventhub，然后使用 1 个消费者组和特定的 IEventProcessor - 是一个选项。
如果您有需要将所有事件发送到同一个 EventHub 的场景，并且如果您知道某些事件类型的处理速度（或需要）非常快 - 您应该考虑使用不同的消费者组，每个消费者组绑定到特定的 IEventProcessor 实现，它将忽略其他 EventType。
例如：如果 ErrorInfo 事件和特殊事件need注意 Real-time，如果由于处理速度慢或峰值负载时间高，遥测数据可以接受 15 分钟 - 我会选择一个 ConsumerGroup 并将其命名为 Real-time 并将其与处理 2 的 IEventProcessor 绑定类型 - 错误和特殊。创建第二个 ConsumerGroup 并将其与处理遥测事件的 IEventProcessor 绑定。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
