Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Abonnentenübersicht

Dieses Dokument bietet einen Überblick über die Funktionen von Abos in Pub/Sub. Weitere Informationen zu den Pull- und Push-Zustellungsabos finden Sie im Pull-Abonnentenleitfaden und im Push-Abonnentenleitfaden.

Um zu einem Thema veröffentlichte Nachrichten empfangen zu können, müssen Sie ein Abo dieses Themas erstellen. Nur Nachrichten, die nach dem Erstellen des Abos für das Thema veröffentlicht wurden, sind für Abonnentenanwendungen verfügbar. Durch das Abo wird das Thema mit einer Abonnentenanwendung verbunden, die Nachrichten empfängt und verarbeitet, die für das Thema veröffentlicht wurden. Für ein Thema sind mehrere Abos möglich, aber jedes Abo gehört zu einem einzelnen Thema.

Weitere Informationen zum Erstellen und Aktualisieren von Abos finden Sie in Themen und Abos verwalten.

Mindestens einmalige Zustellung

Pub/Sub stellt jede veröffentlichte Nachricht mindestens einmal pro Abo zu. Dabei gibt es einige Ausnahmen:

  • Nachrichten, die innerhalb der maximalen Aufbewahrungsdauer von sieben Tagen nicht zugestellt werden können, werden gelöscht und sind nicht mehr verfügbar. Dies kommt vor, wenn Abonnenten den Fluss der Nachrichten nicht regelmäßig verfolgen. Beachten Sie, dass Sie für Nachrichten eine Aufbewahrungsdauer konfigurieren können, die zwischen zehn Minuten und sieben Tagen liegt. Weitere Informationen zur Einstellung der Nachrichtenaufbewahrung finden Sie unter Nachrichten wiedergeben und verwerfen.
  • Nachrichten, die vor der Erstellung eines Abos veröffentlicht wurden, werden normalerweise nicht zugestellt. Somit wird eine Nachricht, die zu einem Thema ohne Abo veröffentlicht wurde, an keinen Abonnenten gesendet.

Wenn eine Nachricht an einen Abonnenten gesendet wurde, sollte dieser den Empfang bestätigen. Eine Nachricht gilt als ausstehend, wenn sie zur Zustellung gesendet und noch nicht von einem Abonnenten bestätigt wurde. Pub/Sub versucht wiederholt, nicht bestätigte Nachrichten zuzustellen. 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, sodass Pub/Sub versucht, die Nachricht noch einmal zu senden.

Normalerweise stellt Pub/Sub jede Nachricht einmal und in der Reihenfolge ihrer Veröffentlichung zu. Nachrichten können aber auch außerhalb der Reihenfolge oder öfter als einmal zugestellt werden. Im Allgemeinen erfordert eine mehrmalige Zustellung, dass der Abonnent bei der Verarbeitung von Nachrichten idempotent ist. Mit Apache Beam programming model können Sie PubSub-Nachrichten-Streams genau einmal verarbeiten. Mit den E/A-Connectors von Apache Beam können Sie über gesteuerte Quellen und Senken mit Cloud Dataflow interagieren. Sie können den Connector Apache Beam PubSubIO (für Java und Python) zum Lesen aus Cloud Pub/Sub verwenden. Sie können die Verarbeitung in einer bestimmten Reihenfolge auch mit Cloud Dataflow erreichen. Dazu verwenden Sie die Standardsortier-APIs des Dienstes. Alternativ kann der Publisher des Themas, das Sie abonnieren, zur Festlegung der Reihenfolge ein Sequenztoken in die Nachricht einfügen. Weitere Informationen finden Sie unter Nachrichtenreihenfolge.

Pull- oder Push-Zustellung

Für die Nachrichtenzustellung durch ein Abo kann entweder der Push- oder der Pull-Mechanismus verwendet werden. Den Mechanismus können Sie jederzeit ändern oder konfigurieren.

Pull-Abo

Bei der Pull-Zustellung initiiert Ihre Abonnentenanwendung, wenn sie Nachrichten abrufen soll, Anfragen beim Pub/Sub-Server.

  1. Die abonnierende Anwendung ruft explizit die Pull-Methode auf, die Nachrichten zur Zustellung anfordert.
  2. Der Pub/Sub-Server antwortet mit der Nachricht (oder einem Fehler, wenn die Warteschlange leer ist) und einer Bestätigungs-ID.
  3. Der Abonnent ruft dann ausdrücklich die Bestätigungsmethode auf und bestätigt den Empfang mit der zurückgegebenen Bestätigungs-ID.

Ablauf von Pull-Abo-Nachrichtenanfragen

Push-Abo

