Übersicht über den Pub/Sub-Dienst

Pub/Sub ist ein publish/subscribe (publish/subscribe) publish/subscribe, ein Nachrichtendienst, bei dem die Absender von Nachrichten von den Empfängern entkoppelt sind. Es gibt mehrere Schlüsselkonzepte in einem Pub/Sub-Dienst, die in der folgenden Abbildung erläutert werden.

Abbildung mit verschiedenen Komponenten eines Pub/Sub-Dienstes und deren Verbindung.
Abbildung 1: Zwei Publisher-Clients senden zwei verschiedene Nachrichten an ein gemeinsames Pub/Sub-Thema.

Im Folgenden sind die Komponenten eines Pub/Sub-Dienstes aufgeführt:

  • Publisher (auch als Producer 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 Erhalt von Nachrichten zu einem bestimmten Thema steht.

  • Abonnent (auch als Nutzer bezeichnet): empfängt Nachrichten zu einem bestimmten Abo.

Im folgenden Verfahren wird der Workflow des Pub/Sub-Dienstes erläutert:

  1. Zwei Publisher-Anwendungen, Publisher 1 und Publisher 2, senden Nachrichten an ein einzelnes Pub/Sub-Thema. Publisher 1 sendet Nachricht A und Publisher 2 sendet Nachricht B.

  2. Das Thema selbst ist mit zwei Abos verknüpft. Dies sind Abo 1 und Abo 2.

  3. Das Thema ist außerdem mit einem Schema verknüpft.

  4. Jedes Abo erhält eine Kopie der A- und B-Nachrichten aus dem Thema.

  5. Abo 1 ist mit zwei Abonnentenanwendungen verbunden: Abonnent 1 und Abonnent 2. Die beiden Abonnentenanwendungen empfangen einen Teil der Nachrichten von dem Thema. In diesem Beispiel erhält Abonnent 1 Nachricht B und Abonnent 2 Nachricht A aus dem Thema.

  6. Abo 2 ist nur mit einer einzelnen Abonnentenanwendung namens Abonnent 3 verbunden. Somit erhält Abonnent 3 alle Nachrichten aus dem Thema.

Lebenszyklus einer Nachricht in Pub/Sub

Angenommen, ein einzelner Publisher-Client ist mit einem Thema verbunden. Mit dem Thema ist ein einzelnes Abo verknüpft. Ein einzelner Abonnent ist mit dem Abo verbunden.

Abbildung, die den Nachrichtenfluss in Pub/Sub zeigt.
Abbildung 2: Ein Nachrichtenfluss wird über Pub/Sub von einem Publisher-Client zu einem Abonnentenclient gesendet.

In den folgenden Schritten wird der Nachrichtenfluss in Pub/Sub beschrieben:

  1. Eine Publisher-Anwendung sendet eine Nachricht an ein Pub/Sub-Thema.

  2. Die Nachricht wird gespeichert.

  3. Pub/Sub schreibt die Nachricht nicht nur in den Speicher, sondern liefert sie auch an alle angehängten Abos des Themas.

    In diesem Beispiel handelt es sich um ein einzelnes Abo.

  4. Das Abo sendet die Nachricht an eine angehängte Abonnentenanwendung.

  5. Der Abonnent sendet eine Bestätigung an Pub/Sub, dass er die Nachricht verarbeitet hat.

    Nachdem mindestens ein Abonnent für jedes Abo die Nachricht bestätigt hat, löscht Pub/Sub die Nachricht aus dem Speicher.

Status einer Nachricht in Pub/Sub

Solange eine Nachricht für einen Abonnenten aussteht, versucht Pub/Sub, sie nicht an einen anderen Abonnenten desselben Abos zu senden. Der Abonnent kann die ausstehende Nachricht innerhalb einer konfigurierbaren, begrenzten Zeit (ackDeadline) bestätigen. Nach Ablauf der Frist gilt die Nachricht nicht mehr als ausstehend und Pub/Sub versucht, die Nachricht noch einmal zu senden.

Es gibt drei Status für eine Nachricht in einem Pub/Sub-Dienst:

  • Bestätigte Nachrichten (bestätigt). Nachdem eine Abonnentenanwendung eine Nachricht verarbeitet hat, die von einem Thema an ein Abo gesendet wurde, sendet sie eine Bestätigung an Pub/Sub zurück. Wenn alle Abos eines Themas die Nachricht bestätigt haben, wird die Nachricht asynchron aus der Publish-Nachrichtenquelle und aus dem Speicher gelöscht.

  • Nicht bestätigte Nachrichten (nicht bestätigt): Wenn Pub/Sub innerhalb der Bestätigungsfrist keine Bestätigung erhält, wird eine Nachricht möglicherweise mehrmals zugestellt. Beispielsweise kann der Abonnent nach Ablauf der Frist eine Bestätigung senden oder die Bestätigung kann aufgrund vorübergehender Netzwerkprobleme verloren gehen. Eine nicht bestätigte Nachricht wird weiter zugestellt, bis die Aufbewahrungsdauer seit der Veröffentlichung der Nachricht abgelaufen ist. An dieser Stelle läuft die Nachricht ab.

  • Negativ bestätigte Nachrichten (nackt): Wenn ein Abonnent eine Nachricht zurückstellt, sendet Pub/Sub sie sofort noch einmal. Wenn ein Abonnent Nachrichten versucht, die ungültig sind, oder wenn er die Nachrichten nicht verarbeiten kann, sorgt der Abonnent dafür, dass diese Nachrichten nicht verloren gehen und schließlich erfolgreich verarbeitet werden. Sie können modifyAckDeadline mit dem Wert 0 verwenden, um eine Nachricht zu senden.

Pub/Sub-Veröffentlichungs- und -Abomuster auswählen

Wenn es mehrere Publisher- und Abonnentenclients gibt, müssen Sie auch die Art der Veröffentlichungs- und Abo-Architektur auswählen, die Sie einrichten möchten.

Abbildung mit verschiedenen Veröffentlichungs- und Abomustern.
Abbildung 3: Publisher-Abonnenten-Beziehungen können n:1 (Fan-In), m:n (Load-Balancing) und 1:n (Fan-Out) sein.

Zu den unterstützten Pub/Sub-Veröffentlichungsmustern gehören:

  • Fan in (m:1). In diesem Beispiel veröffentlichen mehrere Publisher-Anwendungen Nachrichten zu einem einzelnen Thema. Dieses 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 abruft.

  • Load-Balancing (m:n): In diesem Beispiel veröffentlichen eine oder mehrere Publisher-Anwendungen Nachrichten zu einem einzelnen Thema. Dieses Thema ist mit einem einzelnen Abo verbunden, das wiederum mit mehreren Abonnentenanwendungen verbunden ist. Jede Abonnentenanwendung erhält eine Teilmenge der veröffentlichten Nachrichten und nicht zwei Abonnentenanwendungen erhalten dieselbe Teilmenge von Nachrichten. In diesem Load-Balancing-Fall verwenden Sie mehrere Abonnenten, um Nachrichten in großem Umfang zu verarbeiten. Wenn mehr Nachrichten unterstützt werden müssen, fügen Sie weitere Abonnenten hinzu, um Nachrichten aus demselben Abo zu erhalten.

  • Fan-Out (1:n): In diesem Beispiel werden Nachrichten von einer oder mehreren Publisher-Anwendungen zu einem einzelnen Thema veröffentlicht. Dieses einzelne Thema ist mit mehreren Abos verknüpft. Jedes Abo ist mit einer einzelnen Abonnentenanwendung verbunden. Jede Abonnentenanwendung 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 für denselben Satz von Nachrichten ausführen müssen, ist das Fan-Out eine gute Option. Sie können jedem Abo auch mehrere Abonnenten hinzufügen und für jeden Abonnenten eine Teilmenge von Nachrichten mit Load-Balancing abrufen.

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 (allgemeine Clientbibliothek)
  • REST API und RPC API (untergeordnete Clientbibliothek)

Ihre Wahl einer Pub/Sub-Konfigurationsoption 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 übergeordnete Clientbibliothek wird empfohlen, wenn Sie einen hohen Durchsatz und eine niedrige Latenz bei minimalem operativem Aufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die übergeordnete Clientbibliothek die StreamingPull API. Die übergeordneten Clientbibliotheken enthalten vordefinierte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Durchsatz- und Latenzoptimierung, Nachrichtenformatierung und andere Funktionen verarbeiten.

Die untergeordnete Clientbibliothek ist eine automatisch generierte gRPC-Bibliothek. Sie kommt ins Spiel, wenn Sie die Dienst-APIs direkt verwenden.

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 ist beispielsweise effektiver bei vertikaler Skalierung als die Python-Clientbibliothek und kann einen höheren Durchsatz verarbeiten. Java, C++ und Go sind effizientere Sprachen in Bezug auf die Rechenressourcen, die für die Verarbeitung 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-Kunden 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 die erste Veröffentlichungsanfrage nach dem Erstellen eines neuen Publisher-Clients einige Zeit benötigt, um eine autorisierte Verbindung herzustellen. Verwenden Sie in einigen Sprachen wie Node, die keinen expliziten Publisher-Client haben, das Objekt, bei dem Sie die Methode „publish“ aufrufen. Speichern Sie beispielsweise in Node das Topic-Objekt und verwenden Sie es wieder.

Pub/Sub einrichten

Hier sind die übergeordneten Schritte zum Konfigurieren von Pub/Sub:

  1. Erstellen oder wählen Sie ein Google Cloud-Projekt aus, in dem Sie Pub/Sub einrichten können.

  2. Aktivieren Sie die Pub/Sub API.

  3. Rufen Sie die erforderlichen Rollen und Berechtigungen zum Ausführen von Pub/Sub ab.

  4. Thema erstellen

  5. Wenn die Nachrichtenstruktur wichtig ist, definieren Sie ein Schema für Ihre Nachrichten.

  6. Hängen Sie das Schema an das Thema an.

  7. Konfigurieren Sie einen Publisher-Client, der Nachrichten zu dem Thema veröffentlichen kann.

  8. Konfigurieren Sie bei Bedarf erweiterte Veröffentlichungsoptionen wie Ablaufsteuerung, Batchnachrichten und Nebenläufigkeitserkennung.

  9. Wählen Sie einen Abotyp aus, je nachdem, wie Sie Nachrichten erhalten möchten.

  10. Erstellen Sie ein Abo für das ausgewählte Thema.

  11. Konfigurieren Sie einen Abonnentenclient, der Nachrichten vom Abo empfangen kann.

  12. Konfigurieren Sie bei Bedarf erweiterte Optionen für die Nachrichtenzustellung, z. B. die genau einmalige Zustellung, die Freigabeverwaltung, die geordnete Zustellung und die Ablaufsteuerung.

  13. Beginnen Sie damit, Nachrichten von Ihrem Publisher-Client zu dem Thema zu veröffentlichen.

  14. Richte deinen Abonnentenclient gleichzeitig so ein, dass diese Nachrichten empfangen und verarbeitet werden.

Richtlinien zum Benennen eines Themas, Abos, Schemas oder Snapshots

Ein Pub/Sub-Ressourcenname kennzeichnet eine Pub/Sub-Ressource eindeutig, z. B. ein Thema, ein Abo, ein Schema oder einen Snapshot. Der Ressourcenname muss das folgende Format haben:

projects/project-identifier/collection/ID

  • project-identifier: Muss die Projekt-ID oder Projektnummer aus der Google Cloud Console sein. Beispiel: my-cool-project ist eine Projekt-ID. 123456789123 ist eine Projektnummer.

  • collection: Muss topics, subscriptions, schemas oder snapshots sein.

  • ID: Muss den folgenden Richtlinien entsprechen:

    • Beginnt nicht mit dem String goog
    • Muss mit einem Buchstaben beginnen
    • Er muss zwischen 3 und 255 Zeichen lang sein
    • Sie dürfen nur die folgenden Zeichen enthalten: Buchstaben [A-Za-z], Ziffern [0-9], Bindestriche -, Unterstriche _, Punkte ., Tilden ~, Pluszeichen + und Prozentzeichen %.

    Sie können die Sonderzeichen aus der vorherigen Liste in Ressourcennamen ohne URL-Codierung verwenden. Alle anderen Sonderzeichen müssen aber richtig codiert oder decodiert werden, wenn sie in URLs verwendet werden. mi-tópico ist beispielsweise eine ungültige ID. mi-t%C3%B3pico ist jedoch gültig. Dieses Format ist wichtig, wenn Sie REST-Aufrufe ausführen.

Nächste Schritte