Dieses Dokument bietet eine Übersicht über ein Pull-Abo, seinen Workflow und die zugehörigen Attribute.
In 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. Zum Ausführen der ausgewählten API können Sie eine von Google bereitgestellte übergeordnete Clientbibliothek oder eine automatisch generierte Low-Level-Clientbibliothek auswählen. Sie können auch zwischen der asynchronen und der synchronen Nachrichtenverarbeitung wählen.
Hinweise
Bevor Sie dieses Dokument lesen, machen Sie sich mit folgenden Themen vertraut:
Funktionsweise von Pub/Sub und die verschiedenen Pub/Sub-Begriffe
Die verschiedenen Arten von Abos, die Pub/Sub unterstützt, und warum Sie ein Pull-Abo verwenden sollten.
Workflow für 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 Abonnentenclients stellen diese Anfragen nicht direkt. Stattdessen stützen sich die Clients auf die von Google Cloud bereitgestellte allgemeine Clientbibliothek, die Streaming-Pull-Anfragen intern ausführt und Nachrichten asynchron sendet. Für einen Abonnentenclient, der mehr Kontrolle darüber benötigt, wie Nachrichten abgerufen werden, verwendet Pub/Sub eine untergeordnete und automatisch generierte gRPC-Bibliothek. Diese Bibliothek führt Pull- oder Streaming-Pull-Anfragen direkt aus. Diese Anfragen können synchron oder asynchron sein.
Die folgenden beiden Bilder zeigen den Workflow zwischen einem Abonnentenclient und einem Pull-Abo.


