Freigeben über

Service Bus-Warteschlangen, -Themen und -Abonnements

  • Artikel

Azure Service Bus unterstützt zuverlässige Nachrichtenwarteschlangen und dauerhaftes Veröffentlichen/Abonnieren von Messaging. Den Kern der Messagingfunktionen in Service Bus bilden die folgenden Messagingentitäten: Warteschlangen, Themen und Abonnements.

Wichtig

Wenn Azure Service Bus für Sie neu ist, sollten Sie Was ist Azure Service Bus? lesen, bevor Sie diesen Artikel durcharbeiten.

Warteschlangen

Warteschlangen liefern die Nachrichten im First In, First Out-Verfahren (FIFO) an einen oder mehrere Consumer. Das bedeutet: Nachrichten werden in der Reihenfolge an die Empfänger gesendet und verarbeitet, in der sie der Warteschlange hinzugefügt wurden. Außerdem empfängt und verarbeitet nur ein einziger Consumer jede Nachricht.

Abbildung: Funktionsweise von Dienstwarteschlangen.

Als Hauptvorteil ergibt sich bei der Verwendung von Warteschlangen eine vorübergehende Entkopplung von Anwendungskomponenten. Anders ausgedrückt, die Producer (Absender) und Consumer (Empfänger) müssen Nachrichten nicht gleichzeitig senden und empfangen, da Nachrichten dauerhaft in der Warteschlange gespeichert werden. Außerdem muss der Producer nicht auf eine Antwort vom Consumer warten, um weiterhin Nachrichten zu verarbeiten und zu senden.

Daraus ergibt als weiterer Vorteil ein Lastenausgleich, durch den Producer und Consumer Nachrichten mit unterschiedlichen Raten senden und empfangen können. Bei vielen Anwendungen variiert die Systemauslastung im Lauf der Zeit. Die für jede Arbeitseinheit erforderliche Verarbeitungszeit ist jedoch in der Regel konstant. Durch die Zwischenschaltung einer Warteschlange zwischen Nachrichtenproducer und -consumer reicht es aus, wenn die verbrauchende Anwendung lediglich für die Durchschnittslast anstatt für die Spitzenlast ausgelegt ist. Die Tiefe der Warteschlange erhöht und verringert sich mit der eingehenden Last. Durch diese Funktion sparen Sie direkt Geld, weil Sie weniger Infrastruktur für Ihre Anwendungslast benötigen. Mit zunehmender Last können weitere Arbeitsprozesse hinzugefügt werden, die Nachrichten aus der Warteschlange abrufen. Jede Nachricht wird nur von einem der Arbeitsprozesse verarbeitet. Außerdem ermöglicht dieser pullbasierte Lastenausgleich eine optimale Nutzung der Workercomputer, selbst wenn diese die Nachrichten in der eigenen Verarbeitungsleistung und Maximalgeschwindigkeit abrufen. Dieses Muster nennt man auch konkurrierende Consumer.

Die Verwendung von Warteschlangen als Zwischenglied zwischen Nachrichtenproducern und -consumern sorgt für eine inhärente lockere Kopplung zwischen den Komponenten. Da Producer und Consumer voneinander unabhängig sind, kann ein Upgrade für einen Consumer ohne Auswirkungen auf den Producer durchgeführt werden.

Erstellen von Warteschlangen

Sie können Warteschlangen mithilfe einer der folgenden Optionen erstellen:

Senden und empfangen Sie dann Nachrichten mithilfe von Clients, die in einer der folgenden Programmiersprachen geschrieben wurden:

Empfangsmodi

