Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
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:
- Azure-Portal
- PowerShell
- BEFEHLSZEILENSCHNITTSTELLE (CLI)
- Azure Resource Manager-Vorlagen (ARM-Vorlagen)
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.
- 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.
- 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.
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:
- Azure Service Bus-Clientbibliotheksbeispiele für .NET (neueste Version)
- Azure Service Bus-Clientbibliotheksbeispiele für Java (neueste Version)
- Azure Service Bus-Clientbibliotheksbeispiele für Python
- Azure Service Bus-Clientbibliotheksbeispiele für JavaScript
- Azure Service Bus-Clientbibliotheksbeispiele für TypeScript
Verwenden Sie für Beispiele, die die älteren .NET- und Java-Clientbibliotheken verwenden, die folgenden Links:
- Azure Service Bus-Clientbibliotheksbeispiele für .NET (Legacy)
- Azure Service Bus-Clientbibliotheksbeispiele für Java (Legacy)
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.