(0) exportieren Drucken
Alle erweitern

Azure-Warteschlangen und Service Bus-Warteschlangen – Vergleich und Gegenüberstellung

Letzte Aktualisierung: September 2014

Autoren: Valery Mizonov, Seth Manheim und Abhishek Lal

Mitwirkende: Brad Calder, Jai Haridas, Jason Hogg, Jeff Irwin, Jaganathan Thangavelu, Kartik Paramasivam, Todd Holmquist-Sutherland und Ruppert Koch

In diesem Artikel werden die Unterschiede und Ähnlichkeiten zwischen den beiden Warteschlangentypen analysiert, die zurzeit von Azure angeboten werden: -Warteschlangen und Microsoft Azure Service Bus-Warteschlangen. Mithilfe dieser Informationen können Sie die beiden Technologien vergleichen und abgrenzen und sind in der Lage, informiertere Entscheidungen darüber zu treffen, welche Lösung Ihre Anforderungen am besten erfüllt.

unterstützt zwei Typen von Warteschlangen: -Warteschlangen und Servicebus-Warteschlangen.

-Warteschlangen gehören zur Infrastruktur des Azure-Speichers. Sie verfügen über eine einfache REST-basierte Get-/Put-/Peek-Oberfläche, die ein zuverlässiges und konsequentes Messaging zwischen und innerhalb von Diensten gewährleistet.

Servicebus-Warteschlangen gehören der weiter gefassten Azure-Messaging-Infrastruktur an, die neben Warteschlangen auch Veröffentlichungen/Abonnements, Remotebereitstellung von Webdiensten und Integrationsmuster unterstützt. Den Themenbereich zu Servicebus-Warteschlangen, Themen/Abonnements und Relays finden Sie unter Service Bus-Messagingmuster im Überblick.

Obwohl beide Warteschlangentechnologien parallel vorhanden sind, wurden -Warteschlangen zuerst als dedizierter Warteschlangenspeicher-Mechanismus eingeführt, der auf den -Speicherdiensten aufsetzt. Servicebus-Warteschlangen basieren auf der umfassenderen Infrastruktur für "Brokermessaging". Diese dient der Integration von Anwendungen oder Anwendungskomponenten, die sich auf mehrere Kommunikationsprotokolle, Datenverträge, vertrauenswürdige Domänen und/oder Netzwerkumgebungen erstrecken.

In diesem Artikel werden die beiden Warteschlangentechnologien von verglichen. Dabei wird erörtert, welche Unterschiede in Bezug auf Verhalten und Implementierung der jeweils bereitgestellten Leistungsmerkmale bestehen. Darüber hinaus enthält der Artikel Hinweise darüber, welche Eigenschaften für die jeweiligen Anwendungsentwicklungsanforderungen am besten geeignet sind.

-Warteschlangen und Servicebus-Warteschlangen sind Implementierungen des Message Queuing-Diensts, der zurzeit von angeboten wird. Die beiden Implementierungen weisen geringfügig unterschiedliche Funktionsmerkmale auf. Das heißt, Sie können sich für eine entscheiden oder beide verwenden. Welche Sie auswählen, hängt von den Anforderungen Ihrer spezifischen Lösung bzw. dem zu lösenden geschäftlichen oder technischen Problem ab.

Bei der Wahl der Warteschlangentechnologie, die für eine bestimmte Lösung am besten geeignet ist, sollten sich Lösungsarchitekten und -entwickler an die folgenden Empfehlungen halten. Weitere Informationen finden Sie im nächsten Abschnitt.

Als Lösungsarchitekt/-entwickler sollten Sie die Verwendung von -Warteschlangen in den folgenden Situationen in Betracht ziehen:

  • Von der Anwendung müssen Nachrichten mit einer Kapazität von über 80 GB in einer Warteschlange gespeichert werden, wobei die Lebensdauer der Nachrichten unter sieben Tagen liegt.

  • Der Verarbeitungsfortschritt einer Nachricht soll von der Anwendung innerhalb der Warteschlange nachverfolgt werden. Dies ist beim Absturz eines Workerprozesses, von dem die Nachricht verarbeitet wird, von Vorteil. Ein nachfolgender Workerprozess kann diese Informationen verwenden, um die Verarbeitung an der Stelle, an der sich der Absturz ereignet hat, fortzusetzen.

  • Sie benötigen serverseitige Protokolle aller Transaktionen, die für die Warteschlangen ausgeführt wurden.

