Freigeben über

Nachrichtensitzungen

Azure Service Bus-Sitzungen ermöglichen die gemeinsame und geordnete Verarbeitung ungebundener 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 bei Verwendung von Service Bus mithilfe von Sitzungen implementieren.

Hinweis

Der Basic-Tarif von Service Bus unterstützt keine Sitzungen. Die Standard- und Premium-Stufen 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 die FIFO-Verarbeitung bei der Verarbeitung von Nachrichten aus ServiceBus-Warteschlangen oder -Abonnements zu erreichen. Service Bus ist nicht für die Art der Beziehung zwischen Nachrichten präskriptiv und definiert auch kein bestimmtes Modell, um zu bestimmen, wo eine Nachrichtensequenz beginnt oder endet.

Ein Absender kann eine Sitzung initiieren, wenn Nachrichten in ein Thema oder eine Warteschlange gesendet werden, indem die Sitzungs-ID-Eigenschaft auf einen eindeutigen Bezeichner festgelegt wird, der von der Anwendung definiert wird. Auf der AMQP 1.0-Protokollebene ist dieser Wert der Eigenschaft "group-id " 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 Zeit oder API für den Zeitpunkt, zu dem die Sitzung abläuft oder verschwindet. Theoretisch kann eine Nachricht für eine Sitzung heute, die nächste Nachricht in einem Jahr empfangen werden, und wenn die Sitzungs-ID übereinstimmt, ist die Sitzung mit der Sicht des Servicebus identisch.

In der Regel definiert eine Anwendung jedoch, wo eine Reihe verwandter Nachrichten beginnt und endet. Service Bus erzwingt keine spezifischen Regeln. Ihre Anwendung könnte beispielsweise die Label-Eigenschaft für die erste Nachricht als Start, für Zwischennachrichten als Inhalt und für die letzte Nachricht auf Ende festlegen. Die relative Position der Inhaltsnachrichten kann als die aktuelle Meldung SequenceNumber delta aus der StartnachrichtSequenceNumber berechnet werden.

Von Bedeutung

Wenn Sitzungen in einer Warteschlange oder einem Abonnement aktiviert sind, können die Clientanwendungen keine regulären Nachrichten mehr senden/empfangen. Clients müssen Nachrichten als Teil einer Sitzung senden, indem sie die Sitzungs-ID festlegen, und sie empfangen diese, indem sie die Sitzung akzeptieren. Clients können weiterhin eine Warteschlange oder ein Abonnement mit aktivierten Sitzungen einsehen. Siehe Nachrichtenbrowsen.

Die APIs für Sitzungen sind in Warteschlangen- und Abonnementclients vorhanden. Es gibt zwei Möglichkeiten zum Empfangen von Sitzungen und Nachrichten: das imperative Modell, bei dem Sie manuell steuern, wann und wie Nachrichten empfangen werden, und das handlerbasierte Modell, das dinge vereinfacht, indem die Nachrichtenschleife und -verarbeitung automatisch verwaltet wird.

Verwenden Sie für Beispiele Links im Abschnitt "Beispiele ".

Sitzungsfunktionen

Sitzungen ermöglichen das gleichzeitige Demultiplexing von geschachtelten Nachrichtenstreams unter Beibehaltung und Gewährleistung der geordneten Zustellung.

Diagramm, das zeigt, wie die Funktion

Ein Client erstellt einen Sitzungsempfänger, um eine Sitzung zu akzeptieren. Wenn der Client eine Sitzung akzeptiert und beibehält, erhält der Client eine exklusive Sperre für alle Nachrichten mit der Sitzungs-ID in der Warteschlange oder dem Abonnement. Es enthält exklusive Sperren für alle Nachrichten mit der Sitzungs-ID , die später eintreffen.

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. Stattdessen können Sie das Feature für die automatische Sperrverlängerung verwenden, in dem Sie die Zeitdauer angeben können, für die Sie die Sperre verlängern möchten. Die Sitzungssperre sollte wie eine exklusive Sperre für eine Datei behandelt werden, was bedeutet, dass die Anwendung die Sitzung schließen sollte, sobald sie sie 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. Bei 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 obige Abbildung zeigt drei gleichzeitige Sitzungsempfänger. Eine Sitzung mit SessionId = 4 hat keinen aktiven, eigenen Client, was bedeutet, dass keine Nachrichten von dieser bestimmten Sitzung zugestellt werden. Eine Sitzung fungiert in vielerlei Hinsicht wie eine untergeordnete Warteschlange.

Die Sitzungssperre, die vom Sitzungsempfänger gehalten wird, ist ein Oberbegriff für die Nachrichtensperren, die im Peek-Lock-Abwicklungsmodus verwendet werden. Nur ein Empfänger kann eine Sperre für eine Sitzung haben. Ein Empfänger verfügt möglicherweise über viele In-Flight-Nachrichten, aber die Nachrichten werden in der Reihenfolge empfangen. Wenn eine Nachricht aufgegeben wird, wird dieselbe Nachricht mit dem nächsten Empfangsvorgang erneut bereitgestellt.

Status der Nachrichtenverbindung

Wenn Workflows in Hochverfügbarkeits-Cloudsystemen verarbeitet werden, muss der Workflowhandler, der einer bestimmten Sitzung zugeordnet ist, in der Lage sein, aus unerwarteten Fehlern wiederherzustellen und die teilweise abgeschlossene Arbeit an einem anderen Prozess oder Computer fortzusetzen, von dem aus die Arbeit begonnen hat.