Sie können zwei verschiedene Modi angeben, in denen Consumer Nachrichten von Service Bus empfangen können.

  • Receive-and-Delete. In diesem Modus wird eine Nachricht als verarbeitet gekennzeichnet und an die Consumeranwendung zurückgegeben, wenn Service Bus die Anforderung vom Consumer empfängt. Dieser Modus stellt das einfachste Modell dar. Er eignet sich am besten für Szenarien, in denen eine Anwendung es toleriert, wenn eine Nachricht beim Auftreten eines Fehlers nicht verarbeitet wird. Beispiel: Ein Consumer stellt eine Empfangsanforderung aus und stürzt dann ab, bevor diese verarbeitet wird. Da Service Bus die Nachricht als verarbeitet markiert, beginnt die Anwendung bei einem Neustart, Nachrichten zu verarbeiten. Sie lässt damit die Meldung aus, die vor dem Absturz verarbeitet wurde. Dieser Vorgang wird häufig als At-Most-Once-Verarbeitung bezeichnet.
  • Peek-Lock. In diesem Modus ist der Empfangsvorgang zweistufig. Dadurch können Anwendungen unterstützt werden, die das Fehlen von Nachrichten nicht tolerieren können.

    1. Es wird die nächste zu verarbeitende Nachricht gesucht, diese wird gesperrt, um zu verhindern, dass andere Consumer sie erhalten, und dann wird sie an die Anwendung zurückgesendet.

    2. Nachdem die Anwendung die Verarbeitung der Nachricht abgeschlossen hat, fordert sie den Service Bus-Dienst auf, die zweite Phase des Empfangsvorgangs abzuschließen. Anschließend wird die Nachricht vom Dienst als verarbeitet markiert.

      Wenn die Anwendung die Nachricht aus irgendeinem Grund nicht verarbeiten kann, kann sie den Service Bus-Dienst auffordern, die Nachricht zu verwerfen. Service Bus entsperrt die Nachricht und macht sie verfügbar, damit sie erneut empfangen werden kann, und zwar entweder von demselben Consumer oder von einem anderen konkurrierenden Consumer. Darüber hinaus ist der Sperre ein Timeout zugeordnet. Wenn die Anwendung die Nachricht nicht vor Ablauf des Sperrtimeouts verarbeiten kann, entsperrt Service Bus die Nachricht und macht sie für den erneuten Empfang verfügbar.

      Falls die Anwendung abstürzt, nachdem die Nachricht verarbeitet wurde, aber bevor der Service Bus-Dienst zum Abschließen der Nachricht aufgefordert wurde, stellt Service Bus die Nachricht erneut an die Anwendung zu, wenn diese neu gestartet wird. Dieser Vorgang wird häufig als At-Least-Once-Verarbeitung bezeichnet. Dies bedeutet, dass jede Nachricht mindestens einmal verarbeitet wird. In bestimmten Situationen wird dieselbe Nachricht jedoch möglicherweise erneut zugestellt. Wenn eine doppelte Verarbeitung in Ihrem Szenario nicht zulässig ist, fügen Sie der Anwendung zusätzliche Logik zur Erkennung doppelter Nachrichten hinzu. Weitere Informationen finden Sie unter Duplikaterkennung, die als Exactly-Once-Verarbeitung bezeichnet wird.

      Hinweis

      Weitere Informationen zu diesen beiden Modi finden Sie unter Abgleichen von Empfangsvorgängen.

Themen und Abonnements

Eine Warteschlange ermöglicht die Verarbeitung einer Nachricht durch einen einzelnen Consumer. Im Gegensatz zu Warteschlangen bieten Themen und Abonnements eine 1:n-Kommunikation in einem Muster vom Typ Veröffentlichen/Abonnieren. Dies ist nützlich für die Skalierung auf eine große Anzahl von Empfängern. Jede veröffentlichte Nachricht wird für jedes beim Thema registrierte Abonnement verfügbar gemacht. Der Herausgeber sendet eine Nachricht an ein Thema, und mindestens ein Abonnent erhält eine Kopie der Nachricht.

Abbildung: Service Bus-Thema mit drei Abonnements.

Herausgeber senden Nachrichten auf die gleiche Weise an ein Thema, wie sie Nachrichten an eine Warteschlange senden. Allerdings erhalten Consumer die Nachrichten nicht direkt vom Thema. Stattdessen erhalten Consumer die Nachrichten über Abonnements des Themas. Ein Themenabonnement ist mit einer virtuellen Warteschlange vergleichbar, die Kopien der an das Thema gesendeten Nachrichten empfängt. Consumer empfangen Nachrichten von einem Abonnement auf die gleiche Weise wie von einer Warteschlange. Die Sendefunktionalität einer Warteschlange ist mit der eines Themas identisch, und die Empfangsfunktionalität entspricht einem Abonnement. Diese Funktion bedeutet unter anderem, dass die Abonnements das weiter oben in diesem Abschnitt beschriebene Muster hinsichtlich Warteschlangen unterstützen: konkurrierender Verbraucher, vorübergehende Entkopplung, Belastungsausgleich und Lastenausgleich.

Für Abonnements kann definiert werden, welche Nachrichten von einem Thema empfangen werden sollen. Diese Nachrichten werden in Form von benannten Abonnementregeln angegeben. Jede Regel besteht aus einer Filterbedingung, mit der bestimmte Nachrichten ausgewählt werden, und kann optional eine Aktion enthalten, mit der die ausgewählte Nachricht kommentiert wird. Standardmäßig empfängt ein Abonnement eines Themas alle Nachrichten, die an das Thema gesendet werden. Das Abonnement verfügt über eine anfängliche Standardregel mit einem aktivierten Filter (TRUE), mit dem alle Nachrichten im Abonnement ausgewählt werden können. Der Standardregel ist keine Aktion zugeordnet. Sie können Filter mit Regeln und Aktionen für ein Abonnement definieren, sodass das Abonnement nur eine Teilmenge der Nachrichten empfängt, die an das Thema gesendet werden.