Als Lösungsarchitekt/-entwickler sollten Sie die Verwendung von Servicebus-Warteschlangen in den folgenden Situationen in Betracht ziehen:

  • Die Lösung muss in der Lage sein, Nachrichten ohne Abruf der Warteschlange empfangen zu können. Bei Servicebus kann dies erreicht werden, indem ein Empfangsvorgang mit langem Abrufintervall mithilfe der auf TCP basierenden Protokolle verwendet wird, die Servicebus unterstützt.

  • Die Lösung erfordert von der Warteschlange die Zustellung nach dem FIFO-Prinzip (First-in-First-out).

  • Sie wünschen eine symmetrische Benutzeroberfläche in und unter Windows Server (private Cloud). Weitere Informationen finden Sie unter Service Bus for Windows Server (Service Bus 1.1).

  • Die Lösung muss in der Lage sein, die automatische Duplikaterkennung zu unterstützen.

  • Sie wünschen eine Anwendung, die Nachrichten als parallele Datenströme mit langer Ausführungsdauer verarbeitet (Nachrichten werden mithilfe der Eigenschaft SessionId für die Nachricht einem Datenstrom zugeordnet). In diesem Modell konkurriert jeder Knoten in der verarbeitenden Anwendung um Datenströme und nicht um Nachrichten. Wenn ein Datenstrom an einen verarbeitenden Knoten übergeben wird, kann der Knoten den Status des Anwendungsdatenstroms mithilfe von Transaktionen untersuchen.

  • Beim Senden oder Empfangen mehrerer Nachrichten über eine Warteschlange muss sich die Lösung durch Transaktionsfähigkeit und Unteilbarkeit auszeichnen.

  • Die Gültigkeitsdauer (Time to Live, TTL) der anwendungsspezifischen Arbeitsauslastung kann sieben Tage überschreiten.

  • Die Anwendung verarbeitet Nachrichten, die zwar 64 KB überschreiten können, die Grenze von 256 KB aber wahrscheinlich nicht erreichen werden.

  • Sie müssen ein rollenbasiertes Zugriffsmodell für Warteschlangen bereitstellen, die Absendern und Empfängern unterschiedliche Rechte/Berechtigungen gewähren.

  • Die Warteschlangengröße wird 80 GB nicht überschreiten.

  • Sie möchten den auf Standards basierenden AMQP 1.0-Messagingbroker verwenden. Den Themenbereich zu AMQP finden Sie unter Service Bus AMQP – Übersicht.

  • Sie können schließlich eine Migration von der warteschlangenbasierten Punkt-zu-Punkt-Kommunikation zu einem Nachrichtenaustauschmodell in Erwägung ziehen, um zusätzliche Empfänger (Abonnenten) nahtlos zu integrieren, von denen jeder eine Kopie einiger oder aller an die Warteschlange gesendeten Nachrichten erhält. Der letzte Punkt bezieht sich auf die Veröffentlichungs-/Abonnementfunktion, die von Servicebus selbst bereitgestellt wird.

  • Ihre Messaginglösung muss in der Lage sein, die "At-Most-Once"-Zustellung zu garantieren, ohne dass zusätzliche Infrastrukturkomponenten implementiert werden müssen.

  • Sie möchten in der Lage sein, Nachrichtenbatches zu veröffentlichen und zu verarbeiten.

  • Eine vollständige Integration in den Windows Communication Foundation (WCF)-Kommunikationsstapel in ist erforderlich.

In den Tabellen der folgenden Abschnitte sind die Warteschlangenfunktionen logisch gruppiert. Sie erkennen also auf einen Blick, welche Funktionen in -Warteschlangen und Servicebus-Warteschlangen verfügbar sind.

In diesem Abschnitt werden einige der grundlegenden Warteschlangenfunktionen verglichen, die von -Warteschlangen und Microsoft Azure Service Bus-Warteschlangen bereitgestellt werden.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Reihenfolgengarantie

Nein

Ja – First-In-First-Out (FIFO)

(durch Verwendung von Messagingsitzungen)

Zustellungsgarantie

At-Least-Once

At-Least-Once

At-Most-Once

Unterstützung von Transaktionen

Nein

Ja

(durch Verwendung lokaler Transaktionen)

Empfangsverhalten

Nicht blockierend

(wird sofort beendet, wenn keine neue Nachricht gefunden wird)

Blockieren mit/ohne Timeout

(bietet ein langes Abrufintervall oder die "Comet-Technik")

Nicht blockierend

(nur durch Verwendung .NET-verwalteter APIs)

API im Pushstil

Nein

Ja

Verwaltete OnMessage- und OnMessage-Sitzungs-API (.NET).

Empfangsmodus

Peek & Lease

Peek & Lock

Receive & Delete