Die Sitzungszustandseinrichtung ermöglicht eine anwendungsdefinierte Anmerkung einer Nachrichtensitzung innerhalb des Brokers, sodass der aufgezeichnete Verarbeitungszustand relativ zu dieser Sitzung sofort verfügbar wird, wenn die Sitzung von einem neuen Prozessor abgerufen wird.

Aus Sicht des Servicebus ist der Status der Nachrichtensitzung ein undurchsichtiges binäres Objekt, das Daten der Größe einer Nachricht enthalten kann, bei der es sich um 256 KB für Service Bus Standard und 100 MB für Service Bus Premium handelt. Der Verarbeitungszustand relativ zu einer Sitzung kann innerhalb des Sitzungszustands gehalten werden, oder der Sitzungszustand kann auf einen Speicherort oder einen Datenbankdatensatz verweisen, der solche Informationen enthält.

Die Methoden zum Verwalten des Sitzungszustands SetStateund GetStatedes Sitzungsempfängerobjekts finden Sie im Sitzungsempfängerobjekt. Eine Sitzung, die zuvor keinen Sitzungszustand hatte, gibt einen Nullverweis für GetState. Der zuvor festgelegte Sitzungszustand kann gelöscht werden, indem null an die SetState Methode des Empfängers übergeben wird.

Der Sitzungsstatus bleibt so lange erhalten, wie er nicht gelöscht wird (indem null zurückgegeben wird), selbst wenn alle Nachrichten in einer Sitzung konsumiert 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 Lieferanzahl

Die Definition der Zustellungsanzahl pro Nachricht im Kontext von Sitzungen variiert geringfügig von der Definition in Abwesenheit von Sitzungen. Hier ist eine Tabelle, die zusammenfasst, wenn die Anzahl der Zustellungen erhöht wird.

Szenario Wird die Zustellungsanzahl der Nachricht erhöht?
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 (auch wenn sie gesperrt sind), und die Sitzung wird geschlossen. Nein
Die Sitzung wird akzeptiert, Nachrichten werden abgeschlossen, und die Sitzung wird explizit geschlossen. N/A (Es ist der Standardfluss. Hier werden Nachrichten aus der Sitzung entfernt)

Anforderung/Antwort-Muster

Das Anforderungsantwortmuster ist ein gut etabliertes Integrationsmuster, mit dem die Absenderanwendung eine Anforderung senden kann und dem Empfänger die Möglichkeit bietet, eine Antwort ordnungsgemäß an die Absenderanwendung zu senden. Dieses Muster benötigt in der Regel eine kurzlebige Warteschlange oder ein Thema, an die die Anwendung Antworten sendet. In diesem Szenario bieten Sitzungen eine einfache alternative Lösung mit vergleichbarer Semantik.

Mehrere Anwendungen können ihre Anforderungen an eine einzelne Anforderungswarteschlange senden, wobei ein bestimmter Headerparameter festgelegt ist, um die Absenderanwendung eindeutig zu identifizieren. Die Empfängeranwendung kann die in der Warteschlange eingehenden Anforderungen verarbeiten und Antworten an die sitzungsfähige 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 über die spezifische Sitzungs-ID empfangen und die Antworten ordnungsgemäß verarbeiten.

Hinweis

Die Anwendung, die die anfänglichen Anforderungen sendet, sollte über die Sitzungs-ID wissen und sie verwenden, um die Sitzung zu akzeptieren, damit die Sitzung, für die die Antwort erwartet wird, gesperrt ist. Es empfiehlt sich, eine GUID zu verwenden, die die Instanz der Anwendung eindeutig als Sitzungs-ID identifiziert. Es darf kein Sitzungshandler oder Zeitlimit (beim Sitzungsempfänger angegeben) in der Warteschlange vorhanden sein, um sicherzustellen, dass die Antworten für die Sperrung und Verarbeitung durch bestimmte Empfänger verfügbar sind.

Sequenzierung im Vergleich zu Sitzungen

Die Sequenznummer selbst 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.

  1. Consumer 1 ruft Nachricht 1 ab.
  2. Consumer 2 ruft Nachricht 2 ab.
  3. Consumer 2 beendet die Verarbeitung von Nachricht 2 und nimmt Nachricht 3 ab, während Consumer 1 noch nicht mit der Verarbeitung von Nachricht 1 fertig ist.
  4. Consumer 2 beendet die Verarbeitung von Nachricht 3, aber Consumer 1 ist noch nicht mit der Verarbeitung von Nachricht 1 fertig.
  5. 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 in der reihenfolge abgerufen werden müssen, müssen Sie keine Sitzungen verwenden. Wenn Nachrichten in der richtigen Reihenfolge verarbeitet werden müssen, verwenden Sie Sitzungen. Die gleiche Sitzungs-ID sollte für Nachrichten festgelegt werden, die zusammengehören. Dies könnten in einer Gruppe die Nachrichten 1, 4 und 8 sein und in einer anderen Gruppe die Nachrichten 2, 3 und 6.

Nachrichtenablauf

Für sitzungsfähige Warteschlangen oder Themenabonnements werden Nachrichten auf Sitzungsebene gesperrt. Wenn die Gültigkeitsdauer (Time-To-Live. TTL) 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, 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 Ablauf von Nachrichten.

Beispiele

Sie können Nachrichtensitzungen beim Erstellen einer Warteschlange mithilfe von Azure-Portal, PowerShell, CLI, Resource Manager-Vorlage, .NET, Java, Python und JavaScript aktivieren. Weitere Informationen finden Sie unter Aktivieren von Nachrichtensitzungen.

Sehen Sie sich die Beispiele in der Sprache Ihrer Wahl an, um Azure Service Bus-Features zu untersuchen.

Verwandte Inhalte