Nachrichtensitzungen
Azure Service Bus-Sitzungen ermöglichen die gemeinsame und geordnete Verarbeitung unbegrenzter Sequenzen verwandter Nachrichten. Sitzungen können mit FIFO-Mustern (First in, First Out) und Anforderung/Antwort-Mustern verwendet werden. In diesem Artikel wird gezeigt, wie Sie diese Muster mithilfe von Sitzungen implementieren, wenn Sie Service Bus verwenden.
Hinweis
Der Basic-Tarif von Service Bus unterstützt keine Sitzungen. Die Standard- und Premium-Tarife unterstützen Sitzungen. Informationen zu den Unterschieden zwischen diesen Tarifen finden Sie unter Service Bus-Preise.
FIFO-Muster (First in, First Out)
Verwenden Sie Sitzungen, um eine FIFO-Garantie bei der Verarbeitung von Nachrichten in Service Bus-Warteschlangen oder -Abonnements umzusetzen. Service Bus macht keine Vorgaben zur Art der Beziehung zwischen Nachrichten und definiert auch kein bestimmtes Modell zur Bestimmung, wo eine Nachrichtensequenz beginnt oder endet.
Jeder Absender kann eine Sitzung erstellen, wenn er Nachrichten an ein Thema oder eine Warteschlange sendet, indem er die Eigenschaft Sitzungs-ID auf einen von der Anwendung definierten Bezeichner festlegt, der für die Sitzung eindeutig ist. Auf der AMQP 1.0-Protokollebene ist dieser Wert der group-id-Eigenschaft zugeordnet.
Bei sitzungsabhängigen Warteschlangen oder Abonnements entstehen Sitzungen, wenn mindestens eine Nachricht mit der Sitzungs-ID vorhanden ist. Sobald eine Sitzung vorhanden ist, gibt es keine definierte Uhrzeit oder API für den Zeitpunkt, an dem die Sitzung abläuft oder erlischt. Theoretisch kann eine Nachricht für eine Sitzung heute und die nächste Nachricht in einem Jahr empfangen werden. Wenn die Sitzungs-ID übereinstimmt, ist die Sitzung aus Service Bus-Sicht identisch.
Typischerweise verfügt eine Anwendung jedoch über klare Informationen dazu, wo eine Reihe zusammengehöriger Nachrichten beginnt und endet. Service Bus legt allerdings keine spezifischen Regeln fest. Ihre Anwendung kann die Label-Eigenschaft beispielsweise für die erste Nachricht auf start festlegen, für die Zwischennachrichten auf content und für die letzte Nachricht auf end. Die relative Position der content-Nachrichten kann als SequenceNumber-Delta der aktuellen Nachricht von der SequenceNumber der Start-Nachricht berechnet werden.
Wichtig
Wenn Sitzungen für eine Warteschlange oder ein Abonnement aktiviert sind, können die Clientanwendungen keine regulären Nachrichten mehr senden oder empfangen. Alle Nachrichten müssen im Rahmen einer Sitzung (durch Festlegen der Sitzungs-ID) gesendet und durch Akzeptieren der Sitzung empfangen werden. Clients können weiterhin eine Warteschlange oder ein Abonnement mit aktivierten Sitzungen einsehen. Weitere Informationen finden Sie unter Einsehen von Nachrichten.
Die APIs für Sitzungen sind für Warteschlangen- und Abonnementclients vorhanden. Es gibt ein verbindliches Modell, das steuert, wann Sitzungen und Nachrichten empfangen werden, und ein auf einem Handler basierendes Modell, das die Komplexität bei der Verwaltung der Empfangsschleife verbirgt.
Beispiele finden Sie unter den Links im Abschnitt Nächste Schritte.
Sitzungsfeatures
Sitzungen ermöglichen das gleichzeitige Demultiplexing von verschachtelten Nachrichtenströmen unter Beibehaltung und Gewährleistung der geordneten Zustellung.
Ein Sitzungsempfänger wird von einem Client erstellt, der eine Sitzung akzeptiert. Wenn die Sitzung von einem Client akzeptiert und aufrechterhalten wird, hält der Client eine exklusive Sperre für alle Nachrichten mit der Sitzungs-ID dieser Sitzung, die in der Warteschlange oder im Abonnement vorhanden sind. Er hält exklusive Sperren für alle Nachrichten mit der Sitzungs-ID, die später eingehen.
Die Sperre wird freigegeben, wenn Methoden für Schließvorgänge auf der Empfängerseite aufgerufen werden oder die Sperre abläuft. Auf der Empfängerseite sind auch Methoden zum Verlängern der Sperren verfügbar. Sie können stattdessen das Feature für die automatische Verlängerung von Sperren verwenden und dort den Zeitraum angeben, für den die Sperre verlängert werden soll. Die Sitzungssperre sollte wie eine exklusive Sperre für eine Datei behandelt werden, d. h. die Anwendung muss die Sitzung schließen, sobald sie diese nicht mehr benötigt und/oder keine weiteren Nachrichten erwartet.
Wenn mehrere gleichzeitige Empfänger auf die Warteschlange zugreifen, werden die zu einer bestimmten Sitzung gehörenden Nachrichten an den spezifischen Empfänger gesendet, der gerade die Sperre für diese Sitzung hält. Mit diesem Vorgang erfolgt für einen geschachtelten Nachrichtendatenstrom, der sich in einer Warteschlange oder einem Abonnement befindet, ein ordnungsgemäßes Demultiplexing an verschiedene Empfänger. Diese Empfänger können sich auch auf verschiedenen Clientcomputern befinden, da die Sperrverwaltung in Service Bus auf Dienstseite erfolgt.
Die vorherige Abbildung zeigt drei gleichzeitige Sitzungsempfänger. Eine Sitzung mit SessionId = 4 verfügt über keinen aktiven, besitzenden Client, was bedeutet, dass von dieser bestimmten Sitzung keine Nachrichten übermittelt werden. Eine Sitzung fungiert in vielerlei Hinsicht wie eine untergeordnete Warteschlange.
Die vom Sitzungsempfänger gehaltene Sitzungssperre ist ein Schirm für die Nachrichtensperren, die vom peek-lock-Abstimmungsmodus verwendet werden. Nur ein Empfänger kann eine Sperre für eine Sitzung haben. Ein Empfänger könnte viele übermittelte Nachrichten haben, aber die Nachrichten werden der Reihe nach empfangen. Das Abbrechen einer Nachricht bewirkt, dass dieselbe Nachricht beim nächsten Empfangsvorgang erneut abgearbeitet wird.
Nachrichtensitzungszustand
Wenn Workflows in umfangreichen, hochverfügbaren Cloudsystemen verarbeitet werden, muss der zu einer bestimmten Sitzung gehörende Workflowhandler in der Lage sein, unerwartete Fehler zu beheben. Er kann teilweise abgeschlossene Aufgaben in einem anderen Prozess oder auf einem anderen Computer, auf dem die Aufgabe begonnen hat, fortsetzen.
Der Sitzungszustand ermöglicht eine von der Anwendung definierte Anmerkung einer Nachrichtensitzung innerhalb des Brokers, sodass der aufgezeichnete Verarbeitungszustand in Bezug auf diese Sitzung sofort verfügbar wird, sobald die Sitzung von einem neuen Prozessor übernommen wird.
Aus Service Bus-Sicht ist der Nachrichtensitzungszustand ein undurchsichtiges binäres Objekt, das Daten von der Größe einer Nachricht aufnehmen kann, die bei Service Bus Standard 256 KB und bei Service Bus Premium 100 MB beträgt. Der Verarbeitungszustand relativ zu einer Sitzung kann innerhalb des Sitzungszustands gespeichert werden, oder der Sitzungszustand kann auf einen Speicherort oder Datenbankdatensatz verweisen, der solche Informationen enthält.
Die Methoden zum Verwalten des Sitzungszustands – SetState und GetState – befinden sich im Sitzungsempfängerobjekt. Eine Sitzung, für die zuvor kein Sitzungszustand festgelegt wurde, gibt für GetState einen Nullverweis zurück. Der zuvor festgelegte Sitzungszustand kann durch Übergeben von NULL an die SetState-Methode auf der Empfängerseite gelöscht werden.
Der Sitzungszustand bleibt erhalten, bis er gelöscht wird (Rückgabe: NULL), auch wenn alle Nachrichten in einer Sitzung verarbeitet werden.
Der Sitzungszustand, der in einer Warteschlange oder in einem Abonnement gespeichert ist, wird auf das Speicherkontingent dieser Entität angerechnet. Wenn die Anwendung mit einer Sitzung fertig ist, empfiehlt es sich daher für die Anwendung, ihren beibehaltenen Zustand zu bereinigen, um externe Verwaltungskosten zu vermeiden.
Auswirkungen der Übermittlungsanzahl
Die Definition der Übermittlungsanzahl pro Nachricht im Kontext von Sitzungen weicht geringfügig von der Definition bei fehlenden Sitzungen ab. Die folgende Tabelle enthält eine Zusammenfassung der Umstände, unter denen die Übermittlungsanzahl erhöht wird:
| Szenario | Übermittlungsanzahl der Nachricht inkrementiert? |
|---|---|
| Die Sitzung wird akzeptiert, aber die Sitzungssperre läuft ab (aufgrund eines Timeouts). | Ja |
| Die Sitzung wird akzeptiert, die Nachrichten innerhalb der Sitzung werden nicht abgeschlossen (selbst wenn sie gesperrt sind), und die Sitzung wird geschlossen. | Nein |
| Die Sitzung wird akzeptiert, Nachrichten werden abgeschlossen, und die Sitzung wird explizit geschlossen. | Nicht zutreffend (Standardflow. Hier werden die Nachrichten aus der Sitzung entfernt.) |
Anforderung/Antwort-Muster
Das Anforderung/Antwort-Muster ist ein etabliertes Integrationsmuster, das es der sendenden Anwendung ermöglicht, eine Anforderung zu senden, und dem Empfänger die Möglichkeit bietet, eine Antwort ordnungsgemäß an die Absenderanwendung zurückzusenden. Dieses Muster benötigt in der Regel eine kurzlebige Warteschlange oder ein kurzlebiges Thema, an die bzw. das die Anwendung Antworten senden soll. In diesem Szenario stellen Sitzungen eine einfache alternative Lösung mit vergleichbarer Semantik dar.
Mehrere Anwendungen können ihre Anforderungen an eine einzelne Anforderungswarteschlange senden, wobei ein spezifischer Headerparameter zur eindeutigen Identifizierung der Absenderanwendung festgelegt wird. Die Empfängeranwendung kann die in der Warteschlange eingehenden Anforderungen verarbeiten und Antworten in der sitzungsfähigen Warteschlange senden. Dabei wird die Sitzungs-ID auf den eindeutigen Bezeichner festgelegt, den der Absender in der Anforderungsnachricht gesendet hatte. Die Anwendung, die die Anforderung gesendet hat, kann dann Nachrichten mit der bestimmten Sitzungs-ID empfangen und die Antworten ordnungsgemäß verarbeiten.
Hinweis
Die Anwendung, die die ersten Anforderungen sendet, muss die Sitzungs-ID kennen und diese verwenden, um die Sitzung zu akzeptieren, damit die Sitzung, in der sie die Antwort erwartet, gesperrt wird. Es empfiehlt sich, eine GUID zu verwenden, die die Instanz der Anwendung eindeutig als Sitzungs-ID identifiziert. Um sicherzustellen, dass die Antworten durch bestimmte Empfänger gesperrt und verarbeitet werden können, darf kein Sitzungshandler oder -timeout auf der Seite des Sitzungsempfängers für die Warteschlange festgelegt sein.
Sequenzierung im Vergleich zu Sitzungen
Die Sequenznummer an sich garantiert die Warteschlangenreihenfolge und die Extraktionsreihenfolge von Nachrichten, aber nicht die Verarbeitungsreihenfolge. Dafür sind Sitzungen erforderlich.
Angenommen, es gibt drei Nachrichten in der Warteschlange und zwei Consumer.
- Consumer 1 ruft Nachricht 1 ab.
- Consumer 2 ruft Nachricht 2 ab.
- Consumer 2 beendet die Verarbeitung von Nachricht 2 und ruft Nachricht 3 ab, während Consumer 1 die Verarbeitung von Nachricht 1 noch nicht abgeschlossen hat.
- Consumer 2 hat die Verarbeitung von Nachricht 3 abgeschlossen, Consumer 1 die Verarbeitung von Nachricht 1 jedoch noch nicht.
- Schließlich schließt Consumer 1 die Verarbeitung von Nachricht 1 ab.
Die Nachrichten werden also in dieser Reihenfolge verarbeitet: Nachricht 2, Nachricht 3 und Nachricht 1. Wenn die Nachrichten 1, 2 und 3 der Reihe nach verarbeitet werden müssen, müssen Sie Sitzungen verwenden.
Wenn Nachrichten nur der Reihe abgerufen werden müssen, müssen Sie keine Sitzungen verwenden. Wenn Nachrichten in der richtigen Reihenfolge verarbeitet werden müssen, verwenden Sie Sitzungen. Für Nachrichten, die zusammengehören, muss die gleiche Sitzungs-ID festgelegt werden. Dies können die Nachrichten 1, 4 und 8 in einer Gruppe und 2, 3 und 6 in einer anderen Gruppe sein.
Nachrichtenablauf
Für sitzungsfähige Warteschlangen oder Themenabonnements werden Nachrichten auf Sitzungsebene gesperrt. Wenn die TTL (time-to-live) für eine der Nachrichten abläuft, werden je nachdem, ob in der Einstellung für den Nachrichtenablauf für die Entität unzustellbare Nachrichten aktiviert sind oder nicht, alle mit dieser Sitzung in Zusammenhang stehenden Nachrichten entweder verworfen oder als unzustellbare Nachrichten behandelt. Anders ausgedrückt: Wenn in der Sitzung eine einzelne Nachricht vorhanden ist, die die TTL bestanden hat, sind alle Nachrichten in der Sitzung abgelaufen. Die Nachrichten laufen nur ab, wenn ein aktiver Listener vorhanden ist. Weitere Informationen finden Sie unter Nachrichtenablauf.
Nächste Schritte
Sie können Nachrichtensitzungen im Zuge der Erstellung einer Warteschlange per Azure-Portal, PowerShell, CLI, Resource Manager-Vorlage, .NET, Java, Python und JavaScript aktivieren. Weitere Informationen finden Sie unter Aktivieren von Nachrichtensitzungen für eine Azure Service Bus-Warteschlange oder ein Abonnement.
Sehen Sie sich die Beispiele in der Sprache Ihrer Wahl an, um sich mit Azure Service Bus-Features vertraut zu machen:
- .NET
- Sending and receiving session messages (Senden und Empfangen von Sitzungsnachrichten)
- Using the session processor (Verwenden des Sitzungsprozessors)
- Java
- Send messages to a session (Senden von Nachrichten an eine Sitzung)
- Receive messages from the first available session (Empfangen von Nachrichten aus der ersten verfügbaren Sitzung)
- Receive messages from a specific session (Empfangen von Nachrichten aus einer bestimmten Sitzung)
- Process all session messages using a processor (Verarbeiten aller Sitzungsnachrichten mithilfe eines Prozessors)
- Python
- Send and receive messages from a session-enabled queue (Senden und Empfangen von Nachrichten aus einer sitzungsfähigen Warteschlange)
- Receive messages from multiple available sessions in parallel with a thread pool (Paralleles Empfangen von Nachrichten aus mehreren verfügbaren Sitzungen mit einem Threadpool)
- JavaScript
- Send to and receive messages from session enabled queues or subscriptions (Senden und Empfangen von Nachrichten aus sitzungsfähigen Warteschlangen oder Abonnements)
- Continually read through all available sessions (Kontinuierliches Lesen aller verfügbaren Sitzungen)
- Use session state (Verwenden des Sitzungszustands)