Exklusiver Zugriffsmodus

Leasebasiert

Sperrenbasiert

Lease-/Sperrdauer

30 Sekunden (Standard)

7 Tage (maximal) (Sie können eine Nachrichtenlease mithilfe der UpdateMessage-API erneuern oder freigeben.)

60 Sekunden (Standard)

Eine Nachrichtensperre kann mit der RenewLock-API verlängert werden.

Lease-/Sperrengranularität

Nachrichtenebene

(Jede Nachricht kann einen anderen Timeoutwert aufweisen, den Sie nach Bedarf bei der Verarbeitung der Nachricht mithilfe der UpdateMessage-API aktualisieren können.)

Warteschlangenebene

(jede Warteschlange weist eine Sperrengranularität auf, die auf alle enthaltenen Nachrichten angewendet wird; die Sperre kann jedoch mit der RenewLock-API verlängert werden)

Batchempfang

Ja

(explizit angebende Nachrichtenanzahl beim Abrufen von Nachrichten, bis maximal 32 Nachrichten)

Ja

(implizites Aktivieren einer PreFetch-Eigenschaft oder explizites Aktivieren durch Verwendung von Transaktionen)

Batchversand

Nein

Ja

(durch Verwendung von Transaktionen oder clientseitiger Batchverarbeitung)

  • Wenn Sie bereits Azure-Speicher-BLOBs oder -tabellen verwenden und mit der Verwendung von Warteschlangen beginnen, werden 99,9 % Verfügbarkeit garantiert. Wenn Sie BLOBs oder Tabellen mit Servicebus-Warteschlangen verwenden, ist die Verfügbarkeit geringer.

  • Das garantierte FIFO-Prinzip in Servicebus-Warteschlangen erfordert die Verwendung von Messagingsitzungen. Falls die Anwendung bei der Verarbeitung einer im Peek & Lock-Modus empfangenen Nachricht abstürzt, startet die Anwendung, sobald ein Warteschlangenempfänger das nächste Mal eine Messagingsitzung akzeptiert, mit der fehlgeschlagenen Nachricht, nachdem die zugehörige Gültigkeitsdauer (TTL) abgelaufen ist.

  • -Warteschlangen unterstützen Standardwarteschlangenszenarien, z. B. das Abkoppeln von Anwendungskomponenten, um die Skalierbarkeit und Fehlertoleranz zu erhöhen, Lastenausgleich und das Erstellen von Prozessworkflows.

  • Servicebus-Warteschlangen unterstützen die At-Least-Once-Zustellungsgarantie. Darüber hinaus kann die At-Most-Once-Semantik unterstützt werden, indem der Sitzungszustand verwendet wird, um den Anwendungszustand zu speichern, und indem Transaktionen verwendet werden, um Nachrichten atomisch zu empfangen und den Sitzungszustand zu aktualisieren. Der Workflow Service verwendet dieses Verfahren, um die At-Most-Once-Zustellung zu garantieren.

  • -Warteschlangen bieten ein einheitliches und konsistentes Programmiermodell für Warteschlangen, Tabellen und BLOBs – für Entwickler und für Betriebsteams.

  • Servicebus-Warteschlangen unterstützen lokale Transaktionen im Kontext einer einzelnen Warteschlange.

  • Der von Servicebus unterstützte Receive and Delete-Modus bietet die Möglichkeit, die Anzahl der Übermittlungsvorgänge (und damit verbundene Gebühren) auf Kosten einer verminderten Zustellungssicherheit zu reduzieren.

  • -Warteschlangen stellen ein Leasingprinzip bereit, über das die Leasedauer für Nachrichten verlängert werden kann. Auf diese Weise können die Workerprozesse eine kurze Leasedauer für Nachrichten beibehalten. Sollte ein Workerprozess abstürzen, kann die Nachricht folglich von einem anderen Workerprozess schnell verarbeitet werden. Ein Workerprozess kann darüber hinaus die Leasedauer für eine Nachricht verlängern, wenn deren Verarbeitungszeit über die aktuelle Leasedauer hinausgeht.

  • -Warteschlangen verfügen über ein Sichtbarkeitstimeout, das Sie festlegen können, wenn eine Nachricht der Warteschlange hinzugefügt bzw. daraus entfernt wird. Außerdem können Sie eine Nachricht anhand verschiedener Leasewerte zur Laufzeit aktualisieren; und Sie können unterschiedliche Werte für mehrere Nachrichten aktualisieren, die sich in derselben Warteschlange befinden. Servicebus-Sperrtimeouts sind in den Warteschlangenmetadaten definiert. Sie können die Sperre jedoch verlängern, indem Sie die Methode RenewLock aufrufen.

  • Das maximale Timeout für das Blockieren einer empfangenen Nachricht in Servicebus-Warteschlangen beträgt 24 Tage. REST-basierte Timeouts verfügen jedoch über einen maximalen Wert von 55 Sekunden.

  • Mithilfe der clientseitigen Batchverarbeitung von Servicebus kann ein Warteschlangenclient mehrere Nachrichten als Batch in einen einzelnen Sendevorgang einfügen. Die Batchverarbeitung ist nur für asynchrone Sendevorgänge verfügbar.

  • Durch Features wie etwa die Obergrenze von 200 TB für -Warteschlangen (bzw. ein höherer Wert, wenn Sie Konten virtualisieren) und eine uneingeschränkte Anzahl von Warteschlangen ist die Anwendung eine ideale Plattform für SaaS-Anbieter.

  • -Warteschlangen bieten einen flexiblen und leistungsstarken delegierten Zugriffssteuerungsmechanismus.

