Abos abrufen

Dieses Dokument bietet einen Überblick über Pull-Abos, den zugehörigen Workflow und die zugehörigen Eigenschaften.

Bei einem Pull-Abo fordert ein Abonnentenclient Nachrichten vom Pub/Sub-Server an.

Im Pull-Modus kann eine der beiden Dienst-APIs verwendet werden: Pull oder StreamingPull. Um die ausgewählte API auszuführen, können Sie eine von Google bereitgestellte Clientbibliothek auf hoher Ebene oder eine automatisch generierte Clientbibliothek auf niedriger Ebene auswählen. Sie können auch zwischen asynchroner und synchroner Nachrichtenverarbeitung wählen.

Hinweise

Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:

Workflow bei Pull-Abos

Bei einem Pull-Abo initiiert Ihr Abonnentenclient Anfragen an einen Pub/Sub-Server, um Nachrichten abzurufen. Der Abonnentenclient verwendet eine der folgenden APIs:

Die meisten Abonnenten-Clients senden diese Anfragen nicht direkt. Stattdessen verwenden die Clients die von Google Cloudbereitgestellte Clientbibliothek auf hoher Ebene, die Streaming-Pull-Anfragen intern ausführt und Nachrichten asynchron zustellt. Für einen Abonnentenclient, der mehr Kontrolle darüber benötigt, wie Nachrichten abgerufen werden, verwendet Pub/Sub eine automatisch generierte gRPC-Bibliothek auf niedriger Ebene. Mit dieser Bibliothek werden Pull- oder Streaming-Pull-Anfragen direkt gestellt. Diese Anfragen können synchron oder asynchron sein.

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

Ablauf von Nachrichten für ein Pull-Abo
Abbildung 1. Workflow für ein Pull-Abo



Ablauf von Nachrichten für ein StreamingPull-Abo
Abbildung 2. Workflow für ein Streaming-Pull-Abo

Pull-Workflow

Der Pull-Workflow sieht so aus (siehe Abbildung 1):

  1. Der Abonnentenclient ruft explizit die Methode pull auf, die Nachrichten zur Zustellung anfordert. Diese Anfrage ist die PullRequest, wie im Bild zu sehen ist.

  2. Der Pub/Sub-Server antwortet mit null oder mehr Nachrichten und Bestätigungs-IDs. Eine Antwort mit null Nachrichten oder mit einem Fehler bedeutet nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind. Diese Antwort ist der PullResponse, wie im Bild dargestellt.

  3. Der Abonnentenclient ruft explizit die Methode acknowledge 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.

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

Attribute eines Pull-Abos

Die Attribute, die Sie für ein Pull-Abo konfigurieren, bestimmen, wie Sie Nachrichten in Ihr Abo schreiben. Weitere Informationen finden Sie unter Abo-Attribute.

Pub/Sub-Dienst-APIs

Für das Pub/Sub-Pull-Abo kann eine der folgenden beiden APIs zum Abrufen von Nachrichten verwendet werden:

  • Pull
  • StreamingPull

Verwenden Sie die unären RPCs „Acknowledge“ und „ModifyAckDeadline“, wenn Sie Nachrichten über diese APIs empfangen. Die beiden Pub/Sub-APIs werden in den folgenden Abschnitten beschrieben.

StreamingPull API

Wo möglich, verwenden die Pub/Sub-Clientbibliotheken StreamingPull für maximalen Durchsatz und niedrigste Latenz. Auch wenn Sie die StreamingPull API vielleicht niemals direkt verwenden, ist es dennoch hilfreich, wenn Sie den Unterschied zur Pull API kennen.

Die StreamingPull API benötigt eine bidirektionale Verbindung, um mehrere Nachrichten zu empfangen, sobald diese verfügbar werden. Der Workflow sieht so aus:

  1. Der Client sendet eine Anfrage an den Server, um eine Verbindung herzustellen. Wenn das Verbindungskontingent überschritten wird, gibt der Server einen Fehler zurück, der darauf hinweist, dass die Ressourcen erschöpft sind. Die Clientbibliothek wiederholt Fehler aufgrund von Überschreitungen des Kontingents automatisch.

  2. Wenn kein Fehler auftritt oder das Verbindungskontingent wieder verfügbar ist, sendet der Server kontinuierlich Nachrichten an den verbundenen Client.

  3. Wenn das Durchsatzkontingent überschritten wird, stoppt der Server das Senden von Nachrichten. Die Verbindung wird jedoch nicht unterbrochen. Sobald wieder ein ausreichendes Durchsatzkontingent verfügbar ist, wird der Stream fortgesetzt.

  4. Der Client oder der Server beendet die Verbindung schließlich.

Die StreamingPull API hält eine offene Verbindung aufrecht. Die Pub/Sub-Server schließen die Verbindung nach einem bestimmten Zeitraum regelmäßig, um eine lang andauernde, statische Verbindung zu vermeiden. Die Clientbibliothek stellt automatisch eine neue StreamingPull-Verbindung her.

Nachrichten werden an die Verbindung gesendet, sobald sie verfügbar sind. Die StreamingPull API minimiert also die Latenz und maximiert den Durchsatz für Nachrichten.

Weitere Informationen zu den StreamingPull-RPC-Methoden StreamingPullRequest und StreamingPullResponse

Pull API

Diese API ist ein herkömmlicher unärer RPC, der auf einem Anfrage- und Antwortmodell basiert. Eine einzelne Pull-Antwort entspricht einer einzelnen Pull-Anfrage. Der Workflow sieht so aus:

  1. Der Client sendet eine Anfrage an den Server. Wenn das Durchsatzkontingent überschritten wird, gibt der Server einen Fehler vom Typ „resource exhausted“ zurück.

  2. Wenn kein Fehler auftritt oder das Kontingent wieder verfügbar ist, antwortet der Server mit null oder mehr Nachrichten und Bestätigungs-IDs.