Weitere Informationen zu Filtern finden Sie unter Filter und Aktionen.

Erstellen von Themen und Abonnements

Das Erstellen eines Themas ähnelt dem Erstellen einer Warteschlange (siehe vorheriger Abschnitt). Sie können Themen und Abonnements mithilfe einer der folgenden Optionen erstellen:

Senden Sie dann Nachrichten an ein Thema, und empfangen Sie Nachrichten von Abonnements mithilfe von Clients, die in Programmiersprachen wie den folgenden geschrieben wurden:

Regeln und Aktionen

In vielen Fällen müssen Nachrichten mit bestimmten Merkmalen auf unterschiedliche Weise verarbeitet werden. Um dies zu ermöglichen, können Sie Abonnements so konfigurieren, dass sie nach Nachrichten mit bestimmten Eigenschaften suchen und dann bestimmte Änderungen an diesen Eigenschaften vornehmen. Auch wenn Service Bus-Abonnements alle Nachrichten angezeigt werden, die an das Thema gesendet wurden, kann nur eine Teilmenge dieser Nachrichten in die virtuelle Abonnementwarteschlange kopiert werden. Diese Filterung wird mithilfe von Abonnementfiltern erreicht. Solche Änderungen werden als Filteraktionen bezeichnet. Beim Erstellen eines Abonnements können Sie einen Filterausdruck angeben, der auf die Eigenschaften der Nachricht angewandt wird. Die Eigenschaften können Systemeigenschaften (z. B. Label) und benutzerdefinierte Anwendungseigenschaften (z. B. StoreName) sein. Der SQL-Filterausdruck ist in diesem Fall optional. Ohne SQL-Filterausdruck wird jede für ein Abonnement definierte Filteraktion auf alle Nachrichten in diesem Abonnement angewandt.

Ein voll funktionsfähiges Beispiel finden Sie im TopicFilters-Beispiel auf GitHub. Weitere Informationen zu Filtern finden Sie unter Themenfilter und -aktionen.

Java Message Service 2.0-Entitäten (JMS)

Auf die folgenden Entitäten kann über die JMS 2.0-API (Java Message Service) zugegriffen werden.

  • Temporäre Warteschlangen
  • Temporäre Themen
  • Freigegebene dauerhafte Abonnements
  • Nicht freigegebene dauerhafte Abonnements
  • Freigegebene nicht dauerhafte Abonnements
  • Nicht freigegebene nicht dauerhafte Abonnements

Erfahren Sie mehr über die JMS 2.0-Entitäten und darüber, wie Sie diese verwenden.

Expressentitäten

Express-Entitäten wurden für Szenarien mit hohem Durchsatz und reduzierter Latenz erstellt. Mit Expressentitäten wird eine Nachricht, die an eine Warteschlange oder ein Thema gesendet wird, nicht sofort im Nachrichtenspeicher abgelegt. Stattdessen wird die Nachricht zunächst im Arbeitsspeicher zwischengespeichert. Nachrichten, die in der Entität verbleiben, werden nach einer Verzögerung in den Nachrichtenspeicher geschrieben, an dem diese aufgrund eines Ausfalls vor Verlust geschützt sind.

In regulären Entitäten wird jeder Laufzeitvorgang (z. B. Send, Complete, Abandon, Deadletter) zuerst im Speicher beibehalten, und erst nach erfolgreicher Bestätigung für den Client. In Expressentitäten wird ein Laufzeitvorgang zuerst für den Client als erfolgreich anerkannt und erst später im Speicher beibehalten. Wenn ein Computerneustart auftritt oder ein Hardwareproblem auftritt, werden einige anerkannte Laufzeitvorgänge möglicherweise überhaupt nicht beibehalten. Dies bedeutet, dass der Client eine niedrigere Latenz und einen höheren Durchsatz mit Expressentitäten erhält, auf Kosten potenzieller Datenverluste und/oder erneuter Zustellung von Nachrichten.

Darüber hinaus wurden im Laufe der Zeit viele Optimierungen innerhalb von Service Bus durchgeführt, was bedeutet, dass der Durchsatz und die Latenzvorteile von Expressentitäten derzeit minimal sind. Darüber hinaus unterstützt die Premium-Dienstebene keine Express-Entitäten. Aus diesem Grund wird derzeit nicht empfohlen, dieses Feature zu verwenden.

Nächste Schritte

Probieren Sie die Beispiele in der Sprache Ihrer Wahl aus:

Verwenden Sie für Beispiele, die die älteren .NET- und Java-Clientbibliotheken verwenden, die folgenden Links:

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.