In diesem Abschnitt werden die von -Warteschlangen und Servicebus-Warteschlangen bereitgestellten erweiterten Funktionen verglichen.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Zeitgesteuerte Zustellung

Ja

Ja

Automatisch generierte unzustellbare Nachrichten

Nein

Ja

Vergrößern des TTL-Werts einer Warteschlange

Ja

(über direktes Update des Sichtbarkeitstimeouts)

Ja

(über eine dedizierte API-Funktion bereitgestellt)

Unterstützung für nicht verarbeitbare Nachrichten

Ja

Ja

Direktes Update

Ja

Ja

Serverseitiges Transaktionsprotokoll

Ja

Nein

Speichermetrik

Ja

Minutenmetriken: stellen in Echtzeit Metriken für die Verfügbarkeit, TPS, Anzahl der API-Aufrufe, Fehleranzahl usw. zur Verfügung (aggregiert pro Minute und gemeldet innerhalb weniger Minuten nach Ereigniseintritt in der Produktion). Weitere Informationen finden Sie unter zu Informationen zu Metriken der Speicheranalyse.

Ja

(Massenabfragen durch Aufrufen von GetQueues)

Zustandsverwaltung

Nein

Ja

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

Automatische Nachrichtenweiterleitung

Nein

Ja

Warteschlangeninhalt endgültig löschen

Ja

Nein

Nachrichtengruppen

Nein

Ja

(durch Verwendung von Messagingsitzungen)

Anwendungszustand pro Nachrichtengruppe

Nein

Ja

Duplikaterkennung

Nein

Ja

(auf der Absenderseite konfigurierbar)

WCF-Integration

Nein

Ja

(stellt direkt einsatzbereite WCF-Bindungen bereit)

WF-Integration

Benutzerdefiniert

(erfordert das Erstellen einer benutzerdefinierten WF-Aktivität)

Systemeigenes Format

(stellt direkte einsetzbare WF-Aktivitäten bereit)

Durchsuchen von Nachrichtengruppen

Nein

Ja

Abrufen von Nachrichtensitzungen anhand der ID

Nein

