Übersicht über den Pub/Sub-Dienst

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 mehreren wichtigen Konzepten, die anhand der folgenden Abbildung erläutert werden.

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

Ein Pub/Sub-Dienst besteht aus folgenden Komponenten:

  • 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 bestimmt.

  • 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:

  1. 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.

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

  3. Das Thema ist auch mit einem Schema verknüpft.

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

  5. 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 empfängt Abonnent 1 die Nachricht B, während Abonnent 2 die Nachricht A vom Thema empfängt.

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

Lebenszyklus einer Nachricht

Angenommen, ein einzelner Publisher-Client ist mit einem Thema verbunden. Dem Thema ist ein einzelnes Abo zugeordnet. Ein einzelner Abonnent ist mit dem Abo verbunden.

Abbildung, die zeigt, wie eine Nachricht in Pub/Sub übertragen wird.
Abbildung 2: Eine Nachricht wird über Pub/Sub von einem Publisher-Client an einen Abonnentenclient gesendet.

Im Folgenden wird beschrieben, wie eine Nachricht in Pub/Sub übertragen wird:

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

  2. Die Nachricht wird gespeichert.

  3. Während die Nachricht in den Speicher geschrieben wird, stellt Pub/Sub sie an alle mit dem Thema verknüpften Abos zu.

    In diesem Beispiel handelt es sich um ein einzelnes Abo.

  4. Durch das Abo wird die Nachricht an eine angehängte Abonnentenanwendung gesendet.

  5. 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 ist wieder für die Zustellung verfügbar.

Eine Nachricht in einem Pub/Sub-Dienst kann drei Status haben:

  • Bestätigte Nachrichten 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 die Nachricht asynchron aus der Publish-Nachrichtenquelle und aus dem Speicher gelöscht.

  • Nicht bestätigte Nachrichten Wenn Pub/Sub innerhalb der Bestätigungsfrist keine Bestätigung erhält, kann es vorkommen, dass eine Nachricht mehr als einmal zugestellt wird. Beispielsweise sendet der Abonnent möglicherweise eine Bestätigung nach Ablauf der Frist oder die Bestätigung geht aufgrund vorübergehender Netzwerkprobleme verloren. Eine unbestätigte Nachricht wird weiterhin zugestellt, bis die Aufbewahrungsdauer für Nachrichten seit der Veröffentlichung der Nachricht abgelaufen ist. An diesem Punkt läuft die Nachricht ab.

  • Negativ bestätigte Nachrichten (nacked): Wenn ein Abonnent eine Nachricht ablehnt, sendet Pub/Sub sie sofort noch einmal. Dabei werden die Standardeinstellungen für Wiederholungsversuche verwendet, die geändert werden können. Wenn ein Abonnent Nachrichten, die ungültig sind oder die er nicht verarbeiten kann, negativ bestätigt, trägt er dazu bei, dass diese Nachrichten nicht verloren gehen und erfolgreich verarbeitet werden. Sie können modifyAckDeadline mit dem Wert 0 verwenden, um eine Nachricht zu nacken.

Pub/Sub-Publish-/Subscribe-Muster auswählen

Wenn es mehrere Pub/Sub-Publisher- und ‑Subscriber-Clients gibt, müssen Sie auch die Art der Publish/Subscribe-Architektur auswählen, die Sie einrichten möchten.

Abbildung mit verschiedenen Publish- und Subscribe-Mustern.
Abbildung 3 Publisher-Abonnenten-Beziehungen können n:1-Beziehungen (Fan-in), n:n-Beziehungen (Lastenausgleich) und 1:n-Beziehungen (Fan-Out) sein.

Einige der unterstützten Pub/Sub-Publish-/Subscribe-Muster sind:

  • Fan-In (n:1): In diesem Beispiel veröffentlichen mehrere Publisher-Apps Nachrichten zu einem einzelnen 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 des Themas erhält.

  • Load-Balancing (Viele-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 Load-Balancing-Fall 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 aus demselben Abo erhalten.

  • Fan-out (1:n): In diesem Beispiel veröffentlichen eine oder mehrere Publisher-Anwendungen Nachrichten zu einem einzelnen Thema. Dieses einzelne Thema ist mit mehreren Abos verknüpft. Jedes Abo ist mit einer einzelnen Abonnentenanwendung verbunden. 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 für dieselben Nachrichten ausführen müssen, ist „Fan-out“ eine gute Option. Sie können auch mehrere Abonnenten an jedes Abo anhängen und für jeden Abonnenten eine Teilmenge der Nachrichten mit Load Balancing 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 (Clientbibliotheken auf hoher Ebene)
  • REST APIs und RPC APIs (Low-Level-Clientbibliothek)

Die 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 Clientbibliothek auf hoher Ebene wird für Fälle empfohlen, in denen Sie einen hohen Durchsatz und eine niedrige Latenz mit minimalem Betriebsaufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die Clientbibliothek auf hoher Ebene die StreamingPull API. Die Clientbibliotheken auf hoher Ebene enthalten vorgefertigte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Optimierung von Durchsatz und Latenz, Nachrichtenformatierung und andere Funktionen verarbeiten.

Die Low-Level-Clientbibliothek ist eine automatisch generierte gRPC-Bibliothek, die zum Einsatz kommt, 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 der vertikalen 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 zum Verarbeiten der Publish- oder Subscribe-Lasten 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 aktuelle 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 die erste Veröffentlichungsanfrage nach dem Erstellen eines neuen Publisher-Clients einige Zeit benötigt, um eine autorisierte Verbindung herzustellen. In einigen Sprachen wie Node, die keinen expliziten Publisher-Client haben, können Sie das Objekt wiederverwenden, für das Sie die publish-Methode aufrufen. Speichern und verwenden Sie das Themenobjekt beispielsweise in Node wieder.

Pub/Sub einrichten

So konfigurieren Sie 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. Erforderliche Rollen und Berechtigungen zum Ausführen von Pub/Sub abrufen

  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 für das Thema veröffentlichen kann.

  8. Konfigurieren Sie bei Bedarf erweiterte Veröffentlichungsoptionen wie Flusssteuerung, Batch-Messaging und Parallelitätssteuerung.

  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 aus dem Abo empfangen kann.

  12. Konfigurieren Sie bei Bedarf erweiterte Optionen für die Nachrichtenzustellung, z. B. die genaue einmalige Zustellung, die Lease-Verwaltung, die geordnete Zustellung und die Flusssteuerung.

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

  14. Richten Sie gleichzeitig Ihren Abonnentenclient so ein, dass er diese Nachrichten empfängt und verarbeitet.

Richtlinien für die Benennung eines Themas, Abos, Schemas oder Snapshots

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

projects/project-identifier/collection/ID

  • project-identifier: Muss die Projekt-ID oder Projektnummer sein, die in der Google Cloud Konsole verfügbar ist. my-cool-project ist beispielsweise eine Projekt-ID. 123456789123 ist eine Projektnummer.

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

  • ID: Muss 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ópico ist 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