Azure 服務總線，使用過濾器將大消息組合成更小的消息

Question

我試圖找到一種解決方案，用於在 Azure 服務總線上接收大消息。 我考慮的基本模式是分幾部分發布大量消息——連同關聯 ID、頁面和“of”。

因此，如果我有一個由四部分組成的消息，它們都將具有相同的相關 ID，每個都具有 4 的“of”，並且頁面將為 0 - 3。該集合將作為批次發布。

監聽器可以只監聽頁面為0的消息，然后根據事務id拉取剩余的消息。

發布這些消息很容易。 ServiceBusMessage 有一個 CorrelationId 字段和一個名為 ApplicationProperties 的字典字段，我可以將我的自定義“page”和“of”字段添加到其中。 我可以在發布之前將它們組裝成一個 ServiceBusMessageBatch。

我不確定的是如何接收消息。 我正在使用 Function 應用程序，因此很容易設置監聽器。

[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-do.net-get- started-with-queues但同樣我不知道如何過濾。

Azure 我看到的唯一服務總線過濾是在主題和訂閱之間進行的。 那里有很多功能，但我無法在運行時動態設置。

我覺得我要么試圖錯過使用某些東西，要么重新發明輪子。 還有其他人使用 Azure 服務總線做這樣的事情嗎？

Answer 1

我試圖找到一種解決方案，用於在 Azure 服務總線上接收大消息。

解決方案已經存在。 它是 Azure Service Bus 高級層。 能夠發送最大 100MB 的消息。 它是有代價的。 假設您因為要支付高昂的保費或因為消息可能大於 100MB 而想要吐出文件，那么聲明檢查模式就是通往 go 的方式。只有一個問題是聲明檢查模式是在高級層上使用 - 當消息是一個事件並且有多個接收者時，您無法進行確定性清理。 您需要制定一些策略來清理這些 blob，因為這些 blob 很大，並且會隨着時間的推移迅速增加存儲消耗，具體取決於流經系統的消息數量。 使用高級層，不存在清理問題。 您也不必提供存儲帳戶。 因此，如果您的大消息不會超過 100MB，它可能是更適合您的生產環境的解決方案。

Answer 2

無法在隊列上應用過濾器； 他們只對主題/訂閱進行操作。

通常，當您希望發送對於單個消息而言過大的負載時，建議使用Claim Check模式。 簡而言之，您會將有效負載寫入某種形式的持久存儲，然后您的服務總線消息將為消費者提供位置。

可以在此示例中找到使用Azure.Messaging.ServiceBus package 的示例實現。