Ja

  • Beide Warteschlangentechnologien ermöglichen das Planen der Zustellung einer Nachricht zu einem späteren Zeitpunkt.

  • Die automatische Warteschlangenweiterleitung ermöglicht, dass Tausende von Warteschlangen ihre Nachrichten automatische an eine einzelne Warteschlange weiterleiten, aus der die empfangene Anwendung die Nachricht abruft. Sie können diesen Mechanismus verwenden, um Sicherheit zu erzielen, den Datenfluss zu steuern und Speicher zwischen den einzelnen Nachrichtenverlegern zu isolieren.

  • -Warteschlangen bieten Unterstützung für die Aktualisierung von Nachrichteninhalten. Sie können diese Funktionalität verwenden, um Zustandsinformationen und inkrementelle Statusupdates in der Nachricht beizubehalten, sodass sie vom letzten bekannten Prüfpunkt statt von Anfang an verarbeitet wird. Mit Servicebus-Warteschlangen können Sie das gleiche Szenario mithilfe von Nachrichtensitzungen aktivieren. Sitzungen ermöglichen das Speichern und Abrufen des Anwendungsverarbeitungszustands (mithilfe von SetState und GetState).

  • Unzustellbare Nachrichten, die nur von Servicebus-Warteschlangen unterstützt werden, leisten wertvolle Hilfe beim Isolieren von Nachrichten, die von der Empfangsanwendung nicht erfolgreich verarbeitet werden können bzw. die ihr Ziel aufgrund einer abgelaufenen TTL-Eigenschaft (Time-To-Live) nicht erreichen können. Der TTL-Wert gibt an, wie lange eine Nachricht in der Warteschlange verbleibt. Bei Servicebus wird die Nachricht in eine bestimmte Warteschlange mit dem Namen $DeadLetterQueue verschoben, sobald die Gültigkeitsdauer abläuft.

  • Zur Suche nach nicht verarbeitbaren Nachrichten in -Warteschlangen überprüft die Anwendung die DequeueCount-Eigenschaft der Nachricht, wenn eine Nachricht aus der Warteschlange entfernt wird. Wenn DequeueCount über einem angegebenen Schwellenwert liegt, verschiebt die Anwendung die Nachricht in eine von der Anwendung definierte "Warteschlange für unzustellbare Nachrichten".

  • Für -Warteschlangen können Sie ein ausführliches Protokoll aller für die Warteschlange ausgeführten Transaktionen sowie aggregierte Metriken abrufen. Beide erleichtern das Debuggen und verdeutlichen, wie -Warteschlangen von der Anwendung verwendet werden. Weiter dienen diese Informationen dazu, die Anwendungsleistung zu optimieren und die Kosten für die Verwendung von Warteschlangen zu senken.

  • Das von Servicebus unterstützte Konzept "Nachrichtensitzung" macht es möglich, dass Nachrichten, die einer bestimmten logischen Gruppe angehören, einem bestimmten Empfänger zugeordnet werden. Auf diese Weise entsteht eine sitzungsähnliche Affinität zwischen Nachrichten und den betreffenden Empfängern. Sie können diese erweiterte Funktionalität in Servicebus aktivieren, indem Sie die Eigenschaft SessionID für eine Nachricht festlegen. Empfänger können dann auf eine bestimmte Sitzungs-ID lauschen und Nachrichten empfangen, die den angegebenen Sitzungsbezeichner gemeinsam haben.

  • Die von Servicebus-Warteschlangen unterstützte Duplikaterkennung entfernt gemäß dem Wert der MessageID-Eigenschaft automatisch doppelt vorhandene Nachrichten, die an eine Warteschlange bzw. ein Thema gesendet wurden.

In diesem Abschnitt werden -Warteschlangen und Servicebus-Warteschlangen im Hinblick auf die Kapazität und ggf. gültige Kontingente verglichen.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Maximale Warteschlangengröße

200 TB

(beschränkt auf die Kapazität eines einzelnen Speicherkontos)

1 GB to 80 GB

(wird bei Erstellung einer Warteschlange und dem Aktivieren von Partitionierung definiert.)

Maximale Nachrichtengröße

64 KB

(48 KB bei Verwendung der Base64-Codierung)

Azure unterstützt große Nachrichten, indem Warteschlangen und BLOBs kombiniert werden – in diesem Fall können bis zu 200 GB für ein einzelnes Element in der Warteschlange gespeichert werden.

256 KB

(einschließlich Header und Text. Die maximale Headergröße beträgt 64 KB.)

Maximaler TTL-Wert der Nachricht

7 Tage

Unbegrenzt

Maximale Anzahl von Warteschlangen

Unbegrenzt

10,000

(pro Dienstnamespace, kann jedoch erhöht werden)

Maximale Anzahl gleichzeitiger Clients

Unbegrenzt

Unbegrenzt

(Die Beschränkung auf 100 gleichzeitige Verbindungen gilt nur für die Kommunikation über das TCP-Protokoll)

  • Wenn der Inhalt der Nachricht bei -Warteschlangen nicht XML-sicher ist, muss er mit Base64 codiert werden. Wenn Sie die Nachricht mit Base64 codieren, darf die Benutzernutzlast statt 64 KB nur 48 KB betragen.

  • Bei Servicebus-Warteschlangen besteht jede in einer Warteschlange gespeicherte Nachricht aus zwei Teilen: einem Header und einem Text. Die Gesamtgröße der Nachricht darf 256 KB nicht überschreiten.

  • Wenn Clients über das TCP-Protokoll mit Servicebus-Warteschlangen kommunizieren, ist die maximale Anzahl gleichzeitiger Verbindungen mit einer einzelnen Servicebus-Warteschlange auf 100 eingeschränkt. Diese Anzahl wird zwischen Absendern und Empfängern aufgeteilt. Wenn dieses Kontingent erreicht wird, werden nachfolgende Anforderungen für zusätzliche Verbindungen abgelehnt, und vom aufrufenden Code wird eine Ausnahme empfangen. Diese Begrenzung gilt nicht für Clients, die über die REST-basierte API eine Verbindung mit Warteschlangen herstellen.

  • In Servicebus werden Grenzwerte für die Warteschlangengröße durchgesetzt. Die maximale Warteschlangengröße wird bei der Erstellung der Warteschlange angegeben und kann einen Wert zwischen 1 und 80 GB aufweisen. Wenn der bei der Erstellung der Warteschlange festgelegte Größenwert erreicht ist, werden zusätzlich eingehende Nachrichten abgelehnt, und vom aufrufenden Code wird eine Ausnahme empfangen. Den Themenbereich zu Kontingenten in Servicebus finden Sie unter Windows Azure Service Bus-Kontingente.

  • Wenn Sie mehr als 10.000 Warteschlangen in einem einzelnen Servicebus Dienstnamespace benötigen, können Sie sich mit dem -Supportteam in Verbindung setzen und eine Erhöhung des Werts anfordern. Um für Servicebus auf mehr als 10.000 Warteschlangen zu skalieren, können Sie auch zusätzliche Dienstnamespaces mithilfe des -Verwaltungsportals erstellen.

