Pub/Sub unterstützt die Push- und Pull-Nachrichtenzustellung. Einen Überblick und Vergleich von Pull- und Push-Abos finden Sie in Abonnentenübersicht. In diesem Dokument wird die Pull-Zustellung beschrieben. Der Push-Aboleitfaden enthält eine Beschreibung der Push-Zustellung.
Asynchrone Pull-Zustellung
Mit der asynchronen Pull-Zustellung können Sie den Durchsatz Ihrer Anwendung erhöhen, da sie nicht für neue Nachrichten blockiert werden muss. Sie haben die Möglichkeit, Nachrichten in der Anwendung mit einem lange laufenden Nachrichten-Listener zu empfangen und wie im Beispiel unten nacheinander zu bestätigen. Java-, Python-, .NET-, Go- und Ruby-Clients verwenden die StreamingPull Service API, um die asynchrone Client API effizient zu implementieren.
Die asynchrone Pull-Zustellung von Nachrichten wird nicht von allen Clientbibliotheken unterstützt. Weitere Informationen zur synchronen Pull-Zustellung von Nachrichten finden Sie im Abschnitt Synchrone Pull-Zustellung.
Weitere Informationen finden Sie in der API-Referenzdokumentation zu Ihrer Programmiersprache.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Pub/Sub C++ API-Referenzdokumentation.
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 zu 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 zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu 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 zu 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 zu Pub/Sub Ruby API.
Benutzerdefinierte Attribute verarbeiten
In diesem Beispiel wird gezeigt, wie Nachrichten asynchron abgerufen und die benutzerdefinierten Attribute aus Metadaten aufgerufen 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 Pub/Sub C++ API-Referenzdokumentation.
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 zu 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 zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu 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 zu 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 zu Pub/Sub Ruby API.
Prüfen, ob Fehler aufgetreten sind
In diesem Beispiel wird dargestellt, 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 Pub/Sub C++ API-Referenzdokumentation.
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 zu 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 zu 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 zu 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 zu 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 zu Pub/Sub Go API.
Steuerung des Nachrichtenflusses
Ihr Abonnentenclient verarbeitet und bestätigt Nachrichten möglicherweise langsamer, als Pub/Sub diese an den Client sendet. In diesem Fall:
Es ist möglich, dass an einem Client ein Nachrichtenrückstand auftritt, weil er nicht die Kapazität hat, das Volumen der eingehenden Nachrichten zu verarbeiten. Ein anderer Client im Netzwerk hat aber diese Kapazität. Der zweite Client könnte den Rückstand reduzieren, hat aber keine Möglichkeit dazu, da der erste Client ein Vorrecht auf die Verarbeitung der empfangenen Nachrichten hat. Dies reduziert die Verarbeitungsgeschwindigkeit insgesamt, weil die Nachrichten auf dem ersten Client hängen bleiben.
Da die Clientbibliothek die Bestätigungsfrist für zurückgestellte Nachrichten wiederholt verlängert, verbrauchen diese Nachrichten weiterhin Speicher-, CPU- und Bandbreitenressourcen. Dadurch können dem Abonnentenclient die Ressourcen (z. B. Speicher) ausgehen, was den Durchsatz und die Latenz der Nachrichtenverarbeitung beeinträchtigen kann.
Wenn Sie diese Probleme minimieren möchten, verwenden Sie die Ablaufsteuerungsfunktionen des Abonnenten. Damit können Sie die Geschwindigkeit steuern, mit der der Abonnent Nachrichten empfängt. Diese Ablaufsteuerungsfunktionen werden in den folgenden Beispielen veranschaulicht:
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Pub/Sub C++ API-Referenzdokumentation.
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 zu 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 zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu 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 zu 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 zu Pub/Sub Ruby API.
Generell zeigt die Notwendigkeit der Ablaufsteuerung, dass Nachrichten mit einer höheren Geschwindigkeit veröffentlicht werden, als sie verarbeitet werden können. Wenn dies ein Dauerzustand ist und kein vorübergehender Anstieg des Nachrichtenvolumens, sollten Sie die Anzahl der Abonnentenclient-Instanzen erhöhen.
Gleichzeitigkeitserkennung
Die Unterstützung für Gleichzeitigkeit ist programmiersprachenabhängig. Bei Sprachimplementierungen, die parallele Threads wie Java und Go unterstützen, legen die Clientbibliotheken die Anzahl der Threads jeweils anhand ihrer Standardeinstellung fest. Diese Einstellung ist für Ihre Anwendung möglicherweise nicht optimal. Wenn Sie beispielsweise feststellen, dass Ihre Abonnentenanwendung mit dem eingehenden Nachrichtenvolumen nicht Schritt hält, aber nicht CPU-gebunden ist, sollten Sie die Anzahl der Threads erhöhen. Bei CPU-intensiver Nachrichtenverarbeitung kann es sinnvoll sein, die Anzahl der Threads zu verringern.
Das folgende Beispiel zeigt, wie die Gleichzeitigkeit in einem Abo gesteuert wird.
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Pub/Sub C++ API-Referenzdokumentation.
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 zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu Pub/Sub Java 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 zu Pub/Sub Ruby API.
Die Unterstützung für Gleichzeitigkeit ist programmiersprachenabhängig. Weitere Informationen finden Sie in der API-Referenzdokumentation.
StreamingPull
Der Pub/Sub-Dienst hat zwei APIs zum Abrufen von Nachrichten:
Wo möglich, verwenden die Cloud-Client-Bibliotheken StreamingPull für maximalen Durchsatz und niedrigste Latenz. Auch wenn Sie die StreamingPull API vielleicht niemals direkt verwenden, ist es dennoch hilfreich, wenn Sie einige wesentliche Attribute von StreamingPull und den Unterschied zur herkömmlichen Pull-Methode kennen.
Die Pull-Methode basiert auf einem Anfrage-/Antwort-Modell:
- Der Client sendet eine Anfrage an den Server.
- Der Server antwortet mit null oder mehr Nachrichten und trennt die Verbindung.
Die API des StreamingPull-Dienstes benötigt eine bidirektionale Verbindung, um mehrere Nachrichten zu empfangen, sobald diese verfügbar werden.
- Der Client sendet eine Anfrage an den Server, um eine Verbindung herzustellen.
- Der Server sendet kontinuierlich Nachrichten an den verbundenen Client.
- Die Verbindung wird schließlich entweder vom Client oder vom Server beendet.
Sie stellen dem Abonnenten einen Callback bereit und der Abonnent führt den Callback für jede Nachricht asynchron aus. Wenn ein Abonnent Nachrichten mit demselben Reihenfolgenschlüssel empfängt, führen die Clientbibliotheken den Callback nacheinander aus. Der Pub/Sub-Dienst sendet diese Nachrichten an den gleichen Abonnenten auf Best-Effort-Basis.
StreamingPull hat eine (erwartete) Fehlerrate von 100 %
StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Beachten Sie, dass der Fehler hier anders als bei regulären RPCs lediglich ein Hinweis darauf ist, dass ein Stream unterbrochen wurde – nicht jedoch, dass eine Anfrage fehlgeschlagen ist. Aus diesem Grund ist es möglich, dass die StreamingPull API eine anscheinend überraschende Fehlerrate von 100 % hat. Dies ist designbedingt.
Diagnose von StreamingPull-Fehlern
Da StreamingPull-Streams immer mit einem Fehler enden, ist es nicht hilfreich, die Stream-Beendigungskennzahlen während der Fehlerdiagnose zu untersuchen. Konzentrieren Sie sich stattdessen auf den StreamPull-Messwert für die Nachrichtenoperation subscription/streaming_pull_message_operation_count
. Suchen Sie nach folgenden Fehlern:
FAILED_PRECONDITION
-Fehler können in folgenden Fällen auftreten:- Pub/Sub versucht, eine Nachricht mit einem deaktivierten Cloud KMS-Schlüssel zu entschlüsseln.
- Abos können vorübergehend gesperrt werden, wenn noch nicht versendete Nachrichten mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind.
UNAVAILABLE
Fehler
StreamingPull: Große Rückstände kleiner Nachrichten verwalten
Das gRPC-StreamingPull-Paket ist für einen hohen Durchsatz optimiert, sodass Nachrichten zwischengespeichert werden. Dies kann Auswirkungen haben, wenn Sie versuchen, statt eines kontinuierlichen Streams neuer Nachrichten große Rückstände von kleinen Nachrichten zu verarbeiten. Unter diesen Bedingungen werden Nachrichten möglicherweise mehrfach zugestellt und nicht per Lastenausgleich auf Clients verteilt und so effektiver verarbeitet.
Der Zwischenspeicher für den Pub/Sub-Dienst und den Speicherplatz des Clientbibliothek-Nutzers beträgt ca. 10 MB. Die Auswirkungen dieses Zwischenspeichers auf das Verhalten der Clientbibliothek werden am folgenden Beispiel deutlich:
- Es gibt einen Verarbeitungsrückstand von 10.000 1-KB-Nachrichten in einem Abo.
- Jede Nachricht benötigt 1 Sekunde für die sequenzielle Verarbeitung durch eine Clientinstanz mit einem einzigen Thread.
- Die erste Clientinstanz, die eine StreamingPull-Verbindung zu dem Dienst für dieses Abo herstellt, füllt den Puffer mit allen 10.000 Nachrichten.
- Es dauert 10.000 Sekunden (fast drei Stunden), bis der Zwischenspeicher verarbeitet wurde.
- In dieser Zeit überschreiten einige der gepufferten Nachrichten ihre Bestätigungsfrist und werden noch einmal an denselben Client gesendet, was zu Duplikaten führt.
- Wenn mehrere Clientinstanzen ausgeführt werden, sind die Nachrichten, die sich im Puffer des einen Clients befinden, für keine Clientinstanzen verfügbar.
Diese Situation tritt nicht ein, wenn die Nachrichten mit einer konstanten Rate (und nicht als einzelner, großer Batch) ankommen: Der Dienst verfügt nie über die gesamten 10 MB an Nachrichten gleichzeitig und kann daher ein effektives Load-Balancing für mehrere Abonnenten durchführen.
Verwenden Sie zur Behebung dieses Problems entweder ein Push-Abo oder die Pull-API, die derzeit in einigen der Cloud-Clientbibliotheken (siehe Abschnitt "Synchroner Pull") und in allen API-Clientbibliotheken verfügbar ist. Weitere Informationen finden Sie in der Dokumentation zu Clientbibliotheken.
Synchrone Pull-Zustellung
In bestimmten Fällen ist die asynchrone Pull-Zustellung für Ihre Anwendung eher ungeeignet. Zum Beispiel dann, wenn die Anwendungslogik Nachrichten mithilfe eines Abfragemusters abruft oder wenn sie die Anzahl der zu einem bestimmten Zeitpunkt vom Client abgerufenen Nachrichten präzise begrenzen muss. Zur Unterstützung solcher Anwendungen unterstützt der Dienst eine synchrone Pull-Methode.
Hier sehen Sie Beispielcode für die Pull-Zustellung und die Bestätigung einer festen Anzahl von Nachrichten:
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 zu 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 zu Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu 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 zu Pub/Sub Node.js 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 zu 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 zu Pub/Sub Ruby API.
Pub/Sub stellt eine Liste von Nachrichten bereit. Wenn die Liste mehrere Nachrichten enthält, sortiert Pub/Sub die Nachrichten mit demselben Reihenfolgenschlüssel.
Voraussetzung für die Effektivität der synchronen Pull-Zustellung ist, dass eine hohe Zahl gleichzeitig ausstehender Pull-Anfragen vorliegt. Je höher der Durchsatz des Themas wird, desto mehr Pull-Anfragen werden benötigt. Im Allgemeinen sind für latenzempfindliche Anwendungen asynchrone Pull-Zustellungen zu bevorzugen.
Synchroner Pull mit Lease-Management
Die Verarbeitung einer einzelnen Nachricht kann die vorkonfigurierte Bestätigungsfrist überschreiten, die auch als Lease bezeichnet wird. Um eine erneute Zustellung dieser Nachrichten zu vermeiden, bieten die Clientbibliotheken die Möglichkeit, ihre Bestätigungsfristen zurückzusetzen (mit Ausnahme der Go-Clientbibliothek, die die Bestätigungsfristen für abgefragte Nachrichten automatisch ändert), wie in den folgenden Beispielen gezeigt:
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 zu Pub/Sub C# API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu 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 zu 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 zu Pub/Sub Ruby API.
Skalieren
Möglicherweise müssen Sie einen Skalierungsmechanismus für Ihre Abonnentenanwendung implementieren, um das Nachrichtenaufkommen zu bewältigen. Die Vorgehensweise hängt von Ihrer Umgebung ab. Sie basiert jedoch im Allgemeinen auf Rückstandmesswerten, die über den Monitoring-Dienst der Google Cloud Operations Suite bereitgestellt werden. Informationen zur Vorgehensweise mit Compute Engine finden Sie unter Anhand von Cloud Monitoring-Messwerten skalieren.
Wechseln Sie zum Abschnitt Publish/Sub der GCP-Messwertliste, um zu erfahren, welche Messwerte programmatisch überwacht werden können.
Wie bei allen dezentralen Diensten müssen Anfragen möglicherweise wiederholt werden.
Duplikate verwalten und Wiederholungsversuche erzwingen
Wenn Sie eine Nachricht nicht vor Ablauf der Bestätigungsfrist bestätigen, sendet Pub/Sub die Nachricht noch einmal. Infolgedessen kann Pub/Sub Nachrichten doppelt senden. Verwenden Sie die Operations Suite von Google Cloud, um Vorgänge mit dem Antwortcode expired
zu beobachten, um dieses Problem zu erkennen. Wählen Sie zum Abrufen dieser Daten den Messwert Nachrichtenvorgänge bestätigen aus und gruppieren oder filtern Sie ihn nach dem Label response_code
. Beachten Sie, dass response_code
ein Systemlabel für einen Messwert ist und kein Messwert an sich.

Verlängern Sie die Nachrichtenfrist, um die Duplizierungsrate zu senken.
- Clientbibliotheken erledigen die Fristverlängerung automatisch, es gibt jedoch standardmäßig Beschränkungen für die maximal konfigurierbare Fristverlängerung.
- Wenn Sie eine eigene Clientbibliothek erstellen, können Sie die Bestätigungsfrist mit der Methode
modifyAckDeadline
verlängern.
Alternativ können Sie festlegen, dass Pub/Sub eine Nachricht noch einmal sendet, indem Sie modifyAckDeadline
auf 0 setzen.