Abotyp auswählen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Dieses Dokument bietet einen Überblick über die verschiedenen Abotypen in Pub/Sub.

Aboübersicht

Damit Sie Nachrichten zu einem Thema erhalten, müssen Sie ein Abo für dieses Thema erstellen. Nur Nachrichten, die nach dem Erstellen des Abos für das Thema veröffentlicht wurden, sind für Abonnentenclients verfügbar. Sie können jedoch auch die Aufbewahrung von Themen aktivieren, damit ein mit dem Thema verknüpftes Abo in der Vergangenheit liegen und zuvor veröffentlichte Nachrichten wiedergeben kann. Der Abonnentenclient empfängt und verarbeitet die im Thema veröffentlichten Nachrichten. Ein Thema kann mehrere Abos haben, aber ein bestimmtes Abo gehört zu einem einzelnen Thema.

Abo-Workflow

  1. Nachdem eine Nachricht an einen Abonnenten gesendet wurde, muss er die Nachricht bestätigen.

  2. Wenn eine Nachricht zur Zustellung gesendet wird und sie noch nicht von einem Abonnenten bestätigt wurde, wird sie als „ausstehend“ bezeichnet.

  3. Pub/Sub versucht wiederholt, eine Nachricht zuzustellen, die noch nicht bestätigt wurde. Pub/Sub versucht jedoch nicht, eine ausstehende Nachricht an andere Abonnenten im selben Abo zu senden.

  4. Der Abonnent hat einen konfigurierbaren, begrenzten Zeitraum, der als ackDeadline bezeichnet wird, um die ausstehende Nachricht zu bestätigen. Nach Ablauf der Frist gilt die Nachricht nicht mehr als ausstehend und Pub/Sub versucht, die Nachricht noch einmal zuzustellen.

Arten von Abos

Wenn Sie ein Abo erstellen, müssen Sie die Art der Nachrichtenzustellung festlegen. Pub/Sub bietet drei Arten der Nachrichtenzustellung, die den folgenden drei Abotypen entsprechen. Jede Art von Abo wird in späteren Abschnitten dieses Dokuments beschrieben.

  • Pull-Abo
  • Push-Abo
  • BigQuery-Abo

Sie können den Abotyp jederzeit aktualisieren.

Pull-Abo

Bei einem Pull-Abo initiiert der Abonnentenclient Anfragen an einen Pub/Sub-Server, um Nachrichten abzurufen. Der Abonnentenclient verwendet die REST Pull API, die RPC PullRequest API, die REST StreamingPullRequest API oder die RPC StreamingPullRequest API. Die meisten Abonnenten senden diese Anfragen nicht direkt. Stattdessen nutzen die Clients die übergeordnete Clientbibliothek von Google Cloud, die intern Pull-Pull-Anfragen ausführt und Nachrichten asynchron sendet. Für einen Abonnentenclient, der mehr Kontrolle über den Abruf von Nachrichten benötigt, verwendet Pub/Sub eine untergeordnete und automatisch generierte gRPC-Bibliothek. Diese Bibliothek sendet Pull- oder Streaming-Pull-Anfragen direkt. Diese Anfragen können synchron oder asynchron sein.

Die folgenden beiden Images zeigen den Workflow zwischen einem Abonnentenclient und einem Pull-Abo.

Nachrichtenfluss für ein Pull-Abo
Abbildung 1: Workflow für ein Pull-Abo


Nachrichtenfluss für ein streamingPull-Abo
Abbildung 2: Workflow für ein Streaming-Pull-Abo

Der Pull-Workflow sieht so aus und verweist auf Abbildung 1:

  1. Der Abonnentenclient ruft explizit die Pull-Methode auf, die Nachrichten zur Zustellung anfordert. Diese Anfrage ist die Pull-Anfrage, wie im Bild gezeigt.

  2. Der Pub/Sub-Server antwortet mit null oder mehr Nachrichten und Bestätigungs-IDs. Eine Antwort ohne Nachrichten oder mit einem Fehler weist nicht unbedingt darauf hin, dass keine Nachrichten für den Empfang verfügbar sind. Diese Antwort ist die PullImage-Antwort, die im Bild zu sehen ist.

  3. Der Abonnentenclient ruft explizit die bestätigte Methode auf. Der Client verwendet die zurückgegebene Bestätigungs-ID, um zu bestätigen, dass die Nachricht verarbeitet wurde und nicht noch einmal zugestellt werden muss. Diese Anfrage ist die „AckRequest“ wie im Bild gezeigt.

Bei einer einzelnen Streaming-Pull-Anfrage kann ein Abonnentenclient aufgrund der offenen Verbindung mehrere Antworten zurückgeben. Im Gegensatz dazu wird für jede Pull-Anfrage nur eine Antwort zurückgegeben.

Weitere Informationen zur Funktionsweise eines Pull-Abos und Konfigurationsbeispiele finden Sie unter Pull-Abos.

Push-Abo