In diesem Abschnitt werden die von -Warteschlangen und Servicebus-Warteschlangen bereitgestellten Verwaltungsfunktionen verglichen.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Verwaltungsprotokoll

REST über HTTP/HTTPS

REST über HTTPS

Laufzeitprotokoll

REST über HTTP/HTTPS

REST über HTTPS

AMQP 1.0 Standard (TCP mit TLS)

.NET-verwaltete API

Ja

(.NET-verwaltete Speicherclient-API)

Ja

(.NET-verwaltete API für Brokermessaging)

Systemeigenes C++

Ja

Nein

Java-API

Ja

Ja

PHP-API

Ja

Ja

Node.js-API

Ja

Ja

Unterstützung beliebiger Metadaten

Ja

Nein

Benennungsregeln für Warteschlangen

Bis zu 63 Zeichen

(Buchstaben in einem Warteschlangennamen müssen klein geschrieben sein)

Bis zu 260 Zeichen

(bei Warteschlangennamen wird die Groß-/Kleinschreibung unterschieden)

Funktion zum Abrufen der Warteschlangenlänge

Ja

(ungefährer Wert, wenn Nachrichten nach dem TTL-Wert ablaufen, ohne gelöscht zu werden.)

Ja

(genau, Zeitpunktwert)

Peek-Funktion

Ja

Ja

  • -Warteschlangen unterstützen beliebige Attribute, die auf die Warteschlangenbeschreibung angewendet werden können, in Form von Name-Wert-Paaren.

  • Beide Warteschlangentechnologien bieten außerdem die Möglichkeit, einen Blick in eine Nachricht zu werfen, ohne sie zu sperren. Dies kann bei der Implementierung eines Explorer-/Browsertools für die Warteschlange hilfreich sein.

  • Die verwalteten .NET-APIs für Brokermessaging von Servicebus nutzen im Vergleich zu "REST über HTTP" die Vollduplex-TCP-Verbindungen zur Leistungsoptimierung und unterstützen das AMQP 1.0-Standardprotokoll.

  • -Warteschlangennamen dürfen 3 bis 63 Zeichen lang sein und Kleinbuchstaben, Ziffern und Bindestriche enthalten. Weitere Informationen finden Sie unter zu Benennen von Warteschlangen und Metadaten.

  • Namen von Servicebus-Warteschlangen können bis zu 260 Zeichen lang sein und verfügen über weniger restriktive Benennungsregeln. Namen von Servicebus-Warteschlangen dürfen nur Buchstaben, Ziffern, Punkte (.), Bindestriche (-) und Unterstriche (_) enthalten.

In diesem Abschnitt werden -Warteschlangen und Servicebus-Warteschlangen im Hinblick auf Leistung verglichen.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Maximaler Durchsatz

Bis zu 2.000 Nachrichten pro Sekunde

(basierend auf Vergleichstests mit Nachrichten von 1 KB)

Bis zu 2.000 Nachrichten pro Sekunde

(basierend auf Vergleichstests mit Nachrichten von 1 KB)

Durchschnittliche Latenz

10 ms

(mit deaktiviertem TCP Nagle-Algorithmus)

20 - 25 ms

Begrenzungsverhalten

Bei HTTP 503-Code ablehnen

(begrenzte Anforderungen sind nicht abrechenbar)

Mit Ausnahme/HTTP 503 ablehnen

