Pub/Sub ist ein Publish/Subscribe (Pub/Sub) Service, d. h. ein Messaging-Dienst, bei dem die Absender von Nachrichten von den Empfängern der Nachrichten entkoppelt sind. Ein Pub/Sub-Dienst basiert auf folgenden Konzepten, die in der folgenden Abbildung erläutert werden.
Die folgenden Komponenten gehören zu einem Pub/Sub-Dienst:
Publisher (auch als Datenersteller bezeichnet): erstellt Nachrichten und sendet (veröffentlicht) sie an den Messaging-Dienst zu einem bestimmten Thema.
Nachricht: die Daten, die durch den Dienst geleitet werden.
Thema: eine benannte Entität, die für einen Feed von Nachrichten steht.
Schema: Eine benannte Entität, die das Datenformat einer Pub/Sub-Nachricht steuert.
Abo: eine benannte Entität, die für ein Interesse am Erhalten von Nachrichten zu einem bestimmten Thema steht.
Abonnent (auch als Nutzer bezeichnet): erhält Nachrichten zu einem bestimmten Abo.
Im Folgenden wird der Workflow des Pub/Sub-Dienstes beschrieben:
Zwei Publisher-Anwendungen, Publisher 1 und Publisher 2, senden Nachrichten an ein einzelnes Pub/Sub-Thema. Publisher 1 sendet die Nachricht A und Publisher 2 sendet die Nachricht B.
Das Thema selbst ist mit zwei Abos verknüpft. Das sind Abo 1 und Abo 2.
Das Thema ist auch mit einem Schema verknüpft.
Jedes Abo erhält eine Kopie der Nachrichten A und B vom Thema.
Abo 1 ist mit zwei Abonnentenanwendungen verknüpft: Abonnent 1 und Abonnent 2. Die beiden Abonnentenanwendungen erhalten einen Teil der Nachrichten aus dem Thema. In diesem Beispiel erhält Abonnent 1 Nachricht B, während Abonnent 2 Nachricht A vom Thema erhält.
Abo 2 ist nur mit einer einzigen Aboanwendung namens Abonnent 3 verknüpft. Abonnent 3 empfängt also alle Nachrichten aus dem Thema.
Lebensdauer einer Nachricht
Angenommen, ein einzelner Publisher-Client ist mit einem Thema verbunden. Dem Thema ist ein einzelnes Abo zugewiesen. Mit dem Abo ist ein einzelner Abonnent verknüpft.
In den folgenden Schritten wird beschrieben, wie eine Nachricht in Pub/Sub fließt:
Eine Publisher-Anwendung sendet eine Nachricht an ein Pub/Sub-Thema.
Die Nachricht wird gespeichert.
Pub/Sub schreibt die Nachricht nicht nur in den Speicher, sondern liefert sie auch an alle zugehörigen Abos des Themas.
In diesem Beispiel ist es ein einzelnes Abo.
Das Abo sendet die Nachricht an eine angehängte Abonnentenanwendung.
Der Abonnent sendet Pub/Sub eine Bestätigung über die Verarbeitung der Nachricht.
Nachdem mindestens ein Abonnent für jedes Abo die Nachricht bestätigt hat, wird sie von Pub/Sub aus dem Speicher gelöscht.
Status einer Nachricht in Pub/Sub
Solange eine Nachricht von einem Abonnenten nicht bestätigt wurde, versucht Pub/Sub nicht, sie an einen anderen Abonnenten desselben Abos zu senden. Unter ackDeadline kann konfiguriert werden, wie lange ein Abonnent Zeit hat, um die ausstehende Nachricht zu bestätigen. Nach Ablauf der Frist gilt die Nachricht nicht mehr als ausstehend und kann wieder zugestellt werden.
Nachrichten in einem Pub/Sub-Dienst können drei Status haben:
Bestätigte Nachrichten (ACK) Nachdem eine Abonnentenanwendung eine Nachricht verarbeitet hat, die von einem Thema an ein Abo gesendet wurde, sendet sie eine Bestätigung zurück an Pub/Sub. Wenn alle Abos eines Themas die Nachricht bestätigt haben, wird sie asynchron aus der Publish-Nachrichtenquelle und aus dem Speicher gelöscht.
Nicht bestätigte Nachrichten (unacked) Wenn Pub/Sub innerhalb der Bestätigungsfrist keine Bestätigung erhält, wird eine Nachricht möglicherweise mehrmals zugestellt. Beispielsweise kann der Abonnent eine Bestätigung nach Ablauf der Frist senden oder die Bestätigung kann aufgrund vorübergehender Netzwerkprobleme verloren gehen. Unbestätigte Nachrichten werden so lange zugestellt, bis die Aufbewahrungsdauer nach der Veröffentlichung abgelaufen ist. An diesem Punkt läuft die Nachricht ab.
Negativ bestätigte Nachrichten (NACK) Wenn ein Abonnent eine Nachricht nackt, wird sie von Pub/Sub sofort noch einmal gesendet. Wenn ein Abonnent ungültige Nachrichten ablehnt oder die Nachrichten nicht verarbeiten kann, trägt er dazu bei, dass diese Nachrichten nicht verloren gehen und letztendlich erfolgreich verarbeitet werden. Sie können modifyAckDeadline mit dem Wert „0“ verwenden, um eine Nachricht abzulehnen.
Pub/Sub-Publish-/Subscribe-Muster auswählen
Wenn es mehrere Pub/Sub-Publisher- und ‑Abonnenten-Clients gibt, müssen Sie auch die Art der Publish-Subscribe-Architektur auswählen, die Sie einrichten möchten.
Zu den unterstützten Pub/Sub-Publish-Subscribe-Mustern gehören:
Fan-In (n:1) In diesem Beispiel veröffentlichen mehrere Publisher-Anwendungen Nachrichten zu einem einzigen Thema. Dieses einzelne Thema ist mit einem einzelnen Abo verknüpft. Das Abo ist wiederum mit einer einzelnen Abonnentenanwendung verbunden, die alle veröffentlichten Nachrichten aus dem Thema empfängt.
Load Balancing (manche-zu-viele) In diesem Beispiel veröffentlichen eine oder mehrere Publisher-Anwendungen Nachrichten zu einem einzelnen Thema. Dieses einzelne Thema ist mit einem einzelnen Abo verknüpft, das wiederum mit mehreren Abonnentenanwendungen verbunden ist. Jede der Abonnentenanwendungen erhält eine Teilmenge der veröffentlichten Nachrichten. Keine zwei Abonnentenanwendungen erhalten dieselbe Teilmenge von Nachrichten. In diesem Fall für das Load Balancing verwenden Sie mehrere Abonnenten, um Nachrichten im großen Maßstab zu verarbeiten. Wenn mehr Nachrichten unterstützt werden müssen, fügen Sie weitere Abonnenten hinzu, die Nachrichten über dasselbe Abo erhalten sollen.
Verzweigung (1:n). In diesem Beispiel veröffentlichen eine oder mehrere Publisher-Anwendungen Nachrichten zu einem einzigen Thema. Dieses einzelne Thema ist mit mehreren Abos verknüpft. Jedes Abo ist mit einer einzelnen Aboanwendung verknüpft. Jede der Abonnentenanwendungen erhält dieselben veröffentlichten Nachrichten aus dem Thema. Wenn ein Thema mehrere Abos hat, muss jede Nachricht an einen Abonnenten gesendet werden, der Nachrichten im Namen jedes Abos empfängt. Wenn Sie verschiedene Datenvorgänge auf denselben Nachrichten ausführen müssen, ist die Verzweigung eine gute Option. Sie können auch mehrere Abonnenten an jedes Abo anhängen und für jeden Abonnenten eine load-balanced Teilmenge der Nachrichten erhalten.
Pub/Sub-Konfigurationsoption auswählen
Sie können eine Pub/Sub-Umgebung mit einer der folgenden Optionen konfigurieren:
- Google Cloud Console
- Google Cloud CLI
- Cloud-Clientbibliotheken (Clientbibliothek der höheren Ebene)
- REST- und RPC-APIs (Low-Level-Clientbibliothek)
Welche Pub/Sub-Konfigurationsoption Sie auswählen, hängt von Ihrem Anwendungsfall ab.
Wenn Sie die Google Cloud Console noch nicht kennen und Pub/Sub testen möchten, verwenden Sie die Console oder die gcloud CLI.
Die Clientbibliothek der höheren Ebene wird empfohlen, wenn Sie einen hohen Durchsatz und eine geringe Latenz bei minimalem Betriebsaufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die Clientbibliothek der höheren Ebene die StreamingPull API. Die Clientbibliotheken der höheren Ebene enthalten vordefinierte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Durchsatz- und Latenzoptimierung, Nachrichtenformatierung und andere Funktionen verarbeiten.
Die Low-Level-Clientbibliothek ist eine automatisch generierte gRPC-Bibliothek und wird verwendet, wenn Sie die Dienst-APIs direkt verwenden.
Informationen zur Verwendung der Clientbibliotheken der höheren Ebene finden Sie unter Pub/Sub-Clientbibliotheken.
Informationen zur direkten Verwendung der automatisch generierten Clientbibliotheken auf niedriger Ebene finden Sie unter Pub/Sub APIs – Übersicht.
Im Folgenden finden Sie einige Best Practices für die Verwendung der Clientbibliotheken:
Wählen Sie die richtige Sprache für die Clientbibliothek aus. Die Leistung der Pub/Sub-Clientbibliotheken variiert je nach Sprache. Die Java-Clientbibliothek kann beispielsweise vertikal effektiver skaliert werden als die Python-Clientbibliothek und kann einen höheren Durchsatz verarbeiten. Java, C++ und Go sind effizientere Sprachen im Hinblick auf die Rechenressourcen, die zum Verarbeiten der Veröffentlichungs- oder Abolasten erforderlich sind.
Verwenden Sie die neueste Version der Clientbibliothek. Die Pub/Sub-Clientbibliotheken werden ständig mit neuen Funktionen und Fehlerkorrekturen aktualisiert. Achten Sie darauf, dass Sie die neueste Version der Clientbibliothek für Ihre Sprache verwenden.
Publisher-Clients wiederverwenden Beim Veröffentlichen von Nachrichten ist es effizienter, denselben Publisher-Client wiederzuverwenden, anstatt für jede Veröffentlichungsanfrage neue Publisher-Clients zu erstellen. Das liegt daran, dass nach dem Erstellen eines neuen Publisher-Clients einige Zeit benötigt wird, um eine autorisierte Verbindung herzustellen. In einigen Sprachen wie Node, die keinen expliziten Publisher-Client haben, kannst du das Objekt wiederverwenden, auf das du die publish-Methode aufrufst. Speichern und wiederverwenden Sie das Themenobjekt beispielsweise in Node.
Pub/Sub einrichten
So konfigurieren Sie Pub/Sub:
Erstellen oder wählen Sie ein Google Cloud-Projekt aus, in dem Sie Pub/Sub einrichten können.
Aktivieren Sie die Pub/Sub API.
Erforderliche Rollen und Berechtigungen für die Ausführung von Pub/Sub abrufen
Thema erstellen
Wenn die Nachrichtenstruktur wichtig ist, definieren Sie ein Schema für Ihre Nachrichten.
Hängen Sie das Schema an das Thema an.
Konfigurieren Sie einen Publisher-Client, der Nachrichten für das Thema veröffentlichen kann.
Konfigurieren Sie bei Bedarf erweiterte Veröffentlichungsoptionen wie Ablaufsteuerung, Batch-Messaging und Parallelitätssteuerung.
Wählen Sie einen Abotyp aus, je nachdem, wie Sie Nachrichten erhalten möchten.
Erstellen Sie ein Abo für das ausgewählte Thema.
Konfigurieren Sie einen Abonnentenclient, der Nachrichten vom Abo empfangen kann.
Konfigurieren Sie bei Bedarf erweiterte Optionen für die Nachrichtenübermittlung, z. B. die Zustellung genau einmal, die Ressourcenverwaltung, die geordnete Zustellung und die Ablaufsteuerung.
Veröffentliche Nachrichten von deinem Publisher-Client zum Thema.
Richten Sie gleichzeitig Ihren Abonnentenclient so ein, dass er diese Nachrichten empfängt und verarbeitet.
Richtlinien für die Benennung von Themen, Abos, Schemas oder Snapshots
Ein Pub/Sub-Ressourcenname identifiziert eine Pub/Sub-Ressource wie ein Thema, Abo, Schema oder Snapshot eindeutig. Der Ressourcenname muss folgendermaßen formatiert sein:
projects/project-identifier/collection/ID
project-identifier: Muss die Projekt-ID oder Projektnummer sein, die in der Google Cloud Console verfügbar ist.my-cool-projectist beispielsweise eine Projekt-ID.123456789123ist eine Projektnummer.collection: Musstopics,subscriptions,schemasodersnapshotssein.ID: Sie müssen den folgenden Richtlinien entsprechen:- Beginnen Sie nicht mit der Zeichenfolge
goog. - Muss mit einem Buchstaben beginnen
- Er muss zwischen 3 und 255 Zeichen lang sein
- Er darf nur die folgenden Zeichen enthalten: Buchstaben
[A-Za-z], Zahlen[0-9], Bindestriche-, Unterstriche_, Punkte., Tilden~, Pluszeichen+und Prozentzeichen%.
Die Sonderzeichen in der obigen Liste können in Ressourcennamen ohne URL-Codierung verwendet werden. Sie müssen jedoch sicherstellen, dass alle anderen Sonderzeichen bei der Verwendung in URLs richtig codiert oder decodiert werden. Beispiel:
mi-tópicoist eine ungültige ID.mi-t%C3%B3picoist jedoch gültig. Dieses Format ist wichtig, wenn Sie REST-Aufrufe ausführen.- Beginnen Sie nicht mit der Zeichenfolge
Nächste Schritte
Informationen zum Konfigurieren von Pub/Sub mit der gcloud CLI finden Sie unter Kurzanleitung: Nachrichten in Pub/Sub mit der gcloud CLI veröffentlichen und empfangen.
Informationen zum Konfigurieren von Pub/Sub mit der Google Cloud Console finden Sie in der Kurzanleitung: Nachrichten in Pub/Sub mit der Google Cloud Console veröffentlichen und empfangen.
Informationen zum Konfigurieren von Pub/Sub mithilfe der Clientbibliotheken finden Sie unter Schnellstart: Nachrichten in Pub/Sub mit der Clientbibliothek veröffentlichen und empfangen.