Pull-Workflow
Der Pull-Workflow sieht so aus und bezieht sich auf Abbildung 1:
- Der Abonnentenclient ruft explizit die Methode
pull
auf, die Nachrichten zur Zustellung anfordert. Diese Anfrage ist derPullRequest
, wie in der Abbildung dargestellt. Der Pub/Sub-Server antwortet mit null oder mehr Nachrichten und Bestätigungs-IDs. Eine Antwort ohne Nachrichten oder mit einem Fehler bedeutet nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind. Diese Antwort ist der
PullResponse
, wie in der Abbildung dargestellt.Der Abonnentenclient ruft die Methode
acknowledge
explizit auf. Der Client bestätigt anhand der zurückgegebenen Bestätigungs-ID, dass die Nachricht verarbeitet wurde und nicht noch einmal zugestellt werden muss.
Für eine einzelne Streaming-Pull-Anfrage können aufgrund der offenen Verbindung mehrere Antworten eines Abonnentenclients zurückgegeben werden. Im Gegensatz dazu wird für jede Pull-Anfrage nur eine Antwort zurückgegeben.
Attribute eines Pull-Abos
Die Attribute, die Sie für ein Pull-Abo konfigurieren, bestimmen, wie Nachrichten an Ihr Abo geschrieben werden. Weitere Informationen findest du unter Aboattribute.
APIs für Pub/Sub-Dienste
Das Pub/Sub-Pull-Abo kann eine der folgenden beiden APIs zum Abrufen von Nachrichten verwenden:
- Pull
- StreamingPull
Verwenden Sie unäre Bestätigungs- und ModifyAckDeadline-RPCs, wenn Sie Nachrichten über diese APIs empfangen. Die beiden Pub/Sub APIs werden auf den folgenden Tabs beschrieben.
StreamingPull API
Wenn möglich, verwenden die Pub/Sub-Clientbibliotheken StreamingPull für maximalen Durchsatz und niedrigste Latenz. Auch wenn Sie die StreamingPull API möglicherweise nie direkt verwenden, ist es wichtig zu wissen, wie sie sich von der Pull API unterscheidet.
Die StreamingPull API benötigt eine persistente bidirektionale Verbindung, um mehrere Nachrichten zu empfangen, sobald diese verfügbar sind. Der Workflow sieht so aus:
Der Client sendet eine Anfrage an den Server, um eine Verbindung herzustellen. Wenn das Verbindungskontingent überschritten wird, gibt der Server den Fehler „Ressource erschöpft“ zurück. Die Clientbibliothek wiederholt die Fehler aufgrund von überschrittenen Kontingenten automatisch.
Wenn kein Fehler auftritt oder das Verbindungskontingent wieder verfügbar ist, sendet der Server kontinuierlich Nachrichten an den verbundenen Client.
Wenn das Durchsatzkontingent überschritten wird, sendet der Server keine Nachrichten mehr. Die Verbindung ist jedoch nicht unterbrochen. Sobald wieder genügend Durchsatzkontingent verfügbar ist, wird der Stream fortgesetzt.
Der Client oder der Server trennt schließlich die Verbindung.
Die StreamingPull API hält eine offene Verbindung. Die Pub/Sub-Server beenden die Verbindung wiederholt nach einem bestimmten Zeitraum, um eine dauerhafte Verbindung zu vermeiden. Die Clientbibliothek öffnet automatisch eine StreamingPull-Verbindung.
Nachrichten werden an die Verbindung gesendet, sobald sie verfügbar sind. Die StreamingPull API minimiert somit die Latenz und maximiert den Nachrichtendurchsatz.
Weitere Informationen zu den StreamingPull-REST-Methoden finden Sie unter StreamingPullRequest und StreamingPullResponse.
Weitere Informationen zu den StreamingPull-RPC-Methoden: StreamingPullRequest und StreamingPullResponse.
Pull-API
Diese API ist ein traditioneller unärer RPC, der auf einem Anfrage- und Antwortmodell basiert. Eine einzelne Pull-Antwort entspricht einer einzelnen Pull-Anfrage. Der Workflow sieht so aus:
Der Client sendet eine Anfrage an den Server. Wenn das Durchsatzkontingent überschritten wird, gibt der Server den Fehler „Ressource erschöpft“ zurück.
Wenn kein Fehler auftritt oder das Durchsatzkontingent 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 einem Fehler nicht unbedingt, dass keine Nachrichten zum Empfangen verfügbar sind.
Die Verwendung der Pull API garantiert keine niedrige Latenz und einen hohen Nachrichtendurchsatz. Wenn Sie einen hohen Durchsatz und eine niedrige Latenz mit der Pull API erzielen möchten, müssen Sie mehrere ausstehende Anfragen gleichzeitig haben. Neue Anfragen werden erstellt, wenn alte Anfragen eine Antwort erhalten. Die Entwicklung einer solchen Lösung ist fehleranfällig und schwer zu pflegen. Für solche Anwendungsfälle empfehlen wir die StreamingPull API.
Verwenden Sie die Pull API nur dann anstelle der StreamingPull API, wenn Sie eine strenge Kontrolle über Folgendes benötigen:
- 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 stärker Pull-orientiert arbeitet.
Weitere Informationen zu den Pull-REST-Methoden finden Sie unter Method: projects.subscriptions.pull.
Weitere Informationen zu den Pull-RPC-Methoden finden Sie unter PullRequest und PullResponse.
Arten von Modi für die Nachrichtenverarbeitung
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 für die meisten Abonnentenclients die Standardeinstellung. Im asynchronen Pull-Modus kann die StreamingPull API oder die unäre Pull API verwendet werden. Für die asynchrone Pull-Zustellung kann auch die übergeordnete Clientbibliothek oder die automatisch generierte Clientbibliothek auf niedriger Ebene verwendet werden.
Weitere Informationen zu Clientbibliotheken finden Sie weiter unten in diesem Dokument.
Synchroner Pull-Modus
Im synchronen Pull-Modus erfolgen der Empfang und die Verarbeitung von Nachrichten nacheinander und sind nicht voneinander entkoppelt. Ähnlich wie 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 eine niedrige Latenz und ein hoher Durchsatz im Vergleich zu einigen anderen Anforderungen nicht die wichtigsten Faktoren sind. Beispielsweise kann eine Anwendung auf die Verwendung des synchronen Programmiermodells beschränkt sein. Eine Anwendung mit Ressourceneinschränkungen kann auch eine genauere Kontrolle über Arbeitsspeicher, Netzwerk oder CPU erfordern. Verwenden Sie in solchen Fällen den synchronen Modus mit der unären Pull API.
Pub/Sub-Clientbibliotheken
Pub/Sub bietet eine High-Level- und eine Low-Level-Clientbibliothek, die automatisch generiert wird.
Allgemeine Pub/Sub-Clientbibliothek
Die allgemeine Clientbibliothek bietet Optionen zum Steuern der Bestätigungsfristen mithilfe der Lease-Verwaltung. Diese Optionen sind detaillierter als bei der Konfiguration der Bestätigungsfristen über die Console oder die Befehlszeile auf Aboebene. Die übergeordnete Clientbibliothek unterstützt auch Funktionen wie die geordnete Zustellung, die genau einmalige Übermittlung und die Ablaufsteuerung.
Wir empfehlen die Verwendung der asynchronen Pull-Zustellung und der StreamingPull API mit der allgemeinen Clientbibliothek. Nicht alle für Google Cloud unterstützten Sprachen unterstützen auch die Pull API in der allgemeinen Clientbibliothek.
Informationen zur Verwendung der allgemeinen Clientbibliotheken finden Sie unter Pub/Sub-Clientbibliotheken.
Automatisch generierte Low-Level-Pub/Sub-Clientbibliothek
Eine untergeordnete Clientbibliothek ist verfügbar, wenn Sie die Pull API direkt verwenden müssen. Sie können die synchrone oder asynchrone Verarbeitung mit der untergeordneten, automatisch generierten Clientbibliothek verwenden. Wenn Sie die untergeordnete, automatisch generierte Clientbibliothek verwenden, müssen Sie Features wie die geordnete Zustellung, die genau einmalige Zustellung, die Ablaufsteuerung und die Freigabeverwaltung manuell codieren.
Sie können das Modell für die synchrone Verarbeitung verwenden, wenn Sie die untergeordnete, automatisch generierte Clientbibliothek für alle unterstützten Sprachen verwenden. Sie können die untergeordnete, automatisch generierte Clientbibliothek und die synchrone Pull-Zustellung verwenden, wenn die Verwendung der Pull API direkt sinnvoll ist. Angenommen, Sie haben eine vorhandene Anwendungslogik, die auf diesem Modell basiert.
Informationen zur direkten Verwendung der automatisch generierten Clientbibliotheken auf niedriger Ebene finden Sie unter Pub/Sub APIs – Übersicht.
Codebeispiele für die Clientbibliothek
Codebeispiele für StreamingPull und allgemeine Clientbibliothek
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Go
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Ruby
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Ruby in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Ruby API.
Benutzerdefinierte Attribute mithilfe der allgemeinen Clientbibliothek abrufen
Die folgenden Beispiele zeigen, wie Nachrichten asynchron abgerufen und die benutzerdefinierten Attribute aus den Metadaten abgerufen werden.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
sC#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Go
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Ruby
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Ruby in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Ruby API.
Fehler mit der allgemeinen Clientbibliothek verarbeiten
Die folgenden Beispiele zeigen, wie Fehler behandelt werden, die beim Abonnieren von Nachrichten auftreten können.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
Go
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Ruby
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
PHP
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für PHP in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Ruby
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Ruby in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Ruby API.
Protokoll
Anfrage:
POST https://pubsub.googleapis.com/v1/projects/myproject/subscriptions/mysubscription:pull
{
"returnImmediately": "false",
"maxMessages": "1"
}
Antwort:
200 OK
{
"receivedMessages": [{
"ackId": "dQNNHlAbEGEIBERNK0EPKVgUWQYyODM2LwgRHFEZDDsLRk1SK...",
"message": {
"data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
"messageId": "19917247034"
}
}]
}
Anfrage:
POST https://pubsub.googleapis.com/v1/projects/myproject/subscriptions/mysubscription:acknowledge
{
"ackIds": [
"dQNNHlAbEGEIBERNK0EPKVgUWQYyODM2LwgRHFEZDDsLRk1SK..."
]
}
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Pub/Sub stellt eine Liste von Nachrichten bereit. Wenn die Liste mehrere Nachrichten enthält, ordnet Pub/Sub die Nachrichten mit demselben Reihenfolgesschlüssel an. Beachten Sie die folgenden wichtigen Hinweise:
Wenn Sie in der Anfrage einen Wert für
max_messages
festlegen, ist nicht garantiert, dassmax_messages
zurückgegeben werden, auch wenn sich so viele Nachrichten im Rückstand befinden. Die Pub/Sub Pull API gibt möglicherweise weniger alsmax_messages
zurück, um die Zustellungslatenz für Nachrichten zu reduzieren, die sofort zugestellt werden können.Eine Pull-Antwort mit 0 Nachrichten darf nicht als Indikator dafür verwendet werden, dass sich keine Nachrichten im Rückstand befinden. Es ist möglich, eine Antwort mit 0 Nachrichten zu erhalten und eine nachfolgende Anfrage zu haben, die Nachrichten zurückgibt.
Wenn Sie mit dem unären Pull-Modus eine niedrige Latenz bei der Nachrichtenzustellung erreichen möchten, ist es wichtig, dass viele gleichzeitig ausstehende Pull-Anfragen vorhanden sind. Wenn der Durchsatz des Themas zunimmt, sind mehr Pull-Anfragen erforderlich. Im Allgemeinen ist der StreamingPull-Modus für latenzempfindliche Anwendungen zu bevorzugen.
Kontingente und Limits
Sowohl Pull- als auch StreamingPull-Verbindungen unterliegen Kontingenten und Limits. Weitere Informationen finden Sie unter Pub/Sub-Kontingente und -Limits.
Nächste Schritte
Erstellen Sie ein Pull-Abo für Ihr Thema.
Abos mit der gcloud CLI erstellen oder ändern
Abos mit REST APIs erstellen oder ändern
Abo mit RPC APIs erstellen oder ändern