Azure Service Bus，使用过滤器组装一条大消息，分解为较小的消息

Question

我正在尝试寻找在 Azure 服务总线上接收大消息的解决方案。我想到的基本模式是分部分发布一条大消息——以及相关 ID、页面和“of”。

因此，如果我有一条由四部分组成的消息，它们都将具有相同的相关 ID，每个消息的“of”为 4，页面将为 0 - 3。该集合将作为批次发布。

监听器可以只监听page为0的消息，然后根据事务id拉取剩余的消息。

发布这些消息非常容易。 ServiceBusMessage 有一个 CorrelationId 字段和一个名为 ApplicationProperties 的字典字段，我可以将自定义“page”和“of”字段添加到其中。我可以在发布之前将它们组装成 ServiceBusMessageBatch。

我不确定如何接收消息。我正在使用 Function Apps，因此设置侦听器很容易。

[FunctionName("GeneralLogger")]
public static void Run([ServiceBusTrigger("queueName", Connection = "AzureWebJobsServiceBus")] string myQueueItem, ApplicationProperties ap, ILogger log)
{ /// process message }

但我不知道如何在这里过滤。另外，我可以通过向消息处理器添加处理程序来提取消息，如下所述：https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-get-started-with-queues 但同样我也不知道如何进行过滤。

我看到的唯一 Azure 服务总线过滤是在主题和订阅之间进行的。那里有很多功能，但在运行时我无法动态设置任何内容。

我觉得我要么试图错过某些东西，要么重新发明轮子。还有其他人使用 Azure 服务总线做类似的事情吗？

Answer 1

我正在尝试找到用于在Azure服务总线上接收大消息的解决方案。

解决方案已经存在。这是Azure服务总线。能够以大小为100MB的消息发送。它带有价格。假设您想吐出文件，因为溢价要花很多钱，或者是因为消息可能大于100MB，那么索赔检查模式是必不可少的。当高级层上使用索赔检查模式时，只有一个问题 - 当消息是事件时，您无法确定性清理，并且有多个接收器。鉴于这些斑点是大斑点，您需要提出一些策略来清理这些斑点，并且会随着时间的流逝而迅速增加存储消耗，具体取决于流过系统的消息数量。使用高级层，不存在清理问题。您也不需要提供存储帐户。因此，如果您的大信息不会超过100MB，则可能是您生产环境的更合适的解决方案。

Answer 2

不可能在队列上应用过滤器；他们仅对主题/订阅进行操作。

一般来说，当您想要发送对于单个消息来说太大的有效负载。简而言之，您可以将有效负载写入某种形式的持久存储，然后您的服务总线消息将为消费者提供位置。

使用 Azure.Messaging.ServiceBus 包的示例实现可以在 此示例。