In einem Push-Abo initiiert ein Pub/Sub-Server eine Anfrage an Ihren Abonnentenclient, um Nachrichten zuzustellen.

Die folgende Abbildung zeigt den Workflow zwischen einem Abonnentenclient und einem Push-Abo.

Nachrichtenfluss für ein Push-Abo
Abbildung 3: Workflow für ein Push-Abo

Hier ist eine kurze Beschreibung des Workflows, der auf Abbildung 3 verweist:

  1. Der Pub/Sub-Server sendet jede Nachricht als HTTPS-Anfrage an einen vorkonfigurierten Endpunkt an den Abonnentenclient. Diese Anfrage wird als PushRequest im Bild angezeigt.

  2. Der Endpunkt bestätigt die Nachricht, indem er einen HTTP-Erfolgsstatuscode zurückgibt. Eine nicht erfolgreiche Antwort gibt an, dass Pub/Sub die Nachrichten noch einmal senden muss. Diese Antwort wird als PushResponse im Bild angezeigt.

  3. Pub/Sub passt die Rate von Push-Anfragen dynamisch anhand der Rate an, mit der Erfolgsantworten empfangen werden.

Weitere Informationen zur Funktionsweise eines Push-Abos und Beispiele zur Konfiguration finden Sie unter Push-Abos.

BigQuery-Abo

Ein BigQuery-Abo schreibt Nachrichten in eine vorhandene BigQuery-Tabelle, wenn sie empfangen werden. Sie müssen keinen separaten Abonnentenclient konfigurieren.

Ohne den BigQuery-Abotyp benötigen Sie ein Pull- oder Push-Abo und einen Abonnenten (z. B. Dataflow), der Nachrichten liest und in eine BigQuery-Tabelle schreibt. Der Aufwand für das Ausführen eines Dataflow-Jobs ist nicht erforderlich, wenn Nachrichten keine zusätzliche Verarbeitung erfordern, bevor sie in einer BigQuery-Tabelle gespeichert werden. Sie können stattdessen ein BigQuery-Abo verwenden. Für Pub/Sub-Systeme, bei denen eine gewisse Datentransformation erforderlich ist, bevor die Daten in einer BigQuery-Tabelle gespeichert werden, wird jedoch eine Dataflow-Pipeline empfohlen. Informationen zum Streamen von Daten von Pub/Sub zu BigQuery mit Transformation mithilfe von Dataflow finden Sie unter Stream von Pub/Sub zu BigQuery.

Die folgende Abbildung zeigt den Workflow zwischen einem BigQuery-Abo und BigQuery.

Nachrichtenfluss für ein BigQuery-Abo
Abbildung 4: Workflow für ein BigQuery-Abo

Hier ist eine kurze Beschreibung des Workflows, der auf Abbildung 4 verweist:

  1. Pub/Sub verwendet die BigQuery Storage Write API, um Daten an die BigQuery-Tabelle zu senden.
  2. Die Nachrichten werden in Batches an die BigQuery-Tabelle gesendet.
  3. Nach erfolgreichem Abschluss eines Schreibvorgangs gibt die API eine OK-Antwort zurück.
  4. Wenn während des Schreibvorgangs Fehler auftreten, wird die Pub/Sub-Nachricht selbst negativ bestätigt. Die Nachricht wird dann noch einmal gesendet. Wenn die Nachricht zu oft fehlschlägt und für das Abo ein Thema für unzustellbare Nachrichten konfiguriert ist, wird die Nachricht in das Thema für unzustellbare Nachrichten verschoben.

Weitere Informationen zur Funktionsweise eines BigQuery-Abos finden Sie unter BigQuery-Abos.

Abotyp auswählen

Die folgende Tabelle enthält Informationen zur Auswahl des richtigen Zustellungsmechanismus für Ihre Anwendung:

  Pull Push BigQuery
Anwendungsfall
  • Große Menge an Nachrichten (GB/Sekunde).
  • Effizienz und Durchsatz der Nachrichtenverarbeitung sind entscheidend.
  • Umgebungen, in denen kein öffentlicher HTTPS-Endpunkt mit einem nicht selbst signierten SSL-Zertifikat eingerichtet werden kann.
  • Mehrere Themen, die vom selben Webhook verarbeitet werden müssen.
  • Abonnenten der App Engine-Standardumgebung und Cloudfunktionen.
  • Umgebungen, in denen keine Google Cloud-Abhängigkeiten (z. B. Anmeldedaten und die Clientbibliothek) eingerichtet werden können.
  • Große Anzahl von Nachrichten, die auf mehrere Millionen Nachrichten pro Sekunde hochskaliert werden können.
  • Nachrichten werden ohne zusätzliche Verarbeitung direkt an BigQuery gesendet.
