Freigeben über


Service Bus-Warteschlangen, -Themen und -Abonnements

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.

In diesem Artikel werden diese Zentralen Messagingentitäten, ihre Vorteile und die Verwendung der einzelnen Entitäten in Ihrer Anwendungsarchitektur erläutert.

Wichtig

Wenn Sie noch nicht mit Azure Service Bus arbeiten, lesen Sie die Einführung in Azure Service Bus , bevor Sie diesen Artikel durchgehen.

Auswählen zwischen Warteschlangen und Themen

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen Warteschlangen und Themen zusammengefasst, die Ihnen bei der Auswahl der richtigen Messaging-Entität für Ihr Szenario helfen.

Merkmal Warteschlangen Themen und Abonnements
Kommunikationsmuster Punkt-zu-Punkt Veröffentlichen/Abonnieren (eins-zu-viele)
Nachrichtenübermittlung Ein einzelner Verbraucher pro Nachricht Mehrere Abonnenten können Kopien empfangen
Anwendungsfall Aufgabenverteilung, Kapazitätsabgleich Ereignisübertragung, Fanoutszenarien
Filterung Nicht unterstützt Abonnementfilter für die selektive Nachrichtenübermittlung

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.

Diagramm einer Servicebus-Warteschlange mit Nachrichten, die von Absendern zur Warteschlange und dann zu Empfängern fließen.

Vorteile der Verwendung von Warteschlangen

Nutzen Description
Zeitliche Entkopplung Produzenten (Absender) und Verbraucher (Empfänger) müssen nachrichten nicht gleichzeitig senden und empfangen, da Nachrichten dauerhaft in der Warteschlange gespeichert werden. Der Produzent muss nicht warten, bis eine Antwort des Verbrauchers weiter verarbeitet wird.
Kapazitätsausgleich Produzenten und Verbraucher können Nachrichten zu unterschiedlichen Tarifen senden und empfangen. Die verbrauchende Anwendung muss nur die durchschnittliche Last anstelle der Spitzenlast verarbeiten, wodurch Infrastrukturkosten gespart werden.
Konkurrierende Verbraucher Mehrere Arbeitsprozesse können aus der Warteschlange gelesen werden, wobei jede Nachricht von nur einem Mitarbeiter verarbeitet wird. Mit diesem pull-basierten Lastenausgleich können die Mitarbeiter mit ihrer eigenen maximalen Geschwindigkeit arbeiten.
Lose Kopplung Da Produzenten und Verbraucher einander nicht bewusst sind, kann ein Verbraucher ohne Auswirkungen auf den Hersteller aktualisiert 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.

Empfangs- und Löschmodus

Wenn der Service Bus die Anforderung des Konsumenten empfängt, kennzeichnet er die Nachricht als verbraucht und gibt sie an die Konsumentenanwendung zurück. Dieser Modus ist das einfachste Modell und eignet sich am besten für Szenarien, in denen die Anwendung keine Nachricht verarbeiten kann, wenn ein Fehler auftritt.

Wenn der Verbraucher vor der Verarbeitung der Nachricht abstürzt, geht die Nachricht verloren, da der Dienstbus sie bereits als verbraucht markiert hat. Dieser Vorgang wird häufig als At-Most-Once-Verarbeitung bezeichnet.

Vorschausperrmodus

Der Empfangsvorgang wird zweistufig, sodass Anwendungen unterstützt werden, die fehlende Nachrichten nicht tolerieren können.

  1. Sucht die nächste zu verwendende Nachricht, sperrt sie, um zu verhindern, dass andere Verbraucher sie erhalten, und gibt dann die Nachricht an die Anwendung zurück.
  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.

Behandlung von Fehlern im Peek-Lock-Modus:

  • Verwerfen (Abandon): Wenn die Anwendung die Nachricht nicht verarbeiten kann, kann sie den Service Bus auffordern, die Nachricht zu verwerfen (abandon). Der Servicebus entsperrt die Nachricht und macht sie wieder verfügbar.
  • Sperrtimeout: Wenn die Anwendung die Nachricht nicht verarbeiten kann, bevor das Sperrtimeout abläuft, entsperrt Service Bus die Nachricht und stellt sie wieder zur Verfügung, damit sie erneut empfangen werden kann.
  • Anwendungsabsturz: Wenn die Anwendung nach der Verarbeitung der Nachricht abstürzt, aber bevor sie abgeschlossen wurde, wird die Nachricht von Service Bus erneut angezeigt, wenn die Anwendung neu gestartet wird. Dieser Vorgang wird häufig als At-Least-Once-Verarbeitung bezeichnet.

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.

Diagramm eines ServiceBus-Themas mit drei Abonnements, die Kopien von Nachrichten erhalten.

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.

Abonnementfilter

Abonnements können definieren, 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 enthält optional eine Aktion, mit der die ausgewählte Nachricht kommentiert wird. Standardmäßig empfängt ein Abonnement eines Themas alle Nachrichten, die an das Thema gesendet werden. Für das Abonnement ist eine erste Standardregel mit dem Filter „true“ angegeben, der bewirkt, dass alle Nachrichten in das Abonnement gewählt werden können. Der Standardregel ist keine Aktion zugeordnet. Sie können für ein Abonnement Filter mit Regeln und Aktionen 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 diese Verarbeitung zu aktivieren, können Sie Abonnements so konfigurieren, dass Nachrichten mit den gewünschten Eigenschaften gesucht und dann bestimmte Änderungen an diesen Eigenschaften vorgenommen werden. 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 geteilte, nicht dauerhafte Abonnements

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

Expressentitäten

Wichtig

Express-Entitäten werden für neue Anwendungen nicht empfohlen. Die Vorteile von Durchsatz und Latenz sind aufgrund von Optimierungen im Service Bus derzeit minimal. Die Premium-Ebene von ServiceBus unterstützt keine Express-Entitäten.

Express-Entitäten wurden für Szenarien mit hohem Durchsatz und reduzierter Latenz erstellt. Bei Expressentitäten, wenn eine Nachricht an eine Warteschlange oder ein Thema gesendet wird, wird sie nicht sofort im Nachrichtenspeicher gespeichert. 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 sie 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 gespeichert, und erst nachdem der Vorgang dem Client gegenüber als erfolgreich bestätigt wird. In Expressentitäten wird ein Laufzeitvorgang zuerst für den Client als erfolgreich anerkannt und erst später im Speicher beibehalten. Wenn ein Computer neu gestartet wird oder ein Hardwareproblem auftritt, werden einige anerkannte Laufzeitvorgänge möglicherweise überhaupt nicht beibehalten. In diesem Fall erhält der Client eine niedrigere Latenz und einen höheren Durchsatz mit Expressentitäten, auf Kosten potenzieller Datenverluste und/oder Neubelebung von Nachrichten.

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.