Wenn Sie die unäre Pull API verwenden, bedeutet eine Antwort mit null Nachrichten oder mit einem Fehler nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind.

Die Verwendung der Pull API garantiert keine niedrige Latenz und keinen hohen Durchsatz von Nachrichten. Um mit der Pull API einen hohen Durchsatz und eine niedrige Latenz zu erzielen, müssen mehrere gleichzeitige ausstehende Anfragen vorhanden sein. Neue Anfragen werden erstellt, wenn auf alte Anfragen geantwortet wird. Das Entwerfen einer solchen Lösung ist fehleranfällig und schwer zu warten. Für solche Anwendungsfälle empfehlen wir die StreamingPull API.

Verwenden Sie die Pull API anstelle der StreamingPull API nur, wenn Sie die folgenden Aspekte genau steuern müssen:

  • Die Anzahl der Nachrichten, die der Abonnentenclient verarbeiten kann
  • Arbeitsspeicher und Ressourcen des Clients

Sie können diese API auch verwenden, wenn Ihr Abonnent ein Proxy zwischen Pub/Sub und einem anderen Dienst ist, der eher pull-orientiert arbeitet.

Weitere Informationen zu den Pull-REST-Methoden finden Sie unter Methode: projects.subscriptions.pull.

Weitere Informationen zu den Pull-RPC-Methoden PullRequest und PullResponse

Arten von Nachrichtenverarbeitungsmodi

Wählen Sie einen der folgenden Pull-Modi für Ihre Abonnentenclients aus.

Asynchroner Pull-Modus

Im asynchronen Pull-Modus wird der Empfang von Nachrichten von der Verarbeitung von Nachrichten in einem Abonnentenclient entkoppelt. Dieser Modus ist die Standardeinstellung für die meisten Abonnentenclients. Im asynchronen Pull-Modus kann die StreamingPull API oder die unäre Pull API verwendet werden. Für das asynchrone Abrufen kann auch die Clientbibliothek auf hoher Ebene oder die automatisch generierte Clientbibliothek auf niedriger Ebene verwendet werden.

Weitere Informationen zu Clientbibliotheken finden Sie weiter unten in diesem Dokument.

Synchrone Pull-Zustellung

Im synchronen Pull-Modus erfolgen der Empfang und die Verarbeitung von Nachrichten sequenziell und sind nicht voneinander entkoppelt. Ähnlich wie bei StreamingPull im Vergleich zu unären Pull-APIs bietet die asynchrone Verarbeitung eine geringere Latenz und einen höheren Durchsatz als die synchrone Verarbeitung.

Verwenden Sie den synchronen Pull-Modus nur für Anwendungen, bei denen niedrige Latenz und hoher Durchsatz im Vergleich zu anderen Anforderungen nicht die wichtigsten Faktoren sind. Eine Anwendung ist beispielsweise möglicherweise auf die Verwendung des synchronen Programmiermodells beschränkt. Oder eine Anwendung mit Ressourcenbeschränkungen erfordert möglicherweise eine genauere Kontrolle über Arbeitsspeicher, Netzwerk oder CPU. Verwenden Sie in solchen Fällen den synchronen Modus mit der unären Pull API.

Pub/Sub-Clientbibliotheken

Pub/Sub bietet eine automatisch generierte Clientbibliothek auf hoher und niedriger Ebene.

Pub/Sub-Clientbibliothek auf hoher Ebene

Die allgemeine Clientbibliothek bietet Optionen zum Steuern der Quittierungsfristen mithilfe der Freigabeverwaltung. Diese Optionen sind detaillierter als bei der Konfiguration der Bestätigungsfristen auf Aboebene über die Console oder die CLI. Die Clientbibliothek auf hoher Ebene bietet auch Unterstützung für Funktionen wie die geordnete Zustellung, die genau einmalige Zustellung und die Ablaufsteuerung.

Wir empfehlen, asynchronen Pull und die StreamingPull API mit der Clientbibliothek auf hoher Ebene zu verwenden. Nicht alle Sprachen, die fürGoogle Cloud unterstützt werden, unterstützen auch die Pull API in der Clientbibliothek auf hoher Ebene.

Informationen zur Verwendung der Clientbibliotheken auf hoher Ebene finden Sie unter Pub/Sub-Clientbibliotheken.

Automatisch generierte Pub/Sub-Clientbibliothek auf niedriger Ebene

Für Fälle, in denen Sie die Pull API direkt verwenden müssen, ist eine Low-Level-Clientbibliothek verfügbar. Sie können die automatisch generierte Clientbibliothek auf niedriger Ebene für die synchrone oder asynchrone Verarbeitung verwenden. Wenn Sie die automatisch generierte Clientbibliothek auf niedriger Ebene verwenden, müssen Sie Funktionen wie die geordnete Zustellung, die Exactly-Once-Zustellung, die Flusssteuerung und die Lease-Verwaltung manuell codieren.

Sie können das synchrone Verarbeitungsmodell verwenden, wenn Sie die automatisch generierte Clientbibliothek auf niedriger Ebene für alle unterstützten Sprachen verwenden. Sie können die automatisch generierte Clientbibliothek auf niedriger Ebene und den synchronen Pull verwenden, wenn die direkte Verwendung der Pull API sinnvoll ist. Möglicherweise haben Sie beispielsweise vorhandene Anwendungslogik, die auf diesem Modell basiert.

Wenn Sie die automatisch generierten Clientbibliotheken auf niedriger Ebene direkt verwenden möchten, lesen Sie die Übersicht über die Pub/Sub APIs.

Nächste Schritte