Überblick über Queue
Oracle Cloud Infrastructure (OCI) Queue ist ein vollständig verwalteter serverloser Service, mit dem Systeme entkoppelt und asynchrone Vorgänge aktiviert werden können. Queue verarbeitet Transaktionsdaten mit hohem Volumen, die unabhängig verarbeitete Nachrichten ohne Verlust oder Duplizierung erfordern. Queue unterstützt eine transparente, automatische Skalierung basierend auf dem Durchsatz für Producers und Consumers. Queue verwendet offene Standards, um die Kommunikation mit beliebigen Clients oder Producers mit minimalem Aufwand zu unterstützen.
Der OCI Queue-Service basiert auf vier Grundsätzen:
- Veröffentlichen
- Nachrichten können von einem oder mehreren Producers mit jeweils einem Aufbewahrungszeitraum in einer Queue veröffentlicht werden. Wenn kein Aufbewahrungszeitraum angegeben ist, läuft die Nachricht mit einem auf Queueebene definierten Aufbewahrungszeitraum ab. Eine Nachricht enthält eine Payload in Form einer Zeichenfolge.
- Konsumieren
- Mehrere Consumers können Nachrichten aus einer einzelnen Queue konsumieren. Die Anzahl der Consumers kann zusammen mit der Anzahl der veröffentlichten Nachrichten skaliert werden. Nachdem eine Nachricht an einen Consumer zugestellt wurde, wird sie für einen vordefinierten Zeitraum vor anderen Consumers verborgen. Dieser Zeitraum wird als Sichtbarkeitstimeout bezeichnet.
- Aktualisieren
- Wenn die Verarbeitung einer Nachricht länger als erwartet dauert, können Consumers den Sichtbarkeitstimeout einer Nachricht verlängern. Durch Verlängern des Sichtbarkeitstimeouts wird verhindert, dass die Nachricht wieder in die Queue gestellt und an einen anderen Consumer zugestellt wird.
- Löschen
- Nachdem eine Nachricht an einen Consumer zugestellt und von diesem verarbeitet wurde, muss sie gelöscht werden, um eine erneute Zustellung an einen anderen Consumer zu verhindern.
Vorteile
Der Queue-Service bietet die folgenden Vorteile.
Entkoppeln von Anwendungen
Queue unterstützt das Entkoppeln von Anwendungen und Systemen durch das Verwenden einer ereignisgesteuerten Architektur. Durch das Entkoppeln wird sichergestellt, dass einzelne Anwendungskomponenten unabhängig voneinander skaliert werden können und dass neu erstellte Anwendungskomponenten in der Queue veröffentlichen oder diese abonnieren können.
Zuverlässige Nachrichtenverarbeitung
Queue stellt sicher, dass eine Nachricht nie verloren geht, auch wenn der Consumer für das Konsumieren nicht verfügbar ist. Eine veröffentlichte Nachricht ist persistent, bis sie gelöscht wird oder abgelaufen ist.
Wenn eine Nachricht nicht erfolgreich konsumiert wird, wird sie an eine Dead Letter Queue (DLQ) gesendet. Mit Dead Letter Queues können Sie problematische Nachrichten isolieren, um zu bestimmen, warum sie nicht erfolgreich sind. Wenn Sie problematische Nachrichten auf diese Weise isolieren und konsumieren, kann garantiert werden, dass mindestens einmal eine erfolgreiche Zustellung an eine Consumer-Anwendung erfolgt. Weitere Informationen finden Sie unter Dead-Letter Queues.
Offene Standards
Queue kann mit der RESTful API-Definition (mit einer OpenAPI-Spezifikation) oder mit dem STOMP-Protokoll (Branchenstandard) aufgerufen werden.
Konzepte
Der Queue-Service verwendet die folgenden Konzepte.
- Nachricht
- Eine Nachricht ist ein Element in einer Queue, das eine Payload in Form einer Zeichenfolge enthält. Die Zeichenfolge kann in jedem Format vorliegen, einschließlich XML, JSON, CSV, Base64-encoded-Binärnachricht und sogar komprimierte Formate wie gzip. Hersteller und Verbraucher sollten dem Nachrichtenformat zustimmen. Jede Nachricht wird unabhängig verarbeitet.
- Producer
- Ein Client, der Nachrichten an die Queue sendet.
- Consumer
- Ein Client, der Nachrichten aus einer Queue empfängt. Der Consumer ist auch für das Löschen von Nachrichten aus der Queue verantwortlich, nachdem die Nachrichten empfangen wurden.
- Kanal
- Ein flüchtiges Ziel innerhalb einer Queue, das auf Anforderung erstellt werden kann. Nachrichten können in einem bestimmten Kanal innerhalb einer Queue veröffentlicht werden, und Consumer können Nachrichten aus bestimmten Kanälen abrufen. Weitere Informationen finden Sie unter Channels.
- Maximaler Aufbewahrungszeitraum
- Gibt an, wie lange eine Nachricht in einer Queue verbleibt, bis die Nachricht automatisch vom System gelöscht wird, falls sie nicht von einem Consumer gelöscht wird. Für den maximalen Aufbewahrungszeitraum können Werte von 10 Sekunden bis 7 Tage auf Queueebene konfiguriert werden. Der Standardwert ist 1 Tag.
- Zustellungsanzahl
- Gibt an, wie oft eine Nachricht auf Anforderung an einen Consumer zugestellt wird.
- Maximale Zustellversuche
- Gibt an, wie oft eine Nachricht an einen Consumer zugestellt, aber nicht aktualisiert oder gelöscht wird, bevor sie an eine Dead Letter Queue (DLQ) gesendet wird. Für die maximalen Zustellversuche können Werte zwischen 1 und 20 auf Queueebene konfiguriert werden. Weitere Informationen finden Sie unter Zustellungsanzahl.
- Polling-Timeout
- Gibt an, wie lange ein Consumer auf zu konsumierende Nachrichten wartet. Wenn der Polling-Timeout erhöht wird, verringert sich die Häufigkeit, mit der ein Consumer Nachrichten von der Queue anfordert, aber in der Antwort angegeben ist, dass keine zu konsumierenden Nachrichten verfügbar sind. Für den Polling-Timeout können Werte von 0 bis 30 Sekunden auf Queueebene konfiguriert werden. Consumers können den Wert beim Anfordern von Nachrichten festlegen. Der Standardwert ist 30 Sekunden. Weitere Informationen finden Sie unter Langes Polling.
- Sichtbarkeitstimeout
- Gibt an, wie lange eine von einem Consumer aus der Queue empfangene Nachricht für andere Consumers nicht sichtbar ist. Für den Sichtbarkeitstimeout können Werte von 1 Sekunde bis 12 Stunden auf Queueebene konfiguriert werden. Consumers können den Wert beim Anfordern von Nachrichten festlegen. Der Standardwert ist 30 Sekunden. Weitere Informationen finden Sie unter Nachrichten sperren.
- Sichtbare Nachrichten
- Die Anzahl von Nachrichten in einer Queue, die zum Konsumieren verfügbar sind.
- Aktive Nachrichten
- Die Anzahl der an einen Consumer zugestellten, aber noch nicht gelöschten Nachrichten. Aktive Nachrichten können erst nach Ablauf des Sichtbarkeitstimeouts erneut zugestellt werden.
- Dead-Letter Queue
- Wenn eine Nachricht nicht erfolgreich konsumiert wird und mehr Zustellversuche als die konfigurierten maximalen Zustellversuche aufweist, wird die Nachricht in eine Dead-Letter Queue (DLQ) übertragen. Weitere Informationen finden Sie unter Dead-Letter Queues.
Garantien
Der Queue-Service stellt die folgenden Garantien bereit.
- Eine erfolgreich veröffentlichte Nachricht ist garantiert solange dauerhaft, bis sie gelöscht wird oder der Aufbewahrungszeitraum abgelaufen ist. Die Veröffentlichung einer Nachricht wird als erfolgreich betrachtet, wenn der Queue-Service eine Bestätigung an den Producer zurücksendet. Dabei spielt keine Rolle, ob die Antwort empfangen wurde.
- Eine Nachricht innerhalb des Sichtbarkeitstimeouts wird garantiert erst dann an einen anderen Consumer zugestellt, wenn dieser Timeout abgelaufen ist.
- Eine Nachricht wird nicht vom Queue-Service gelöscht, bevor der Aufbewahrungszeitraum abgelaufen ist. Ein Consumer kann eine Nachricht während des Aufbewahrungszeitraums verarbeiten und löschen.
Authentifizierung und Autorisierung
Jeder Service in Oracle Cloud Infrastructure kann zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) in IAM integriert werden.
Ein Administrator in Ihrer Organisation muss Gruppen, Compartments und Policys einrichten, die den Zugriffstyp sowie den Zugriff der Benutzer auf Services und Ressourcen steuern. Mit Policys können Sie beispielsweise steuern, wer Benutzer, Gruppen und Compartments erstellen oder wer virtuelle Deployments erstellen und verwalten kann.
- Wenn Sie ein neuer Administrator sind, lesen Sie Erste Schritte mit Policys.
- Einzelheiten zum Schreiben von Policys für diesen Service finden Sie unter Queue-Policys.
- Einzelheiten zum Schreiben von Policys für Ressourcen in anderen Services finden Sie in der Policy-Referenz.
Möglichkeiten für den Zugriff auf Queue
Sie können über die Konsole (eine browserbasierte Schnittstelle), die Oracle Cloud Infrastructure-CLI oder die REST-APIs auf Queue zugreifen.
In dieser Dokumentation finden Sie Anweisungen für alle drei Methoden.
- Die OCI Console ist eine einfache, browserbasierte Schnittstelle. Um auf die Konsole zuzugreifen, müssen Sie einen unterstützten Browser verwenden.
- Die REST-APIs bieten die meisten Funktionen, erfordern jedoch Programmierkenntnisse. API-Referenz und -Endpunkte enthalten Endpunktdetails und Links zu den verfügbaren API-Referenzdokumenten, einschließlich der Queue-APIs.
- OCI stellt SDKs bereit, die mit Queue interagieren.
- Die Befehlszeilenschnittstelle (CLI) bietet sowohl Schnellzugriff als auch vollständige Funktionalität ohne Programmierung.
- Um die OCI-CLI oder REST-APIs zu verwenden, können Sie entweder Ihre Umgebung einrichten oder Oracle Cloud Infrastructure Cloud Shell verwenden.
- Um die CLI oder die REST-APIs in Cloud Shell zu verwenden, melden Sie sich bei der Konsole an. Siehe Cloud Shell verwenden und OCI-Befehlsreferenz.
- Um die OCI-CLI in Ihrer Umgebung zu installieren, führen Sie die Schritte im Schnellstart unter CLI installieren aus.
- Informationen zur Verwendung von REST-APIs finden Sie in der REST-API-Dokumentation und unter API-Referenz und -Endpunkte.
Servicelimits
Bei der Registrierung für Oracle Cloud Infrastructure wird ein Set von Servicelimits für Ihren Mandanten konfiguriert. Das Servicelimit ist die Quota oder die zulässige Nutzung für eine Ressource. Prüfen Sie die folgenden Servicelimits für Queue-Ressourcen.
Ressource | Details |
---|---|
Queues | 10 pro Mandant und Region |
Unter Service Limits finden Sie weitere Informationen zu Servicelimits sowie Anweisungen dazu, wie Sie eine Limiterhöhung beantragen. Um compartment-spezifische Grenzwerte für eine Ressource oder Ressourcenfamilie festzulegen, können Administratoren Compartment-Quotas verwenden.
Funktionslimits
Neben Dienstressourcenbeschränkungen gibt es bestimmte Warteschlangenbeschränkungen für Funktionen und Funktionen.
Grenzwert | Details |
---|---|
Kanäle pro Queue | 256 pro Warteschlange |
Maximale PutMessage-Anforderungsgröße | 512 KB und 20 Nachrichten |
Maximale GetMessage-Antwortgröße | 2 MB und 20 Nachrichten |
Maximale Nachrichtengröße | 256 KB |
Maximale Anzahl aktive Nachrichten | 100.000 pro Queue |
Höchstanzahl Nachrichten pro Queue | Unbegrenzt |
Nachrichtenaufbewahrung | Maximum: 7 Tage Minimum: 10 Sekunden Standard: 1 Tag |
Nachrichtensichtbarkeitstimeout | Maximum: 12 Stunden Minimum: 0 Sekunden auf Nachrichtenebene Minimum: 1 Sekunde auf Queueebene Standard: 30 Sekunden |
Höchstanzahl nebenläufige GET-Anforderungen | 1.000 Anforderungen pro Sekunde und Queue |
Höchstanzahl Nachrichtenvorgänge | 1.000 Anforderungen pro Sekunde und API und Queue |
Maximale Datenrate | Ingress pro Queue: 10 MB/s Egress pro Queue: 10 MB/s |
Polling-Timeout | Maximum: 30 Sekunden Minimum: 0 Sekunden |
STOMP-Durchsatz | 10 MB/s pro STOMP-Verbindung |
Speicher | 20 GB pro Mandant 2 GB pro Queue |