(begrenzte Anforderungen sind nicht abrechenbar)

  • Eine einzelne -Warteschlange kann bis zu 2.000 Transaktionen pro Sekunde verarbeiten. Eine Transaktion ist entweder ein Put-, Get- oder Delete-Vorgang. Das Senden einer einzelnen Nachricht an eine Warteschlange (Put) wird als eine Transaktion gezählt, während der Empfang einer Nachricht häufig ein zweistufiger Vorgang ist, der den Abruf (Get) gefolgt von einer Anforderung zum Entfernen der Nachricht aus der Warteschlange (Delete) umfasst. Folglich werden in der Regel zwei Transaktionen ausgeführt, um eine Nachricht erfolgreich aus einer Warteschlange zu entfernen. Das Abrufen mehrerer Nachrichten in einem Batch kann die negativen Auswirkungen verringern, da Sie bis zu 32 Nachrichten mithilfe von Get in einer Transaktion abrufen können, gefolgt von einem Delete-Vorgang für jede dieser Nachrichten. Damit ein besserer Durchsatz erzielt wird, können Sie mehrere Warteschlangen erstellen (ein Speicherkonto kann uneingeschränkt viele Warteschlangen aufweisen).

  • Wenn die Anwendung den maximalen Durchsatz für eine -Warteschlange erreicht, wird normalerweise die Antwort "HTTP 503 Server ausgelastet" vom Warteschlangendienst zurückgegeben. In diesem Fall sollte die Anwendung die Wiederholungslösung mit exponentieller Backoffverzögerung auslösen.

  • Die Latenz von -Warteschlangen beträgt durchschnittlich 10 Millisekunden, wenn kleine Nachrichten (unter 10 KB) von einem gehosteten Dienst behandelt werden, der sich am selben Ort (bzw. in derselben Region) wie das Speicherkonto befindet.

  • Von -Warteschlangen und von Servicebus-Warteschlangen wird das Einschränkungsverhalten durchgesetzt, indem Anforderungen an eine eingeschränkte Warteschlange zurückgewiesen werden. Begrenzte Anforderungen werden jedoch von keiner der Warteschlangen als abrechenbar behandelt.

  • Vergleichstests für Servicebus-Warteschlangen haben gezeigt, dass eine einzelne Warteschlange einen Nachrichtendurchsatz von bis zu 2.000 Nachrichten pro Sekunde bei einer Nachrichtengröße von ca. 1 KB erreichen kann. Verwenden Sie mehrere Warteschlangen, um einen höheren Durchsatz zu erzielen. Weitere Informationen zur Leistungsoptimierung mit Servicebus finden Sie unter Bewährte Methoden für Leistungsoptimierungen mithilfe von Service Bus-Brokermessaging.

  • Sobald der maximale Durchsatz für eine Servicebus-Warteschlange erreicht ist, wird (bei Verwendung der verwalteten .NET-API für Brokermessaging) eine ServerBusyException-Antwort bzw. (bei Verwendung der REST-basierten API) eine HTTP 503-Antwort an den Warteschlangenclient zurückgegeben. Dies weist darauf hin, dass die Warteschlange eingeschränkt ist.

In diesem Abschnitt werden die von -Warteschlangen und Servicebus-Warteschlangen unterstützten Autorisierungsfunktionen erläutert.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Authentifizierung

Symmetrischer Schlüssel

Symmetrischer Schlüssel

Zugriffssteuerungsmodell

Delegierter Zugriff über SAS-Token.

RBAC über ACS.

Verbund von Identitätsanbietern

Nein

Ja

  • Jede Anforderung an eine der beiden Warteschlangentechnologien muss authentifiziert werden. Öffentliche Warteschlangen mit anonymem Zugriff werden nicht unterstützt. Mithilfe von SAS können Sie dieses Szenario verwalten, indem Sie eine lesegeschützte SAS, ein schreibgeschützte SAS oder sogar eine SAS mit Vollzugriff veröffentlichen.

  • Das von -Warteschlangen bereitgestellte Authentifizierungsschema schließt die Verwendung eines symmetrischen Schlüssels ein. Dieser entspricht einem hashbasierten Message Authentication Code (HMAC), der mit dem SHA-256-Algorithmus berechnet und als Base64-Zeichenfolge codiert wird. Den Themenbereich zum jeweiligen Protokoll finden Sie unter Authentifizieren des Zugriffs auf das Speicherkonto. Servicebus-Warteschlangen unterstützen ein ähnliches Modell mithilfe symmetrischer Schlüssel. Weitere Informationen finden Sie unter SAS-Authentifizierung (Shared Access Signature) mit Service Bus.

  • Der von Servicebus unterstützte Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) bietet drei verschiedene Rollen: Administrator, Absender und Empfänger. Diese werden derzeit für -Warteschlangen nicht unterstützt.

  • Da Servicebus die ACS-Integration bietet, können Sie (durch Verwendung von ADFS) einen Verbund mit Active Directory und allgemeinen Webidentitätsanbietern wie Live ID, Google, Facebook und Yahoo eingehen.