Bei der Push-Lieferung initiiert Pub/Sub, wenn es Nachrichten zustellen soll, Anfragen bei Ihrer Abonnentenanwendung.

  1. Der Pub/Sub-Server sendet jede Nachricht als HTTPS-Anfrage an die Abonnentenanwendung an einem vorkonfigurierten Endpunkt.
  2. Der Endpunkt bestätigt die Nachricht, indem er einen HTTP-Erfolgsstatuscode zurückgibt. Wenn in der Antwort angegeben wird, dass der Vorgang nicht erfolgreich war, muss die Nachricht noch einmal gesendet werden.

Ablauf von Push-Abo-Nachrichtenanfragen

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

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

Pull Push
  • Hohe Anzahl von Nachrichten (deutlich mehr als 1/Sekunde).
  • Effizienz und Durchsatz der Nachrichtenverarbeitung sind entscheidend.
  • Es ist nicht möglich, einen öffentlichen HTTPS-Endpunkt mit nicht selbst signiertem SSL-Zertifikat einzurichten.
  • 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.

In der folgenden Tabelle werden Pull- und Push-Zustellung verglichen:

  Pull Push
Endpoints Jedes Gerät im Internet mit autorisierten Anmeldedaten kann die Pub/Sub API aufrufen. Ein im Internet verfügbarer HTTPS-Server mit nicht selbst signiertem Zertifikat. Der empfangende Endpunkt kann von dem Pub/Sub-Abo getrennt werden, damit Nachrichten aus mehreren Abos an einen einzigen Endpunkt gesendet werden können.
Load-Balancing Mehrere Abonnenten können Abrufe bei dem gleichen "geteilten" Abonnenten durchführen. Jeder Abonnent erhält einen bestimmten Teil der Nachrichten. Der Push-Endpunkt kann ein Load-Balancer sein.
Konfiguration Keine Konfiguration notwendig. Für App Engine-Anwendungen im selben Projekt wie der Abonnent ist keine Konfiguration erforderlich.
Die Überprüfung von Push-Endpunkten ist in der Google Cloud Console nicht erforderlich. Endpunkte müssen über DNS-Namen erreichbar sein und für sie müssen SSL-Zertifikate installiert sein.
Ablaufsteuerung Der Abonnentenclient steuert das Tempo der Zustellung. Der Abonnent kann das Bestätigungszeitlimit dynamisch ändern und ermöglicht damit beliebig lange Nachrichtenverarbeitung. Der Pub/Sub-Server implementiert automatisch eine Ablaufsteuerung. Es ist nicht erforderlich, den Nachrichtenfluss auf der Clientseite zu verarbeiten (man kann jedoch angeben, dass der Client die aktuelle Nachrichtenlast nicht bewältigen kann, indem man einen HTTP-Fehler zurückgibt).
Effizienz und Durchsatz Erzielt hohen Durchsatz mit geringer CPU-Leistung und Bandbreite durch Unterstützung von Stapelzustellung und -Bestätigungen sowie Massenparallelverarbeitung. Ist möglicherweise ineffizient, wenn versucht wird, durch aggressiven Abruf die Nachrichtenzustellungszeit zu minimieren. Stellt eine Nachricht pro Anfrage zu und begrenzt die Höchstzahl der ausstehenden Nachrichten.

Lebenszyklus eines Abos

Abos laufen standardmäßig nach 31 Tagen Inaktivität ab. Inaktivität liegt beispielsweise vor, wenn keine aktiven Verbindungen, Pull-Anfragen oder erfolgreichen Push-Vorgänge vorhanden sind. Erkennt Pub/Sub Aktivitäten von Abonnenten, wird die Zeit bis zum Löschen des Abos wieder zurückgesetzt. In Ablaufrichtlinien können Sie den Zeitraum der Inaktivität konfigurieren oder das Abo unabhängig von seinem Alter dauerhaft einrichten. Sie können ein Abo auch manuell löschen.

Beachten Sie, dass Sie zwar ein neues Abo mit demselben Namen wie ein gelöschtes erstellen können, das neue Abo jedoch keine Beziehung zum alten Abo hat. Auch wenn das gelöschte Abo eine große Zahl nicht bestätigter Nachrichten enthielt, wird dieser Rückstand an noch zuzustellenden Nachrichten bei der Erstellung des neuen Abos mit identischem Namen nicht übernommen.

Weitere Informationen zum Arbeiten mit Abos finden Sie unter Abos konfigurieren.

Themen mit Schema abonnieren

Themen können Schemas verwenden, um ein Format für die Nachrichten zu definieren. Wenn Sie ein Thema mit einem Schema abonnieren, erhalten die an den Abonnenten gesendeten Nachrichten garantiert gültige Nachrichten vom Typ und Codierung, die in den Schemaeinstellungen des Themas angegeben sind. Der Abonnent kann die Schema-Einstellungen für ein Thema anhand von zwei Attributen bestimmen:

  • googclient_schemaname: Der Name des Schemas für die Validierung. Wenn das Schema gelöscht wurde, lautet der Name _deleted-schema_
  • googclient_schemaencoding: Die Codierung der Nachricht, entweder JSON in BINARY