Auf dieser Seite wird beschrieben, wie Sie Nachrichten mit der Pub/Sub-Funktion „Genau einmal“ empfangen und bestätigen. Mit dieser Funktion können Sie die doppelte Verarbeitung von Nachrichten nachverfolgen und verhindern. Wenn das Feature 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 letzte Bestätigungs-ID zum Bestätigen der Nachricht verwendet werden. Alle Anfragen mit einer vorherigen Bestätigungs-ID schlagen fehl.
Wenn die genau einmalige Verarbeitung 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 werden beibehalten, bis sie erfolgreich bestätigt wurde.
Anhand der Informationen zum Fortschritt der Verarbeitung einer Nachricht können Sie doppelte Arbeit vermeiden, wenn eine Bestätigung fehlschlägt.
Nur der Pull-Abo-Typ unterstützt die „Genau einmal“-Übermittlung, einschließlich Abonnenten, die die StreamingPull API verwenden. Push- und Exportabos unterstützen die genau einmalige Zustellung nicht.
Pub/Sub unterstützt die genau einmalige Zustellung innerhalb einer Cloud-Region auf Grundlage einer von Pub/Sub definierten eindeutigen Nachrichten-ID.
Empfohlene Clientbibliotheksversionen
- Für eine optimale Leistung sollten Sie die neueste Version der Clientbibliothek verwenden: 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 Übermittlung 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. Die erneute Zustellung gilt als gültig und das System funktioniert wie vorgesehen.
Informationen zur Fehlerbehebung bei erneuten Zustellungen finden Sie unter Mit Duplikaten umgehen.
Eine Nachricht gilt als Duplikat, wenn sie nach einer erfolgreichen Bestätigung oder vor Ablauf der Bestätigungsfrist noch einmal gesendet wird.
Eine neu zugestellte Nachricht behält zwischen den Zustellversuchen dieselbe Nachrichten-ID.
Bei Abos, für die die genau einmalige Zustellung aktiviert ist, werden keine doppelten Zustellungen empfangen.
Unterstützung der genau einmaligen Zustellung in Clientbibliotheken
Unterstützte Clientbibliotheken haben eine Schnittstelle für die Bestätigung mit Antwort (Beispiel: Go). Über diese Schnittstelle können Sie prüfen, ob die Bestätigungsanfrage erfolgreich war. Wenn die Bestätigungsanfrage erfolgreich ist, erhalten die Kunden garantiert keine erneute Lieferung. Wenn die Bestätigungsanfrage fehlschlägt, können die Kunden mit einer erneuten Lieferung rechnen.
Clients können die unterstützten Clientbibliotheken auch ohne die Bestätigungsoberfläche verwenden. In solchen Fällen können die Bestätigungsfehler jedoch dazu führen, dass Nachrichten still und leise noch einmal zugestellt werden.
Unterstützte Clientbibliotheken haben Schnittstellen zum Festlegen der Mindestfristverlängerungszeit (Beispiel: Go). Sie müssen den Wert für die Mindestverlängerung des Leases auf eine hohe Zahl festlegen, um netzwerkbedingte Ablaufbestätigungen zu vermeiden. Der Höchstwert beträgt 600 Sekunden.
Wenn Sie die Java-Clientbibliothek verwenden und Ihren Subscriber mit einem benutzerdefinierten gRPC-Channel initialisieren, indem Sie die Methode
setChannelProvider()
verwenden, empfehlen wir, dass Sie beim Erstellen IhresTransportChannelProvider
auchmaxInboundMetadataSize
auf mindestens 1 MB festlegen. Für diese Konfiguration können Sie die MethodeInstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize()
oderManagedChannelBuilder.maxInboundMetadataSize()
verwenden.
Die Standardwerte und der Bereich für die Variablen, die sich auf die Exactly-Once-Zustellung beziehen, sowie die Namen der Variablen können sich je nach Clientbibliothek unterscheiden. In der Java-Clientbibliothek steuern beispielsweise die folgenden Variablen die Exactly-Once-Zustellung.
Variable | Beschreibung | Wert |
---|---|---|
setEnableExactlyOnceDelivery |
Aktiviert oder deaktiviert die genau einmalige Zustellung. | „true“ oder „false“ (Standardwert: „false“) |
minDurationPerAckExtension |
Die Mindestzeit in Sekunden, die zum Verlängern der Bestätigungsfrist für die Änderung verwendet werden soll. | Bereich: 0 bis 600, Standard: keine |
maxDurationPerAckExtension |
Die maximale Zeit in Sekunden, die zum Verlängern der Frist für die Bestätigung der Änderung verwendet werden soll. | Bereich: 0 bis 600, Standard: keine |
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 wird die abgelaufene Bestätigungs-ID vom Dienst als ungültig betrachtet, da möglicherweise bereits eine neuere Lieferung unterwegs ist. Dies ist für die „Genau einmal“-Übermittlung so vorgesehen. Anschließend wird für acknowledgment
- und ModifyAckDeadline
-Anfragen eine INVALID_ARGUMENT
-Antwort zurückgegeben. 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 es zu einer doppelten Nachrichtenzustellung kommen, auch wenn die genau einmalige Zustellung aktiviert ist. Publisher können Nachrichten an eine beliebige Region senden und die Garantie für die genaue einmalige Zustellung wird weiterhin eingehalten.
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 in einer einzelnen Region innerhalb von Google Cloudausführen, interagieren Sie in der Regel mit einer einzelnen Region.
Wenn Sie Ihre Abonnentenanwendung außerhalb von Google Cloudoder 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 Standortendpunkt verwenden. Alle Standortendpunkte für Pub/Sub verweisen auf einzelne Regionen. Weitere Informationen zu standortbezogenen Endpunkten finden Sie unter Pub/Sub-Endpunkte. Eine Liste aller standortbezogenen Endpunkte für Pub/Sub finden Sie unter Liste der standortbezogenen Endpunkte.
Abos mit genau einmaliger Zustellung erstellen
Sie können ein Abo mit Exactly-Once-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 Exactly-Once-Zustellung:
Rufen Sie in der Google Cloud Console die Seite Abos 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 Abschnitt Genau einmal zugestellt die Option Genau einmal zugestellt aktivieren aus.
Klicken Sie auf Erstellen.
gcloud
Verwenden Sie zum Erstellen eines Pull-Abos mit Exactly-Once-Zustellung den Befehl gcloud pubsub subscriptions create
mit dem Flag --enable-exactly-once-delivery
:
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
Wenn Sie ein Abo mit Exactly-Once-Zustellung erstellen möchten, verwenden Sie die Methode projects.subscriptions.create
.
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 Exactly-Once-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 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 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 Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zu 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 zu Pub/Sub Python 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.
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.
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.
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 PHP-API von Pub/Sub.
Abonnieren mit genau einmaliger Nachrichtenzustellung
Im Folgenden finden Sie einige Codebeispiele für das Abonnieren mit Exactly-Once-Zustellung mithilfe der Clientbibliothek.
Pull-Abo
Go
Folgen Sie der Einrichtungsanleitung für Go in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Java
Folgen Sie der Einrichtungsanleitung für Java in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Java API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js
Folgen Sie der Einrichtungsanleitung für Node.js in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
PHP
Folgen Sie der Einrichtungsanleitung für PHP in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub PHP API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Python
Folgen Sie der Einrichtungsanleitung für Python in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Ruby
Folgen Sie der Einrichtungsanleitung für Ruby in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Ruby API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
C++
Folgen Sie der Einrichtungsanleitung für C++ in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C++ API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
C#
Folgen Sie der Einrichtungsanleitung für C# in der Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden, bevor Sie dieses Beispiel anwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js (TypeScript)
Lesen Sie unter Pub/Sub-Kurzanleitung: Clientbibliotheken verwenden die Anleitung für die Einrichtung von Node.js, bevor Sie dieses Beispiel ausprobieren. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Richten Sie zur Authentifizierung bei Pub/Sub Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Abos für genau einmalige Zustellung im Blick behalten
Mit dem Messwert subscription/exactly_once_warning_count
wird die Anzahl der Ereignisse erfasst, die zu möglichen erneuten Zustellungen führen können (gültig oder doppelt). Dieser Messwert zählt, wie oft Pub/Sub Anfragen mit Bestätigungs-IDs (ModifyAckDeadline
- oder acknowledgment
-Anfrage) nicht verarbeiten kann. Die Gründe für den Fehler können server- oder clientseitig sein. Wenn beispielsweise die Persistenzebene, die zum Verwalten der Informationen zur „Exactly-Once“-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 möglicherweise zu tatsächlichen Neuzustellungen führen, und kann je nach Clientverhalten viele irrelevante Daten enthalten. Beispiel: Wiederholte acknowledgment
- oder ModifyAckDeadline
-Anfragen mit ungültigen Bestätigungs-IDs erhöhen den Messwert wiederholt.
Die folgenden Messwerte sind ebenfalls nützlich, um das Clientverhalten zu verstehen:
Der Messwert
subscription/expired_ack_deadlines_count
gibt die Anzahl der abgelaufenen Bestätigungs-IDs an. Das Ablaufen von Bestätigungs-IDs kann zu Fehlern beiModifyAckDeadline
- undacknowledgment
-Anfragen führen.Mit dem Messwert
service.serviceruntime.googleapis.com/api/request_count
lassen sich Fehler beiModifyAckDeadline
- oderacknowledgment
-Anfragen erfassen, wenn die Anfragen Google Cloud erreichen, aber nicht Pub/Sub. Es gibt Fehler, die von diesem Messwert nicht erfasst werden, z. B. wenn Clients von Google Cloudgetrennt werden.
In den meisten Fällen von Fehlerereignissen, bei denen ein Wiederholungsversuch möglich ist, wird die Anfrage von unterstützten Clientbibliotheken automatisch wiederholt.
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 Exactly-Once-Zustellung pro Region abgerufen wurden.
- Anzahl der Nachrichten, die bestätigt wurden oder deren Frist verlängert wurde, wenn Abos mit aktivierter einmaliger Zustellung pro Region verwendet werden.
Weitere Informationen zu diesen Kontingenten finden Sie in der Tabelle im Thema Kontingente.
Genau einmalige Zustellung und geordnete Abos
Pub/Sub unterstützt die genau einmalige Zustellung mit geordneter Zustellung.
Wenn Sie die Reihenfolge mit genau einmaliger Zustellung verwenden, erwartet Pub/Sub, dass die Bestätigungen in der richtigen Reihenfolge erfolgen. Wenn die Bestätigungen nicht in der richtigen Reihenfolge eingehen, schlägt der Dienst die Anfragen mit temporären Fehlern fehl. Wenn die Bestätigungsfrist vor einer In-Order-Bestätigung für die Zustellung abläuft, erhält der Client eine erneute Zustellung der Nachricht. Wenn Sie die Bestellung mit der Exactly-Once-Zustellung verwenden, ist der Clientdurchsatz daher auf etwa 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 empfangen, bestätigen die Nachrichten, indem sie auf die Push-Anfragen mit einer Erfolgsantwort antworten. Clients wissen jedoch nicht, ob das Pub/Sub-Abo die Antwort empfangen 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 passt die genau einmalige Zustellung nicht gut zu Push-Abos.
Wichtige Informationen
Wenn beim Erstellen des Abos keine Bestätigungsfrist angegeben wird, gilt für Abos mit aktivierter genau einmaliger Zustellung eine Standardbestätigungsfrist von 60 Sekunden.
Längere Standardfristen für die Bestätigung sind von Vorteil, um eine erneute Zustellung aufgrund von Netzwerkereignissen zu vermeiden. Unterstützte Clientbibliotheken verwenden nicht die standardmäßige Bestä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 „Genau einmal“-Zustellungsclients auch Streaming-Pull verwenden.
Ein Abo kann aufgrund von Duplikaten auf der Publisher-Seite mehrere Kopien derselben Nachricht erhalten, auch wenn die genau einmalige Zustellung aktiviert ist. Duplikate auf Publisher-Seite können durch mehrere eindeutige Wiederholungsversuche des Publishing-Clients oder des Pub/Sub-Dienstes verursacht werden. Mehrere eindeutige Veröffentlichungen durch den Publishing-Client führen bei Wiederholungsversuchen 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 gleichen Nachrichten-IDs.
Sie können Fehler in
subscription/exactly_once_warning_count
wiederholen. Die unterstützten Clientbibliotheken wiederholen diese automatisch. Fehler im Zusammenhang mit ungültigen Bestätigungs-IDs können jedoch nicht wiederholt werden.