Storage-Warteschlangen und Service Bus-Warteschlangen – Vergleich und Gegenüberstellung
In diesem Artikel werden die Unterschiede und Ähnlichkeiten zwischen den beiden Warteschlangentypen untersucht, die in Microsoft Azure angeboten werden: Storage-Warteschlangen und Service Bus-Warteschlangen. Anhand dieser Informationen können Sie eine fundierte Entscheidung darüber treffen, welche Lösung Ihre Anforderungen am besten erfüllt.
Einführung
Azure unterstützt zwei Arten von Warteschlangenmechanismen: Storage-Warteschlangen und Service Bus-Warteschlangen.
Speicherwarteschlangen sind Teil der Azure Storage-Infrastruktur. Sie ermöglichen das Speichern einer großen Anzahl von Nachrichten. Sie können überall auf der Welt über authentifizierte Aufrufe mithilfe von HTTP oder HTTPS auf Nachrichten zugreifen. Eine Warteschlangennachricht kann bis zu 64 KB groß sein. Eine Warteschlange kann Millionen Nachrichten enthalten, bis die maximale Kapazität eines Speicherkontos erreicht ist. Warteschlangen werden häufig verwendet, um ein Arbeits-Backlog zur asynchronen Verarbeitung zu erstellen. Weitere Informationen finden Sie unter Was sind Azure Storage-Warteschlangen?.
Service Bus-Warteschlangen gehören der weiter gefassten Azure-Messaginginfrastruktur an, die Warteschlangen, Veröffentlichungen/Abonnements und fortgeschrittenere Integrationsmuster unterstützt. Sie dienen der Integration von Anwendungen oder Anwendungskomponenten, die sich über mehrere Kommunikationsprotokolle, Datenverträge, vertrauenswürdige Domänen oder Netzwerkumgebungen erstrecken. Weitere Informationen zu Service Bus-Warteschlangen/-Themen/-Abonnements finden Sie unter Service Bus-Warteschlangen, -Themen und -Abonnements.
Überlegungen zur Wahl der richtigen Technologie
Storage-Warteschlangen und Service Bus-Warteschlangen bieten leicht unterschiedliche Funktionen. Sie können je nach den Anforderungen Ihrer jeweiligen Lösung eine oder beide auswählen.
Bei der Auswahl der Warteschlangentechnologie, die für eine bestimmte Lösung am besten geeignet ist, sollten sich Lösungsarchitekten und -entwickler an die folgenden Empfehlungen halten.
Gründe für Storage-Warteschlangen
Als Lösungsarchitekt/-entwickler sollten Sie die Verwendung von Storage-Warteschlangen in den folgenden Situationen in Betracht ziehen:
- In der Anwendung müssen Nachrichten mit einer Kapazität von über 80 GB in einer Warteschlange gespeichert werden.
- Der Verarbeitungsfortschritt einer Nachricht soll von der Anwendung in der Warteschlange nachverfolgt werden. Dies ist beim Absturz eines Workers von Vorteil, von dem die Nachricht verarbeitet wird. Ein weiterer Worker kann diese Informationen nutzen, um die Verarbeitung an der Stelle fortzusetzen, an der sich der Absturz ereignet hat.
- Sie benötigen serverseitige Protokolle aller Transaktionen, die für die Warteschlangen ausgeführt wurden.
Gründe für Service Bus-Warteschlangen
Als Lösungsarchitekt/-entwickler sollten Sie die Verwendung von Service Bus-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 Service Bus kann dies erreicht werden, indem ein Empfangsvorgang mit langem Abrufintervall mit den von Service Bus unterstützten auf TCP basierenden Protokollen verwendet wird.
- Die Lösung erfordert von der Warteschlange die Zustellung nach dem FIFO-Prinzip (First-In-First-Out).
- 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 session ID-Eigenschaft 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.
- Ihre Anwendung verarbeitet Nachrichten, die 64 KB überschreiten können, aber wahrscheinlich nicht den Grenzwert von 256 KB oder 1 MB erreichen, je nach ausgewählter Dienstebene (obwohl Service Bus-Warteschlangen Nachrichten bis zu 100 MB verarbeiten können).
- Sie müssen ein rollenbasiertes Zugriffsmodell für Warteschlangen bereitstellen, die Absendern und Empfängern unterschiedliche Rechte/Berechtigungen gewähren. Weitere Informationen finden Sie in den folgenden Artikeln:
- Die Warteschlangengröße überschreitet 80 GB nicht.
- Sie möchten das auf Standards basierende AMQP 1.0-Messagingprotokoll verwenden. Weitere Informationen zu AMQP finden Sie unter Service Bus AMQP Overview (Service Bus AMQP – Übersicht).
- Sie planen eine spätere Migration von der warteschlangenbasierten Punkt-zu-Punkt-Kommunikation zu einem Veröffentlichungs-Abonnement-Messagingmuster. Dieses Muster ermöglicht die Integration zusätzlicher Empfänger (Abonnenten). Jeder Empfänger erhält unabhängige Kopien von einigen oder allen der an die Warteschlange gesendeten Nachrichten.
- Ihre Messaginglösung muss die „At-Most-Once“-Zustellung und die „At-Least-Once“-Zustellung garantieren, ohne dass zusätzliche Infrastrukturkomponenten erstellt werden müssen.
- Die Lösung muss in der Lage sein, Nachrichtenbatches zu veröffentlichen und zu verarbeiten.
Vergleich von Storage-Warteschlangen und Service Bus-Warteschlangen
In den Tabellen in den folgenden Abschnitten werden die Warteschlangenfeatures logisch gruppiert. So können Sie auf einen Blick die verfügbaren Funktionen in Azure Storage-Warteschlangen und Service Bus-Warteschlangen vergleichen.
Grundlegende Funktionen
In diesem Abschnitt werden einige der grundlegenden Warteschlangenfunktionen verglichen, die von Storage-Warteschlangen und Azure Service Bus-Warteschlangen bereitgestellt werden.
| Vergleichskriterien | Storage-Warteschlangen | Service Bus-Warteschlangen |
|---|---|---|
| Reihenfolgengarantie | Ohne Weitere Informationen finden Sie in der ersten Anmerkung im Abschnitt Weitere Informationen. |
Ja – First-In-First-Out (FIFO) (mithilfe von Nachrichtensitzungen) |
| Zustellungsgarantie | At-Least-Once | At-Least-Once (mit dem PeekLock-Empfangsmodus, dies ist die Standardeinstellung) At-Most-Once (mit dem ReceiveAndDelete-Empfangsmodus) Weitere Informationen zu den verschiedenen Empfangsmodi |
| Unterstützung für atomare Operationen | Nein | Ja |
| Empfangsverhalten | Nicht blockierend (wird sofort beendet, wenn keine neue Nachricht gefunden wird) |
Blockieren mit oder ohne Timeout (bietet ein langes Abrufintervall oder die „Comet-Technik“) Nicht blockierend (nur mithilfe der verwalteten .NET-API) |
| API im Pushstil | Nein | Ja Unsere .NET-, Java-, JavaScript- und Go-SDKs bieten eine API im Pushstil. |
| 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.) |
30 Sekunden (Standard) Sie können die Nachrichtensperre jedes Mal für die gleiche Dauer manuell erneuern oder die automatische Sperrverlängerungsfunktion verwenden, bei der der Client die Sperrverlängerung für Sie verwaltet. |
| 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 Sperrpräzision auf, die auf alle ihre Nachrichten angewendet wird, aber die Sperre kann wie in der vorherigen Zeile beschrieben erneuert werden) |
| Batchempfang | Ja (explizit angebende Nachrichtenanzahl beim Abrufen von Nachrichten, bis maximal 32 Nachrichten) |
Ja (implizites Aktivieren einer Vorababrufeigenschaft oder explizit durch Verwendung von Transaktionen) |
| Batchversand | Nein | Ja (mithilfe von Transaktionen oder clientseitiger Batchverarbeitung) |
Zusätzliche Informationen
- Für Nachrichten in Storage-Warteschlangen gilt normalerweise das FIFO-Prinzip, manchmal kann jedoch die Reihenfolge auch falsch sein. Dies ist beispielsweise der Fall, wenn die Dauer der Sichtbarkeit einer Nachricht abläuft, da eine Clientanwendung bei der Verarbeitung einer Nachricht abgestürzt ist. Wenn das Sichtbarkeitstimeout abläuft, wird die Nachricht für die Warteschlange erneut sichtbar, damit sie von einem anderen Worker aus der Warteschlange entnommen werden kann. Zu diesem Zeitpunkt wird die neue sichtbare Nachricht ggf. hinter einer Nachricht in der Warteschlange platziert, um erneut aus dieser entnommen zu werden.
- Das garantierte FIFO-Prinzip in Service Bus-Warteschlangen erfordert die Verwendung von Messagingsitzungen. Wenn die Anwendung bei der Verarbeitung einer im Peek & Lock-Modus empfangenen Nachricht abstürzt, wird sie beim nächsten Akzeptieren einer Messagingsitzung durch einen Warteschlangenempfänger mit der Fehlernachricht gestartet, nachdem die Sperrdauer der Sitzung abläuft.
- Storage-Warteschlangen wurden für die Unterstützung von Standardwarteschlangenszenarien wie den folgenden konzipiert:
- Entkoppeln von Anwendungskomponenten zur Steigerung von Skalierbarkeit und Fehlertoleranz
- Belastungsausgleich
- Erstellen von Prozessworkflows
- Inkonsistenzen in Bezug auf die Nachrichtenbehandlung im Kontext von Service Bus-Sitzungen können vermieden werden, indem der Sitzungszustand verwendet wird, um den Zustand der Anwendung im Verhältnis zum Fortschritt bei der Behandlung der Nachrichtensequenz der Sitzung zu speichern, und indem Transaktionen zum Klären empfangener Nachrichten und zum Aktualisieren des Sitzungszustands verwendet werden. Diese Art von Konsistenzfeature wird in Produkten anderer Hersteller manchmal als Exactly-Once Processing, also genau eine Verarbeitung bezeichnet. Alle Transaktionsfehler führen offensichtlich dazu, dass Nachrichten erneut zugestellt werden. Aus diesem Grund ist dieser Begriff jedoch nicht ganz zutreffend.
- Storage-Warteschlangen bieten ein einheitliches und konsistentes Programmiermodell für Warteschlangen, Tabellen und Blobs – für Entwickler und für Betriebsteams.
- Service Bus-Warteschlangen unterstützen lokale Transaktionen im Kontext einer einzelnen Warteschlange.
- Der von Service Bus unterstützte Receive & Delete-Modus bietet die Möglichkeit, die Anzahl von Übermittlungsvorgängen (und damit verbundenen Gebühren) auf Kosten einer verminderten Zustellungssicherheit zu reduzieren.
- Storage-Warteschlangen stellen ein Leasingprinzip bereit, über das die Leasedauer für Nachrichten verlängert werden kann. Mit diesem Feature können die Workerprozesse eine kurze Leasedauer für Nachrichten beibehalten. Sollte ein Worker abstürzen, kann die Nachricht schnell von einem anderen Worker verarbeitet werden. Ein Worker kann darüber hinaus die Leasedauer einer Nachricht verlängern, wenn deren Verarbeitungszeit über die aktuelle Leasedauer hinausgeht.
- Speicherwarteschlangen verfügen über ein Sichtbarkeitstimeout, das Sie festlegen können, wenn eine Nachricht der Warteschlange hinzugefügt bzw. aus dieser entfernt wird. Außerdem können Sie eine Nachricht mit verschiedenen Leasewerten zur Laufzeit aktualisieren und unterschiedliche Werte für mehrere Nachrichten in derselben Warteschlange anpassen. Die Sperrtimeouts von Service Bus werden in den Metadaten der Warteschlangen definiert. Sie können die Nachrichtensperre jedoch für die gleiche vordefinierte Dauer manuell erneuern oder die automatische Sperrverlängerungsfunktion verwenden, bei der der Client die Sperrverlängerung für Sie verwaltet.
- Das maximale Timeout für das Blockieren einer empfangenen Nachricht in Service Bus-Warteschlangen beträgt 24 Tage. REST-basierte Timeouts verfügen jedoch über einen maximalen Wert von 55 Sekunden.
- Mithilfe der clientseitigen Batchverarbeitung von Service Bus 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 Storage-Warteschlangen (bzw. ein höherer Wert, wenn Sie Konten virtualisieren) und eine uneingeschränkte Anzahl von Warteschlangen ist dies die ideale Plattform für SaaS-Anbieter.
- Storage-Warteschlangen bieten einen flexiblen und leistungsstarken delegierten Zugriffssteuerungsmechanismus.
Erweiterte Funktionen
In diesem Abschnitt werden die von Storage-Warteschlangen und Service Bus-Warteschlangen bereitgestellten erweiterten Funktionen verglichen.
| Vergleichskriterien | Storage-Warteschlangen | Service Bus-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 bieten Echtzeitmetriken zu Verfügbarkeit, TPS, Anzahl von API-Aufrufen, Anzahl von Fehlern u. v. m. Diese Metriken werden in Echtzeit minutenweise aggregiert und innerhalb weniger Minuten ab dem Vorfall in der Produktionsumgebung gemeldet. Weitere Informationen finden Sie unter Informationen zu Metriken der Speicheranalyse. |
Ja Informationen zu Metriken, die von Azure Service Bus unterstützt werden, finden Sie unter Nachrichtenmetriken. |
| Zustandsverwaltung | Nein | Ja (Active, Disabled, SendDisabled, ReceiveDisabled. Weitere Informationen zu diesen Zuständen finden Sie unter Warteschlangenstatus.) |
| Automatische Weiterleitung von Nachrichten | Nein | Ja |
| Warteschlangeninhalt endgültig löschen | Ja | Nein |
| Nachrichtengruppen | Nein | Ja (mithilfe von Messagingsitzungen) |
| Anwendungszustand pro Nachrichtengruppe | Nein | Ja |
| Duplikaterkennung | Nein | Ja (auf der Absenderseite konfigurierbar) |
| Durchsuchen von Nachrichtengruppen | Nein | Ja |
| Abrufen von Nachrichtensitzungen anhand der ID | Nein | Ja |
Zusätzliche Informationen
- 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 automatisch an eine einzelne Warteschlange weiterleiten, aus der die empfangende 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.
- Storage-Warteschlangen bieten Unterstützung zum Aktualisieren von Nachrichteninhalten. Sie können diese Funktionen verwenden, um Zustandsinformationen und inkrementelle Statusupdates in der Nachricht beizubehalten, sodass sie vom letzten bekannten Prüfpunkt statt von Anfang an verarbeitet wird. Mit Service Bus-Warteschlangen können Sie das gleiche Szenario mithilfe von Nachrichtensitzungen aktivieren. Weitere Informationen finden Sie unter Zustand von Nachrichtensitzungen.
- Service Bus-Warteschlangen unterstützen unzustellbare Nachrichten. Dies kann nützlich sein, um Nachrichten zu isolieren, die die folgenden Kriterien erfüllen:
- Nachrichten können von der empfangenden Anwendung nicht erfolgreich verarbeitet werden.
- Nachrichten können aufgrund einer abgelaufenen Gültigkeitsdauer (TTL) nicht an ihr Ziel zugestellt werden. Der TTL-Wert gibt an, wie lange eine Nachricht in der Warteschlange verbleibt. Bei Service Bus wird die Nachricht in eine bestimmte Warteschlange mit dem Namen "$DeadLetterQueue" verschoben, sobald die Gültigkeitsdauer abläuft.
- Für die Suche nach nicht verarbeitbaren Nachrichten in Storage-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“.
- Bei Storage-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 Storage-Warteschlangen von der Anwendung verwendet werden. Außerdem dienen diese Informationen dazu, die Anwendung zu optimieren und die Kosten für die Verwendung von Warteschlangen zu senken.
- Von Service Bus unterstützte Nachrichtensitzungen ermöglichen es, die Nachrichten einer logischen Gruppe einem Empfänger zuzuordnen. Dadurch wird eine sitzungsähnliche Affinität zwischen Nachrichten und den jeweiligen Empfängern erzeugt. Sie können diese erweiterte Funktionalität in Service Bus aktivieren, indem Sie die session ID-Eigenschaft 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.
- Das Feature zur Duplikaterkennung von Service Bus-Warteschlangen entfernt gemäß dem Wert der message ID-Eigenschaft automatisch doppelt vorhandene Nachrichten, die an eine Warteschlange bzw. ein Thema gesendet wurden.
Kapazität und Kontingente
In diesem Abschnitt werden Storage-Warteschlangen und Service Bus-Warteschlangen im Hinblick auf die Kapazität und ggf. gültige Kontingente verglichen.
| Vergleichskriterien | Storage-Warteschlangen | Service Bus-Warteschlangen |
|---|---|---|
| Maximale Warteschlangengröße | 500 TB (beschränkt auf die Kapazität eines einzelnen Speicherkontos) |
1 GB bis 80 GB (wird bei Erstellung einer Warteschlange und dem Aktivieren von Partitionierung definiert – weitere Informationen finden Sie im Abschnitt „Zusätzliche Informationen“) |
| 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 oder 100 MB (Einschließlich Header und Text, maximale Headergröße: 64 KB.) Hängt von der Dienstebene ab. |
| Maximaler TTL-Wert der Nachricht | Unbegrenzt (API-Version 2017-07-27 oder höher) | TimeSpan.MaxValue |
| Maximale Anzahl von Warteschlangen | Unbegrenzt | 10.000 (pro Dienstnamespace) |
| Maximale Anzahl gleichzeitiger Clients | Unbegrenzt | 5\.000 |
Zusätzliche Informationen
- In Service Bus werden Grenzwerte für die Warteschlangengröße durchgesetzt. Die maximale Warteschlangengröße wird beim Erstellen der Warteschlange angegeben. Sie kann zwischen 1 GB und 80 GB liegen. Wenn die Warteschlangengröße diesen Grenzwert erreicht, werden alle weiteren eingehenden Nachrichten zurückgewiesen, und der Aufrufer empfängt eine Ausnahme. Weitere Informationen zu Kontingenten in Service Bus finden Sie unter Service Bus-Kontingente.
- Im Standard-Messagingtarif können Sie Service Bus-Warteschlangen und -Themen in Größen von 1 (Standard), 2, 3, 4 oder 5 GB erstellen. Wenn Partitionierung in der Standardebene aktiviert wird, erstellt Service Bus 16 Kopien (16 Partitionen) der Entität mit der jeweils angegebenen Größe. Wenn Sie also eine Warteschlange mit einer Größe von 5 GB erstellen, beträgt die maximale Warteschlangengröße bei 16 Partitionen 5 × 16 = 80 GB. Die maximale Größe der partitionierten Warteschlange oder des Themas wird im Azure-Portal angezeigt.
- Wenn der Inhalt der Nachricht bei Storage-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 Service Bus-Warteschlangen besteht jede in einer Warteschlange gespeicherte Nachricht aus zwei Teilen: einem Header und einem Text. Die Gesamtgröße der Nachricht darf die maximale, von der Dienstebene unterstützte Nachrichtengröße nicht überschreiten.
- Wenn Clients über das TCP-Protokoll mit Service Bus-Warteschlangen kommunizieren, ist die maximale Anzahl gleichzeitiger Verbindungen mit einer einzelnen Service Bus-Warteschlange auf 100 beschränkt. Diese Anzahl wird zwischen Absendern und Empfängern aufgeteilt. Wenn dieses Kontingent erreicht wird, werden Anforderungen für zusätzliche Verbindungen abgelehnt, und vom aufrufenden Code wird eine Ausnahme empfangen. Dieser Grenzwert gilt nicht für Clients, die über die REST-basierte API eine Verbindung mit Warteschlangen herstellen.
- Wenn Sie mehr als 10.000 Warteschlangen in einem einzelnen Service Bus-Dienstnamespace benötigen, können Sie sich mit dem Azure-Supportteam in Verbindung setzen und eine Erhöhung des Werts anfordern. Um für Service Bus auf mehr als 10.000 Warteschlangen zu skalieren, können Sie mithilfe des Azure-Portals auch zusätzliche Namespaces erstellen.
Verwaltung und Abläufe
In diesem Abschnitt werden die von Storage-Warteschlangen und Service Bus-Warteschlangen bereitgestellten Verwaltungsfunktionen verglichen.
| Vergleichskriterien | Storage-Warteschlangen | Service Bus-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 API | Ja (.NET-Storage-Client-API) |
Ja (.NET-Service Bus-API) |
| Systemeigenes C++ | Ja | Ja |
| 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 (Warteschlangennamen müssen in Kleinbuchstaben geschrieben sein.) |
Bis zu 260 Zeichen lang (bei Warteschlangenpfaden und -namen wird die Groß-/Kleinschreibung nicht berücksichtigt.) |
| Funktion zum Abrufen der Warteschlangenlänge | Ja (ungefährer Wert, wenn Nachrichten nach dem TTL-Wert ablaufen, ohne gelöscht zu werden.) |
Ja (genauer Zeitpunktwert.) |
| Peek-Funktion | Ja | Ja |
Zusätzliche Informationen
- Storage-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 Service Bus nutzen im Vergleich zu REST über HTTP Vollduplex-TCP-Verbindungen zur Leistungsoptimierung und unterstützen das AMQP 1.0-Standardprotokoll.
- Die Namen von Storage-Warteschlangen dürfen 3 bis 63 Zeichen lang sein und Kleinbuchstaben, Ziffern und Bindestriche enthalten. Weitere Informationen finden Sie unter Benennen von Warteschlangen und Metadaten.
- Namen von Service Bus-Warteschlangen können bis zu 260 Zeichen lang sein und verfügen über weniger restriktive Benennungsregeln. Namen von Service Bus-Warteschlangen dürfen Buchstaben, Ziffern, Punkte, Bindestriche und Unterstriche enthalten.
Authentifizierung und Autorisierung
In diesem Abschnitt werden die von Storage-Warteschlangen und Service Bus-Warteschlangen unterstützten Autorisierungsfunktionen erläutert.
| Vergleichskriterien | Storage-Warteschlangen | Service Bus-Warteschlangen |
|---|---|---|
| Authentifizierung | Symmetrischer Schlüssel und rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) | Symmetrischer Schlüssel und rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) |
| Verbund von Identitätsanbietern | Ja | Ja |
Zusätzliche Informationen
- Jede Anforderung an eine der beiden Warteschlangentechnologien muss authentifiziert werden. Öffentliche Warteschlangen mit anonymem Zugriff werden nicht unterstützt.
- Mithilfe von SAS-Authentifizierung (Shared Access Signature) können Sie eine SAS-Autorisierungsregel für eine Warteschlange erstellen, die Benutzern Schreibzugriff, schreibgeschützten Zugriff oder Vollzugriff ermöglichen kann. Weitere Informationen finden Sie unter Azure Storage – SAS-Authentifizierung und Azure Service Bus – SAS-Authentifizierung.
- Beide Warteschlangen unterstützen die Autorisierung des Zugriffs mithilfe von Microsoft Entra-ID. Das Autorisieren von Benutzern oder Anwendungen mithilfe eines von Microsoft Entra ID zurückgegebenen OAuth 2.0-Tokens bietet mehr Sicherheit und Benutzerfreundlichkeit als die Autorisierung per SAS (Shared Access Signature). Mit Microsoft Entra ID ist es nicht erforderlich, Token in Ihrem Code zu speichern und potenzielle Sicherheitsrisiken einzugehen. Weitere Informationen finden Sie unter Azure Storage – Microsoft Entra-Authentifizierung und Azure Service Bus – Microsoft Entra-Authentifizierung.
Zusammenfassung
Durch ein tieferes Verständnis der beiden Technologien können Sie eine fundiertere Entscheidung zur verwendeten Warteschlangentechnologie treffen. Die Entscheidung für Storage-Warteschlangen oder Service Bus-Warteschlangen hängt eindeutig von vielen Faktoren ab. Diese Faktoren richten sich nach den individuellen Anforderungen der Anwendung und der Architektur.
In folgenden Fällen empfehlen sich Storage-Warteschlangen:
- Ihre Anwendung nutzt bereits die Kernfunktionen von Microsoft Azure.
- Sie benötigen eine grundlegende Kommunikation und Messaging zwischen Diensten.
- Sie benötigen Warteschlangen, die auch größer als 80 GB sein können.
Service Bus-Warteschlangen bieten zahlreiche erweiterte Features, z. B. die folgenden. Sie eignen sich daher möglicherweise besser, wenn Sie eine Hybridanwendung entwickeln oder wenn Ihre Anwendung diese Features generell benötigt.
- Sitzungen
- Transaktionen
- Duplikaterkennung
- Automatisch generierte unzustellbare Nachrichten
- Funktionen für dauerhafte Veröffentlichungen und Abonnements
Nächste Schritte
Die folgenden Artikel enthalten weitere Anleitungen und Informationen zur Verwendung von Storage-Warteschlangen oder Service Bus-Warteschlangen.