Endpoints Die Pub/Sub API kann von jedem Gerät im Internet mit autorisierten Anmeldedaten aufgerufen werden. Ein im Internet verfügbarer HTTPS-Server mit nicht selbst signiertem Zertifikat. Der empfangende Endpunkt kann vom Pub/Sub-Abo entkoppelt werden, sodass Nachrichten von mehreren Abos an einen einzelnen Endpunkt gesendet werden können. Eine BigQuery-Tabelle.
Load-Balancing Mehrere Abonnenten können dasselbe gemeinsame Abo aufrufen (Pull). Jeder Abonnent empfängt einen Teil der Nachrichten. Der Push-Endpunkt kann ein Load-Balancer sein. Der Pub/Sub-Dienst gleicht die Last automatisch aus.
Configuration Keine Konfiguration notwendig. Für App Engine-Anwendungen, die sich im selben Projekt wie der Abonnent befinden, ist keine Konfiguration erforderlich.
In der Google Cloud Console ist keine Überprüfung von Push-Endpunkten erforderlich. Endpunkte müssen über DNS-Namen erreichbar sein und für sie müssen SSL-Zertifikate installiert sein.
Für das Themenabo muss eine BigQuery-Tabelle vorhanden sein.
Ablaufsteuerung Der Abonnentenclient steuert die Auslieferungsrate. Der Abonnent kann die Bestätigungsfrist dynamisch ändern, sodass die Nachrichtenverarbeitung beliebig lang sein kann. Der Pub/Sub-Server implementiert automatisch eine Ablaufsteuerung. Der Nachrichtenfluss muss nicht clientseitig verarbeitet werden. Es kann jedoch auch angezeigt werden, dass der Client die aktuelle Nachrichtenlast nicht bewältigen kann, indem er einen HTTP-Fehler zurückgibt. Der Pub/Sub-Server implementiert automatisch die Ablaufsteuerung, um das Schreiben von Nachrichten in BigQuery zu optimieren.
Effizienz und Durchsatz Erzielt einen hohen Durchsatz bei geringer CPU- und Bandbreite, da die Batchbereitstellung und -bestätigungen sowie ein massiv paralleler Verbrauch möglich sind. Kann ineffizient sein, wenn aggressive Abfragen verwendet werden, um die Nachrichtenzustellungszeit zu minimieren. Es wird eine Nachricht pro Anfrage gesendet und die maximale Anzahl der ausstehenden Nachrichten begrenzt. Die Skalierbarkeit wird dynamisch von Pub/Sub-Servern verarbeitet.

Standardaboeigenschaften

Standardmäßig bietet Pub/Sub eine mindestens einmalige Übermittlung ohne Sortiergarantien für alle Abotypen. Wenn Nachrichten denselben Sortierschlüssel haben und sich in derselben Region befinden, können Sie auch die Nachrichtenreihenfolge aktivieren. Nachdem Sie die Property für die Nachrichtenreihenfolge festgelegt haben, liefert der Pub/Sub-Dienst Nachrichten mit demselben Sortierschlüssel und in der Reihenfolge, in der der Pub/Sub-Dienst die Nachrichten empfängt.

Pub/Sub unterstützt auch die genau einmalige Zustellung.

Im Allgemeinen liefert Pub/Sub jede Nachricht einmal und in der Reihenfolge, in der sie veröffentlicht wurde. Nachrichten können jedoch in falscher Reihenfolge oder mehr als einmal zugestellt werden. Pub/Sub kann eine Nachricht noch einmal senden, auch wenn eine Bestätigungsanfrage für die Nachricht erfolgreich zurückgegeben wurde. Diese erneute Bereitstellung kann durch Probleme wie serverseitige Neustarts oder clientseitige Probleme verursacht werden. Daher kann jede Nachricht, die selten vorkommt, jederzeit erneut übermittelt werden. Wenn Sie mehr als eine Zustellung zulassen, muss Ihr Abonnent bei der Verarbeitung von Nachrichten idempotent sein.

Aboablauf

Abos laufen standardmäßig nach 31 Tagen Inaktivität ab oder werden nicht aktualisiert. Beispiele für Abonnentenaktivitäten sind offene Verbindungen, aktive Pull- oder erfolgreiche Push-Vorgänge. Wenn Pub/Sub Abonnentenaktivitäten oder eine Aktualisierung der Abo-Properties erkennt, wird die Zeit zum Löschen des Abos neu gestartet. Mit Richtlinien zum Ablauf des Abos können Sie die Inaktivitätsdauer konfigurieren oder das Abo unabhängig von der Aktivität dauerhaft einrichten. Sie können ein Abo auch manuell löschen.

Sie können zwar ein neues Abo mit dem Namen eines gelöschten Abos erstellen, aber das neue Abo hat keine Beziehung zum alten Abo. Selbst wenn das gelöschte Abo viele nicht bestätigte Nachrichten aufwies, hatte ein neues Abo mit demselben Namen zum Zeitpunkt der Erstellung keinen Rückstand (keine zuzustellenden Nachrichten).

Weitere Informationen zum Arbeiten mit Abos finden Sie unter Abos erstellen und verwenden.

Nächste Schritte