In diesem Abschnitt werden -Warteschlangen und Servicebus-Warteschlangen im Hinblick auf Kosten verglichen.

 

Vergleichskriterien -Warteschlangen Servicebus-Warteschlangen

Kosten für Warteschlangentransaktionen

$0.0005

(pro 10.000 Transaktionen)

$0.01

(pro 10.000 Nachrichten)

Abrechenbare Vorgänge

All

Nur Senden/Empfangen

(keine Gebühren für andere Vorgänge)

Transaktionen im Leerlauf

Abrechenbar

(die Abfrage einer leeren Warteschlange wird als abrechenbare Transaktion angerechnet)

Abrechenbar

(ein Empfangsvorgang für eine leere Warteschlange wird als abrechenbare Nachricht angerechnet)

Speicherkosten

$0.07

(pro GB/Monat)

$0.00

Übertragungskosten für ausgehende Daten

$0.12 - $0.19

(je nach Geografie)

$0.12 - $0.19

(je nach Geografie)

  • Datenübertragungen werden auf Grundlage der Gesamtmenge von Daten abgerechnet, die das -Datencenter über das Internet in einem bestimmten Abrechnungszeitraum verlassen.

  • Datenübertragungen zwischen -Diensten, die sich in derselben Region befinden, sind nicht gebührenpflichtig.

  • Zum Zeitpunkt der Erstellung dieses Dokuments sind sämtliche eingehenden Datenübertragungen nicht gebührenpflichtig.

  • Die Kosten von ACS-Transaktionen sind insignifikant, wenn Messagingvorgänge mit Servicebus-Warteschlangen ausgeführt werden. Servicebus ruft ein ACS-Token pro Instanz des Messagingfactoryobjekts ab. Das Token wird so lange wiederverwendet, bis es nach etwas 20 Minuten abläuft. Folglich verhält sich das Volumen der Messagingvorgänge in Servicebus nicht direkt proportional zur Menge der ACS-Transaktionen, die zur Unterstützung dieser Vorgänge erforderlich sind.

  • Die Unterstützung langer Abrufintervalle vorausgesetzt, kann sich die Verwendung von Servicebus-Warteschlangen in Situationen, in denen eine Zustellung mit niedriger Latenz erforderlich ist, als kosteneffektiv erweisen.

noteHinweis
Änderungen bei allen Kosten bleiben vorbehalten. Die vorangehende Tabelle enthält die Preise, die zum Zeitpunkt der Erstellung dieses Dokuments gültig waren und schließt keine Werbeangebote ein, die möglicherweise gerade gültig sind. Aktuelle Preisinformationen finden Sie auf der Seite Preisübersicht.

Die Entscheidung für -Warteschlangen oder Servicebus-Warteschlangen hängt eindeutig von mehreren Faktoren ab. Diese Faktoren können sich nach den individuellen Anforderungen der Anwendung und der Architektur richten. Wenn die Anwendung bereits die Kernfunktionen von verwendet, ziehen Sie es möglicherweise vor, -Warteschlangen zu verwenden, insbesondere, wenn es um die grundlegende Kommunikation und das Messaging zwischen Diensten geht oder Sie Warteschlangen benötigen, die größer sind als 80 GB.

Da Servicebus-Warteschlangen eine Vielzahl erweiterter Funktionen wie Sitzungen, Transaktionen, Duplikaterkennung, automatische unzustellbare Nachrichten und bewährte Funktionen für Veröffentlichung/Abonnements bieten, werden Sie diese vielleicht vorziehen, wenn Sie eine Hybridanwendung erstellen bzw. diese Funktionen von der Anwendung benötigt werden.

Nach einer Zusammenfassung normativer Empfehlungen zu Beginn des Artikels wurden die Funktionen der beiden Warteschlangentechnologien, die heute von angeboten werden, vorgestellt und verglichen. Die Unterteilung in Funktionsgruppen ergab eine visuell ansprechende Vergleichsanalyse, die die Ähnlichkeiten und Unterschiede zwischen -Warteschlangen und Servicebus-Warteschlangen auf einen Blick erkennbar macht. Das tiefere Verständnis der beiden Technologien erleichtert Ihnen die Entscheidung, wann Sie welche Warteschlangentechnologie einsetzen sollten.

Siehe auch

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft