1

Ich entwickle zwei WebJobs für azure: Eine, die Nachrichten in die Service Bus Queue mit einem Thema und eine andere, die den ServiceBusTrigger mit dem gleichen Thema abonniert setzt.Microsoft Azure Service Bus-Warteschlange arbeitet als FIFO

Die Nachrichten werden korrekt an die Service-Bus-Warteschlange gesendet, aber wenn der WebJob den ServiceBusTrigger abonniert hat, werden diese Nachrichten nicht auf FIFO-Basis verarbeitet.

Der Code für die WebJob die Nachrichten in den Servicebus Warteschlange setzt, ist der folgende:

NamespaceManager namespaceManager = NamespaceManager.Create(); 

// Delete if exists 
if (namespaceManager.TopicExists("SampleTopic")) 
{ 
    namespaceManager.DeleteTopic("SampleTopic"); 
} 

TopicDescription td = new TopicDescription("SampleTopic"); 
td.SupportOrdering = true; 
TopicDescription myTopic = namespaceManager.CreateTopic(td); 

SubscriptionDescription myAuditSubscription = namespaceManager.CreateSubscription(myTopic.Path, "ImporterSubscription"); 

TopicClient topicClient = TopicClient.Create("SampleTopic"); 
for(int i = 1; i <= 10; i++) 
{ 
    var message = new BrokeredMessage("message"+i);     
    topicClient.Send(message); 
} 
topicClient.Close(); 

Die WebJob die an den Servicebus Triggers subscrited wird, hat den folgenden Code:

namespace HO.Importer.Azure.WebJob.TGZProcessor 
{ 
    public class Program 
    { 
     static void Main(string[] args) 
     { 
      JobHostConfiguration config = new JobHostConfiguration(); 
      config.UseServiceBus(); 
      JobHost host = new JobHost(config); 
      host.RunAndBlock(); 
     } 

     public static void WriteLog([ServiceBusTrigger("SampleTopic", "ImporterSubscription")] string message, 
      TextWriter logger) 
     {     
      Console.WriteLine(message)); 
     } 
    } 
} 

Wie kann ich erreichen, dass die Nachrichten aus der Warteschlange als FIFO verarbeitet werden?

Vielen Dank im Voraus!

Antwort

2

Während Azure Service Bus versuchen kann, FIFO-ähnliche Features bereitzustellen, ist es besser, dieses Verhalten bei einem Broker-basierten Warteschlangensystem nicht anzunehmen. Ben Morris hatte einen guten Beitrag Don’t assume message ordering in Azure Service Bus auf der Tatsache, dass Annahme von Bestellungen mit asynchronem Messaging ist fast ein Fehlschluss und Gründe dafür.

+0

Danke! Was ich tun muss, ist Blobs zu verarbeiten, während sie in einen Container geladen werden. Eine der Voraussetzungen ist, dass sie in der Reihenfolge verarbeitet werden müssen, in der sie zum Blob kommen, so dass ich dachte, dass das Benachrichtigen über eine Service-Bus-Warteschlange, die die Bestellung unterstützen soll, das Problem lösen würde. –

+0

Je nachdem, wie Blobs ankommen, können Sie eine benutzerdefinierte Logik erstellen, um dies zu erreichen. Wenn Sie sicher sind, dass Blobs in Ordnung sind, warum nicht stattdessen einen Blob-Trigger? –

0

Verwenden Sie SessionId oder PartitionKey, um sicherzustellen, dass die Nachricht von demselben Nachrichtenbroker verarbeitet wird.

See: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-partitioning

„SessionId. Wenn eine Nachricht, die die BrokeredMessage.SessionId Eigenschaft festgelegt ist, dann Service Bus verwendet diese Eigenschaft als Partitionsschlüssel Auf diese Weise werden alle Nachrichten, die an der gleichen Sitzung gehören, werden behandelt, indem derselbe Nachrichtenbroker. Dies ermöglicht es Service Bus, die Nachrichtenreihenfolge sowie die Konsistenz der Sitzungszustände zu gewährleisten. "