Auf dieser Seite wird erläutert, wie Sie Nachrichten mit der Funktion „Genau einmalige Zustellung“ von Pub/Sub empfangen und bestätigen. Mit dieser Funktion können Sie die doppelte Verarbeitung von Nachrichten nachverfolgen und verhindern. Wenn die Funktion aktiviert ist, bietet Pub/Sub die folgenden Semantiken:
Abonnenten können feststellen, ob Nachrichtenbestätigungen erfolgreich waren.
Nachdem die Nachricht erfolgreich bestätigt wurde, erfolgt keine erneute Zustellung.
Solange eine Nachricht aussteht, erfolgt keine erneute Zustellung. Eine Nachricht gilt als ausstehend, bis die Bestätigungsfrist abläuft oder die Nachricht bestätigt wird.
Bei mehreren gültigen Zustellungen aufgrund des Ablaufs der Bestätigungsfrist oder einer vom Client initiierten negativen Bestätigung kann nur die neueste Bestätigungs-ID verwendet werden, um die Nachricht zu bestätigen. Alle Anfragen mit einer vorherigen Bestätigungs-ID schlagen fehl.
Wenn „Genau einmalige Zustellung“ aktiviert ist, können Abonnenten dafür sorgen, dass Nachrichten einmal verarbeitet werden. Dazu müssen sie die folgenden Richtlinien beachten:
Nachrichten innerhalb der Bestätigungsfrist bestätigen.
Informationen zum Fortschritt der Verarbeitung einer Nachricht bis zur erfolgreichen Bestätigung aufbewahren.
Informationen zum Fortschritt der Verarbeitung einer Nachricht verwenden, um doppelte Arbeit zu vermeiden, wenn eine Bestätigung fehlschlägt.
Nur der Pull-Abo-Typ unterstützt die genau einmalige Zustellung, einschließlich Abonnenten, die die StreamingPull APIverwenden. Push- und Export-Abos unterstützen die genau einmalige Zustellung nicht.
Pub/Sub unterstützt die genau einmalige Zustellung innerhalb einer Cloud-Region, basierend auf einer von Pub/Sub definierten eindeutigen Nachrichten-ID.
Empfohlene Clientbibliotheksversionen
- Für eine optimale Leistung verwenden Sie die neueste Version der Clientbibliothek: Python v2.13.6 oder höher, Java v1.139.0 oder höher, PHP v1.39.0 oder höher, C# v3.2.0 oder höher, C++ v2.1.0, Go v1.25.1 oder höher, Node v3.2.0 oder höher und Ruby v2.12.1 oder höher.
Erneute Zustellung im Vergleich zu Duplikat
Es ist wichtig, den Unterschied zwischen erwarteten und unerwarteten erneuten Zustellungen zu verstehen.
Eine erneute Zustellung kann entweder aufgrund einer vom Client initiierten negativen Bestätigung einer Nachricht oder erfolgen, wenn der Client die Bestätigungsfrist der Nachricht nicht verlängert, bevor sie abläuft. Erneute Zustellungen gelten als gültig und das System funktioniert wie vorgesehen.
Informationen zur Fehlerbehebung bei erneuten Zustellungen finden Sie unter Mit Duplikaten umgehen.
Ein Duplikat entsteht, wenn eine Nachricht nach einer erfolgreichen Bestätigung oder vor Ablauf der Bestätigungsfrist noch einmal gesendet wird.
Eine erneut zugestellte Nachricht behält zwischen den Zustellungsversuchen dieselbe Nachrichten-ID bei.
Abos, bei denen die genau einmalige Zustellung aktiviert ist, erhalten keine doppelten Zustellungen.
Unterstützung für die genau einmalige Zustellung in Clientbibliotheken
Unterstützte Clientbibliotheken haben eine Schnittstelle für die Bestätigung mit Antwort (Beispiel: Go). Mit dieser Schnittstelle können Sie prüfen, ob die Bestätigungsanfrage erfolgreich war. Wenn die Bestätigungsanfrage erfolgreich ist, erhalten die Clients garantiert keine erneute Zustellung. Wenn die Bestätigungsanfrage fehlschlägt, können die Clients mit einer erneuten Zustellung rechnen.
Clients können die unterstützten Clientbibliotheken auch ohne die Bestätigungsschnittstelle verwenden. In solchen Fällen können Bestätigungsfehler jedoch zu stillen erneuten Zustellungen von Nachrichten führen.
Unterstützte Clientbibliotheken haben Schnittstellen zum Festlegen der Mindest verlängerungszeit für die Lease (Beispiel: Go). Sie müssen den Wert für die Mindestverlängerung der Lease auf eine hohe Zahl festlegen, um netzwerkbedingte Bestätigungsabläufe zu vermeiden. Der Höchstwert beträgt 600 Sekunden.
Wenn Sie die Java-Clientbibliothek verwenden und Ihren Abonnenten mit einem benutzerdefinierten gRPC-Kanal initialisieren, indem Sie die
setChannelProvider()Methode verwenden, sollten Sie auchmaxInboundMetadataSizeauf mindestens 1 MB festlegen, wenn SieTransportChannelProvidererstellen. Für diese Konfiguration können Sie die MethodeInstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize()oder dieManagedChannelBuilder.maxInboundMetadataSize()verwenden.
Die Standardwerte und der Bereich für die Variablen im Zusammenhang mit der genau einmaligen Zustellung sowie die Namen der Variablen können sich zwischen den Clientbibliotheken unterscheiden. In der Java-Clientbibliothek steuern beispielsweise die folgenden Variablen die genau einmalige Zustellung.
| Variable | Beschreibung | Wert |
|---|---|---|
setEnableExactlyOnceDelivery |
Aktiviert oder deaktiviert die genau einmalige Zustellung. | „true“ oder „false“ Standardwert: „false“ |
minDurationPerAckExtension |
Die Mindestzeit in Sekunden, die für die Verlängerung der Bestätigungsfrist verwendet werden soll. | Bereich: 0 bis 600 Standardwert: „none“ |
maxDurationPerAckExtension |
Die maximale Zeit in Sekunden, die für die Verlängerung der Bestätigungsfrist verwendet werden soll. | Bereich: 0 bis 600 Standardwert: „none“ |
Bei der genau einmaligen Zustellung schlägt die modifyAckDeadline oder acknowledgment
Anfrage an Pub/Sub fehl, wenn die Bestätigungs-ID bereits abgelaufen ist. In solchen Fällen betrachtet der Dienst die abgelaufene Bestätigungs-ID als ungültig, da möglicherweise bereits eine neuere Zustellung unterwegs ist. Das ist so für die genau einmalige Zustellung vorgesehen. Anfragen vom Typ acknowledgment und ModifyAckDeadline geben dann die Antwort INVALID_ARGUMENT zurück. Wenn die genau einmalige Zustellung deaktiviert ist, geben diese Anfragen bei abgelaufenen Bestätigungs-IDs OK zurück.
Damit acknowledgment- und ModifyAckDeadline-Anfragen gültige Bestätigungs-IDs haben, sollten Sie den Wert für minDurationPerAckExtension auf eine hohe Zahl festlegen.
Regionale Einschränkungen
Die Garantie für die genau einmalige Zustellung gilt nur, wenn Abonnenten in derselben Region eine Verbindung zum Dienst herstellen. Wenn Ihre Abonnentenanwendung auf mehrere Regionen verteilt ist, kann dies zu einer doppelten Nachrichtenzustellung führen, auch wenn die genau einmalige Zustellung aktiviert ist. Publisher können Nachrichten an jede Region senden und die Garantie für die genau einmalige Zustellung bleibt bestehen.
Wenn Sie Ihre Anwendung in Google Cloudausführen, wird standardmäßig eine Verbindung zum Pub/Sub-Endpunkt in derselben Region hergestellt. Wenn Sie Ihre Anwendung also in einer einzelnen Region in Google Cloud ausführen, interagieren Sie in der Regel mit einer einzelnen Region.
Wenn Sie Ihre Abonnentenanwendung außerhalb von Google Cloud oder in mehreren Regionen ausführen, können Sie sicherstellen, dass Sie eine Verbindung zu einer einzelnen Region herstellen , indem Sie beim Konfigurieren Ihres Pub/Sub Clients einen standortbezogenen Endpunkt verwenden. Alle Standortendpunkte für Pub/Sub verweisen auf einzelne Regionen. Weitere Informationen zu Standortendpunkten finden Sie unter Pub/Sub-Endpunkte. Eine Liste aller Standortendpunkte für Pub/Sub, finden Sie unter Liste der Standortendpunkte.
Abos mit genau einmaliger Zustellung erstellen
Sie können ein Abo mit genau einmaliger Zustellung über die Google Cloud Console, die Google Cloud CLI, die Clientbibliothek oder die Pub/Sub API erstellen.
Pull-Abo
Console
So erstellen Sie ein Pull-Abo mit genau einmaliger Zustellung:
Rufen Sie in der Google Cloud Console die Abos Seite auf.
Klicken Sie auf Abo erstellen.
Geben Sie die Abo-ID ein.
Wählen Sie im Drop-down-Menü ein Thema aus oder erstellen Sie ein Thema.
Das Abo erhält Nachrichten aus dem Thema.
Wählen Sie im Bereich Genau einmalige Zustellung die Option Genau einmalige Zustellung aktivieren aus.
Klicken Sie auf Erstellen.
gcloud
Verwenden Sie zum Erstellen eines Pull-Abos mit genau einmaliger Zustellung den
gcloud pubsub subscriptions create
Befehl mit dem --enable-exactly-once-delivery Flag:
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --topic=TOPIC_ID \ --enable-exactly-once-delivery
Ersetzen Sie Folgendes:
- SUBSCRIPTION_ID: Die ID des zu erstellenden Abos
- TOPIC_ID: Die ID des Themas, das an das Abo angehängt werden soll
REST
Verwenden Sie zum Erstellen eines Abos mit genau einmaliger Zustellung die
projects.subscriptions.create
Methode.
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth print-access-token)
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID des Projekts, in dem das Abo erstellt werden soll
- SUBSCRIPTION_ID: Die ID des zu erstellenden Abos
Wenn Sie ein Pull-Abo mit genau einmaliger Zustellung erstellen möchten, geben Sie dies im Anfragetext an:
{ "topic": "projects/PROJECT_ID/topics/TOPIC_ID", "enableExactlyOnceDelivery": true, }
Ersetzen Sie Folgendes:
- PROJECT_ID: Die Projekt-ID des Projekts mit dem Thema
- TOPIC_ID: Die ID des Themas, das an das Abo angehängt werden soll
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 zur Pub/Sub C# API.
Go
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (Version 2) verwendet. Wenn Sie noch die Version 1 verwenden, lesen Sie den Migrationsleitfaden zu Version 2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Veraltete Codebeispiele.
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.
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.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Node.js in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Node.js in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Ruby
Im folgenden Beispiel wird die Ruby Pub/Sub-Clientbibliothek Version 3 verwendet. Wenn Sie noch die Version 2 verwenden, lesen Sie den Migrationsleitfaden zu Version 3. Eine Liste der Codebeispiele für Ruby Version 2 finden Sie unter Veraltete Codebeispiele.
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.
PHP
Folgen Sie der Einrichtungsanleitung für PHP unter Schnellstart: Clientbibliotheken verwenden, bevor Sie dieses Beispiel ausprobieren. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub PHP API.
Abos mit genau einmaliger Zustellung überwachen
Der
subscription/exactly_once_warning_count
Messwert erfasst die Anzahl der Ereignisse, die
zu möglichen erneuten Zustellungen führen können (gültig oder Duplikat). Dieser Messwert zählt, wie oft Pub/Sub Anfragen im Zusammenhang mit Bestätigungs-IDs (ModifyAckDeadline- oder acknowledgment-Anfrage) nicht verarbeiten kann. Die Gründe für den Fehler können auf dem Server oder Client beruhen. Wenn beispielsweise die Persistenzebene, die zum Verwalten der Informationen zur genau einmaligen Zustellung verwendet wird, nicht verfügbar ist, handelt es sich um ein serverbasiertes Ereignis. Wenn der Client versucht, eine Nachricht mit einer ungültigen Bestätigungs-ID zu bestätigen, handelt es sich um ein clientbasiertes Ereignis.
Messwert verstehen
subscription/exactly_once_warning_count erfasst Ereignisse, die zu tatsächlichen erneuten Zustellungen führen können oder nicht, und kann je nach Clientverhalten verrauscht sein. Beispiel: Wiederholte acknowledgment- oder ModifyAckDeadline-Anfragen mit ungültigen Bestätigungs-IDs erhöhen den Messwert wiederholt.
Die folgenden Messwerte sind ebenfalls hilfreich, um das Clientverhalten zu verstehen:
subscription/expired_ack_deadlines_countDer Messwert zeigt die Anzahl der abgelaufenen Bestätigungs-IDs. Ablaufende Bestätigungs-IDs können zu Fehlern beiModifyAckDeadline- undacknowledgment-Anfragen führen.service.serviceruntime.googleapis.com/api/request_countMit dem Messwert können Sie Fehler beiModifyAckDeadlineoderacknowledgmentAnfragen erfassen, wenn die Anfragen erreichen Google Cloud aber nicht Pub/Sub. Es gibt Fehler, die mit diesem Messwert nicht erfasst werden, z. B. wenn Clients die Verbindung zu verlieren Google Cloud.
In den meisten Fällen von Fehlerereignissen, die wiederholt werden können, wiederholen unterstützte Clientbibliotheken die Anfrage automatisch.
Kontingente
Für Abos mit genau einmaliger Zustellung gelten zusätzliche Kontingentanforderungen. Diese Kontingente werden für Folgendes erzwungen:
- Anzahl der Nachrichten, die aus Abos mit aktivierter genau einmaliger Zustellung pro Region genutzt werden.
- Anzahl der Nachrichten, die bestätigt werden oder deren Frist verlängert wird, wenn Abos mit aktivierter genau einmaliger Zustellung pro Region verwendet werden.
Weitere Informationen zu diesen Kontingenten finden Sie in der Tabelle im Thema Kontingente.
Genau einmalige Zustellung und Abos mit Reihenfolge
Pub/Sub unterstützt die genau einmalige Zustellung mit geordneter Zustellung.
Wenn Sie die Reihenfolge mit der genau einmaligen Zustellung verwenden, erwartet Pub/Sub, dass die Bestätigungen in der richtigen Reihenfolge erfolgen. Wenn die Bestätigungen nicht in der richtigen Reihenfolge erfolgen, schlagen die Anfragen mit temporären Fehlern fehl. Wenn die Bestätigungsfrist abläuft, bevor eine Bestätigung in der richtigen Reihenfolge für die Zustellung erfolgt, erhält der Client eine erneute Zustellung der Nachricht. Wenn Sie die Reihenfolge mit der genau einmaligen Zustellung verwenden, ist der Clientdurchsatz daher auf einige Tausend Nachrichten pro Sekunde begrenzt.
Genau einmalige Zustellung und Push-Abos
Pub/Sub unterstützt die genau einmalige Zustellung nur bei Pull-Abos.
Clients, die Nachrichten aus den Push-Abos nutzen, bestätigen die Nachrichten, indem sie auf die Push-Anfragen mit einer erfolgreichen Antwort reagieren. Clients wissen jedoch nicht, ob das Pub/Sub-Abo die Antwort erhalten und verarbeitet hat. Das unterscheidet sich von Pull-Abos, bei denen Bestätigungsanfragen von den Clients initiiert werden und das Pub/Sub-Abo antwortet, wenn die Anfrage erfolgreich verarbeitet wurde. Aus diesem Grund passen die Semantiken der genau einmaligen Zustellung nicht gut zu Push-Abos.
Wichtige Punkte
Wenn die Bestätigungsfrist bei der Erstellung des Abos nicht angegeben wird, haben Abos mit aktivierter genau einmaliger Zustellung eine Standardbestätigungsfrist von 60 Sekunden.
Längere Standardbestätigungsfristen sind von Vorteil, um erneute Zustellungen aufgrund von Netzwerkereignissen zu vermeiden. Unterstützte Clientbibliotheken verwenden nicht die Standardbestätigungsfrist für Abos.
Abos mit genau einmaliger Zustellung haben eine deutlich höhere Latenz zwischen Veröffentlichung und Abo als reguläre Abos.
Wenn Sie einen hohen Durchsatz benötigen, müssen Ihre Clients mit genau einmaliger Zustellung auch Streaming-Pull verwenden.
Ein Abo kann aufgrund von Duplikaten auf der Veröffentlichungsseite mehrere Kopien derselben Nachricht erhalten, auch wenn die genau einmalige Zustellung aktiviert ist. Duplikate auf der Veröffentlichungsseite können auf mehrere eindeutige Veröffentlichungsversuche durch den Publisher-Client oder den Pub/Sub-Dienst zurückzuführen sein. Mehrere eindeutige Veröffentlichungen durch den Publisher-Client über mehrere Versuche hinweg führen zu erneuten Zustellungen mit unterschiedlichen Nachrichten-IDs. Mehrere eindeutige Veröffentlichungen durch den Pub/Sub-Dienst als Reaktion auf eine Veröffentlichungsanfrage des Clients führen zu erneuten Zustellungen mit den denselben Nachrichten-IDs.
Sie können Fehler in
subscription/exactly_once_warning_countwiederholen und die unterstützten Clientbibliotheken wiederholen diese automatisch. Fehler im Zusammenhang mit ungültigen Bestätigungs-IDs können jedoch nicht wiederholt werden.