Erkunden von Service Bus-Warteschlangen, -Themen und -Abonnements

  • 3 Minuten

Den Kern der Messagingfunktionen in Service Bus bilden die folgenden Messagingentitäten: Warteschlangen, Themen und Abonnements sowie Regeln/Aktionen.

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. Da Nachrichten dauerhaft in der Warteschlange gespeichert werden, müssen Producer (Absender) und Consumer (Empfänger) Nachrichten nicht gleichzeitig verarbeiten.

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 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.

Sie können Warteschlangen über das Azure-Portal, PowerShell, die Befehlszeilenschnittstelle oder Resource Manager-Vorlagen erstellen. Für das Senden und Empfangen von Nachrichten können Sie Clients verwenden, die in C#, Java, Python und JavaScript geschrieben wurden.

Empfangsmodi

Sie können zwei verschiedene Modi angeben, in denen Service Bus Nachrichten empfängt: Empfangen und Löschen oder Peek/Lock.

Empfangen und Löschen

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: Stellen Sie sich ein Szenario vor, in dem der Consumer die Empfangsanforderung ausstellt und dann abstürzt, 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.

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.

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.

In Abonnements können die zu empfangenden Nachrichten mithilfe weiterer Filter eingeschränkt werden. 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.

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, können Sie nur eine Teilmenge dieser Nachrichten in die virtuelle Abonnementwarteschlange kopieren. 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.