Eventarc Standard unterstützt die mindestens einmalige Ereignisübermittlung. Wenn ein Ziel ein Ereignis nicht bestätigt, versucht Eventarc automatisch, es noch einmal zu senden.
Die Wiederholungsmerkmale von Eventarc Standard entsprechen denen der Transportebene, Cloud Pub/Sub, die Verarbeitungsfehler mithilfe einer Wiederholungsrichtlinie für Abos behandelt.
Funktionsweise von Wiederholungsversuchen
Wenn Sie einen Eventarc-Trigger erstellen, werden das Pub/Sub-Transportthema und das Abo automatisch für Sie erstellt. (Ereignisse aus Pub/Sub-Quellen können ein vorhandenes Pub/Sub-Thema verwenden.)
Alle von Eventarc automatisch erstellten Abo-IDs haben ein
Format, das mit eventarc-REGION- beginnt.
Wenn ein Ziel eine Nachricht nicht bestätigen kann, sendet Pub/Sub die Nachricht standardmäßig mit einer exponentiellen Backoff-Verzögerung noch einmal. Mit einem exponentiellen Backoff können Sie zwischen Wiederholungsversuchen schrittweise längere Verzögerungen hinzufügen. Die Standardverzögerung beginnt bei mindestens 10 Sekunden und erhöht sich mit jedem nachfolgenden Fehler auf maximal 600 Sekunden. Eventarc legt die Standardaufbewahrungsdauer für Nachrichten auf 24 Stunden fest.
Weitere Informationen dazu, wie Pub/Sub Wiederholungsversuche handhabt, finden Sie unter Nachrichtenfehler behandeln und Anfragen wiederholen.
Best Practices für die Behandlung von Wiederholungsversuchen
Wenn eine Ereignisnachricht nicht innerhalb des Aufbewahrungszeitraums für Nachrichten zugestellt werden kann, wird sie verworfen, es sei denn, ein Thema für unzustellbare Nachrichten ist konfiguriert. Mit einem Thema für unzustellbare Nachrichten können Sie persistente Fehler speichern und analysieren. Weitere Informationen finden Sie in diesem Dokument unter Themen für unzustellbare Nachrichten.
Aufgrund der mindestens einmaligen Zustellung kann Ihr Event-Handler doppelte Ereignisse empfangen. Es empfiehlt sich, Ihre Handler so zu gestalten, dass sie idempotent sind. Weitere Informationen finden Sie in diesem Dokument unter Idempotente Event-Handler.
Wiederholungsversuche konfigurieren
Möglicherweise möchten Sie das Standardverhalten für Wiederholungsversuche anpassen. Alle Einstellungen für Wiederholungsversuche und Aufbewahrung werden über die Wiederholungsrichtlinie für Pub/Sub-Abos konfiguriert, die mit Ihrem Eventarc-Trigger verknüpft ist.
Wenn Sie die Wiederholungsrichtlinie für Abos ändern möchten, müssen Sie zuerst das Pub/Sub-Abo ermitteln, das mit Ihrem Eventarc-Trigger verknüpft ist. Aktualisieren Sie dann das Abo selbst.
Weitere Informationen zu Abo-Attributen finden Sie unter Abo-Attribute. Informationen zu Abolimits finden Sie unter Pub/Sub-Ressourcenlimits.
Abo ermitteln
So ermitteln Sie das Pub/Sub-Abo, das mit Ihrem Eventarc-Trigger verknüpft ist:
Console
Rufen Sie in der Google Cloud -Console die Seite Eventarc Trigger auf.
Klicken Sie in der Liste der Trigger auf den Trigger, dessen Details Sie sehen möchten.
Klicken Sie auf den Namen des Themas.
Klicken Sie auf den Tab Abos, um die Abo-ID anzuzeigen.
gcloud
Mit dem
gcloud eventarc triggers describe
Befehl können Sie die Abo-ID abrufen.
gcloud eventarc triggers describe TRIGGER_NAME \ --location=LOCATION
Ersetzen Sie Folgendes:
TRIGGER_NAME: der Name des Triggers oder eine voll qualifizierte Kennzeichnung.LOCATION: der Standort des Eventarc-Triggers.
Dieser Befehl gibt Informationen über den Trigger zurück, die in etwa so aussehen und die Abo-ID enthalten:
createTime: '2023-03-16T13:40:44.889670204Z'
destination:
cloudRun:
path: /
region: us-central1
service: hello
eventDataContentType: application/protobuf
eventFilters:
...
transport:
pubsub:
subscription: projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID
topic: projects/PROJECT_ID/topics/TOPIC_ID
Terraform
Verwenden Sie den state show-Befehl, um eine
google_eventarc_trigger
-Terraform-Ressource zu beschreiben.
terraform state show google_eventarc_trigger.default
Der Befehl state show gibt Informationen über den Trigger zurück, einschließlich der Abo-ID. Beispiel:
# google_eventarc_trigger.default:
resource "google_eventarc_trigger" "default" {
conditions = {}
create_time = "2025-07-14T17:29:22.575033822Z"
effective_labels = {
"goog-terraform-provisioned" = "true"
}
...
transport {
pubsub {
subscription = "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
topic = "projects/PROJECT_ID/topics/TOPIC_ID"
}
}
}
Weitere Informationen zur Verwendung von Terraform finden Sie in der Terraform-Dokumentation. Google Cloud
REST
Verwenden Sie die Methode projects.locations.triggers.get, um einen Trigger für ein bestimmtes Projekt und einen bestimmten Standort zu beschreiben.
Ersetzen Sie diese Werte in den folgenden Anfragedaten:
TRIGGER_NAME: der Name des Triggers, den Sie beschreiben möchten.PROJECT_ID: Ihre Google Cloud Projekt-ID.LOCATION: die Region, in der der Trigger erstellt wird – zum Beispiel:us-central1.
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
Wenn der Vorgang erfolgreich ist, enthält der Antworttext eine Instanz von
Trigger
die etwa so aussieht:
{
"name": "projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME",
"uid": "d700773a-698b-47b2-a712-2ee10b690062",
"createTime": "2022-12-06T22:44:04.744001514Z",
"updateTime": "2022-12-06T22:44:09.116459550Z",
"eventFilters": [
{
"attribute": "type",
"value": "google.cloud.pubsub.topic.v1.messagePublished"
}
],
"serviceAccount": "SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com",
"destination": {
"workflow": "projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_NAME"
},
"transport": {
"pubsub": {
"topic": "projects/PROJECT_ID/topics/TOPIC_ID",
"subscription": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
}
}
}
Abo aktualisieren
So aktualisieren Sie die Wiederholungsrichtlinie für Pub/Sub-Abos, die mit Ihrem Eventarc-Trigger verknüpft ist:
Console
Rufen Sie in der Google Cloud -Console die Seite Eventarc Trigger auf.
Klicken Sie in der Liste der Trigger auf den Trigger, dessen Details Sie sehen möchten.
Klicken Sie auf den Namen des Themas.
Klicken Sie auf den Tab Abos, um die Abo-ID anzuzeigen.
Klicken Sie auf die Abo-ID und dann auf Bearbeiten.
Wählen Sie im Abschnitt Wiederholungsrichtlinie die Option Sofort wiederholen aus.
Wenn Sie nach einer exponentiellen Backoff-Verzögerung wiederholen möchten, geben Sie die folgenden Werte in Sekunden ein:
Minimaler Backoff: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und sollte zwischen 0 und 600 liegen.
Maximaler Backoff: die maximale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 600 Sekunden und sollte zwischen 0 und 600 liegen.
Weitere Informationen finden Sie unter Wiederholungsrichtlinie.
Klicken Sie auf Aktualisieren.
gcloud
Mit dem
gcloud pubsub subscriptions update
Befehl können Sie die Wiederholungsrichtlinie für Abos aktualisieren.
gcloud pubsub subscriptions update SUBSCRIPTION_ID \ --min-retry-delay=MIN_RETRY_DELAY \ --max-retry-delay=MAX_RETRY_DELAY
Ersetzen Sie Folgendes:
SUBSCRIPTION_ID: die ID des Abos oder eine voll qualifizierte Kennzeichnung.Beide folgenden Flags müssen angegeben werden, um nach einer exponentiellen Backoff-Verzögerung wiederholen zu können. Andernfalls wird für alle ausgelassenen Flags der Standardwert verwendet:
MIN_RETRY_DELAY: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und sollte zwischen 0 und 600 liegen.MAX_RETRY_DELAY: die maximale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 600 Sekunden und sollte zwischen 0 und 600 liegen.
Optional können Sie mit dem Flag --clear-retry-policy die Wiederholungsrichtlinie löschen und das Abo so einstellen, dass Wiederholungsversuche sofort ausgeführt werden.
Terraform
Sie können eine Wiederholungsrichtlinie für Pub/Sub-Abos aktualisieren, indem Sie
die
google_pubsub_subscription
Terraform-Ressource konfigurieren. Verwenden Sie den
import Block
um das vorhandene Abo zu importieren, damit Terraform die Ressource
in Ihrer Zustandsdatei verfolgen kann. Sie können die importierte Ressource dann wie jede andere verwalten,
mit
ignore_changes
Attribute angeben, die Terraform beim Aktualisieren der
Ressource ignorieren soll.
Beispiel:
import { to = google_pubsub_subscription.default id = "SUBSCRIPTION_ID" } resource "google_pubsub_subscription" "default" { name = "SUBSCRIPTION_ID" topic = "TOPIC_ID" retry_policy { minimum_backoff = "MIN_RETRY_DELAYs" maximum_backoff = "MAX_RETRY_DELAYs" } lifecycle { # Ignore push delivery configuration which is managed by Eventarc ignore_changes = [push_config] } }
Ersetzen Sie Folgendes:
SUBSCRIPTION_ID: die ID des Abos.TOPIC_ID: die ID des Themas.MIN_RETRY_DELAY: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und sollte zwischen 0 und 600 liegen.MAX_RETRY_DELAY: die maximale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 600 Sekunden und sollte zwischen 0 und 600 liegen.
REST
Verwenden Sie die
projects.subscriptions.patch
Methode, um die Wiederholungsrichtlinie für ein Abo in einem bestimmten Projekt zu aktualisieren.
Ersetzen Sie diese Werte in den folgenden Anfragedaten:
MIN_RETRY_DELAY: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und sollte zwischen 0 und 600 liegen.MAX_RETRY_DELAY: die maximale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 600 Sekunden und sollte zwischen 0 und 600 liegen.PROJECT_ID: Ihre Google Cloud Projekt-ID.SUBSCRIPTION_ID: die ID des Pub/Sub-Abos, das Sie aktualisieren.
JSON-Text der Anfrage:
{
"subscription": {
"retryPolicy": {
"minimumBackoff": "MIN_RETRY_DELAYs",
"maximumBackoff": "MAX_RETRY_DELAYs"
}
},
"updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
Wenn der Vorgang erfolgreich ist, enthält der Antworttext eine Instanz von
Subscription
die etwa so aussieht:
{
"name": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID",
"topic": "projects/PROJECT_ID/topics/TOPIC_ID",
...
"retryPolicy": {
"minimumBackoff": "MIN_RETRY_DELAYs",
"maximumBackoff": "MAX_RETRY_DELAYs"
},
"state": "ACTIVE"
}
Weitere Überlegungen zu Wiederholungsversuchen
Bei der Behandlung von Verarbeitungsfehlern oder der Weiterleitung nicht zugestellter Nachrichten sollten Sie die folgenden Aspekte beachten.
Push-Backoffs
Wenn ein Push-Abonnent zu viele negative Bestätigungen sendet, stellt Pub/Sub Nachrichten möglicherweise mit einem Push-Backoff zu. Wenn Pub/Sub einen Push-Backoff verwendet, werden keine Nachrichten mehr für eine bestimmte Zeit zugestellt. Dieser Zeitraum kann zwischen 100 Millisekunden und 60 Sekunden liegen. Nach Ablauf der Zeit beginnt Pub/Sub wieder mit der Zustellung von Nachrichten. Weitere Informationen finden Sie unter Push-Backoff.
Themen für unzustellbare Nachrichten
Wenn das Ziel die Nachricht nicht empfängt, können Sie nicht zugestellte Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten (auch als Dead-Letter-Warteschlange bezeichnet). In einem Thema für unzustellbare Nachrichten können Nachrichten gespeichert werden, die vom Ziel nicht bestätigt werden können. Sie müssen ein Thema für unzustellbare Nachrichten festlegen, wenn Sie ein Pub/Sub-Abo erstellen oder aktualisieren, und nicht, wenn Sie ein Pub/Sub-Thema erstellen oder wenn Eventarc ein Pub/Sub-Thema erstellt. Weitere Informationen finden Sie unter Thema für unzustellbare Nachrichten konfigurieren.
Fehler, die keine Wiederholungen rechtfertigen
Wenn Anwendungen Pub/Sub als Ereignisquelle verwenden und das Ereignis nicht zugestellt wird, wird das Ereignis automatisch wiederholt, außer bei Fehlern, die keine Wiederholungen rechtfertigen. Ereignisse für ein Workflows-Ziel von einer beliebigen Quelle werden nicht wiederholt, wenn der Workflow nicht ausgeführt wird. Beachten Sie, dass Workflows Ereignisse bestätigen, sobald die Workflowausführung beginnt. Wenn die Workflowausführung beginnt, aber später fehlschlägt, werden die Ausführungen nicht wiederholt. Zum Beheben dieser Dienstprobleme sollten Sie Fehler und Wiederholungsversuche innerhalb des Workflows beheben.
Duplizierte Termine
Ereignis-Duplikate werden möglicherweise an Event-Handler gesendet. Gemäß der
CloudEvents-Spezifikation,
wird die Kombination der Attribute source und id als eindeutig angesehen und
daher werden alle Ereignisse mit derselben Kombination als Duplikate betrachtet. Sie sollten idempotente Event-Handler als allgemeine Best Practice implementieren.
Idempotente Event-Handler
Event-Handler, für die Wiederholungsversuche gemacht werden können, sollten gemäß den folgenden allgemeinen Richtlinien idempotent sein:
- Bei vielen externen APIs können Sie einen Idempotenzschlüssel als Parameter bereitstellen. Wenn Sie eine solche API verwenden, sollten Sie die Ereignis-ID als Idempotenzschlüssel verwenden.
- Idempotenz funktioniert gut bei mindestens einmaliger Übermittlung, weil Wiederholungsversuche dadurch problemlos erfolgen können. Eine allgemeine Best Practice für das Schreiben von zuverlässigem Code ist also, Idempotenz mit Wiederholungsversuchen zu kombinieren.
- Achten Sie darauf, dass der Code intern idempotent ist. Beispiele:
- Sorgen Sie dafür, dass Mutationen mehr als einmal passieren können, ohne das Ergebnis zu verändern.
- Fragen Sie den Datenbankstatus in einer Transaktion ab, bevor der Status mutiert wird.
- Stellen Sie sicher, dass alle Nebenwirkungen selbst idempotent sind.
- Erzwingen Sie eine Transaktionsprüfung außerhalb des Dienstes und unabhängig vom Code. Beispiel: Zustand an einem Punkt persistent machen, um aufzuzeichnen, dass eine bestimmte Ereignis-ID bereits verarbeitet wurde.
- Nutzen Sie ein Verfahren für doppelte Aufrufe "out of band". Verwenden Sie beispielsweise einen separaten Bereinigungsprozess, der nach doppelten Aufrufen eine Bereinigung durchführt.