Eventarc Standard unterstützt die mindestens einmalige Ereignisübermittlung. Wenn ein Ziel ein Ereignis nicht bestätigen kann, versucht Eventarc automatisch, es noch einmal zu senden.
Die Wiederholungsmerkmale von Eventarc Standard entsprechen denen der Transportebene, Cloud Pub/Sub, die Verarbeitungsfehler mithilfe einer Abo-Wiederholungsrichtlinie 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 für Cloud Run-Ziele
Optional können Sie für Cloud Run-Ziele (einschließlich Cloud Run-Funktionen) einen einzelnen Zustellversuch ohne Wiederholungsversuche konfigurieren. Wenn Sie einen Eventarc-Trigger in der Google Cloud Console auf der Cloud Run-Seite erstellen, ist dies die Standard konfiguration. Andernfalls sind Wiederholungsversuche standardmäßig aktiviert, wenn Sie einen Trigger mit der Google Cloud CLI, Terraform oder in der Google Cloud Console from the Eventarc page erstellen.
Wir empfehlen, Wiederholungsversuche zu deaktivieren, wenn Sie Ihren Code entwickeln oder testen, um unkontrollierte Wiederholungsversuche zu vermeiden, die zu höheren Kosten und einer höheren Ressourcennutzung führen können. Umgekehrt empfehlen wir, Wiederholungsversuche zu aktivieren, wenn Ihr Code in der Produktion ist, und die Best Practices für die Behandlung von Wiederholungsversuchen zu befolgen, damit jede Nachricht wie erwartet verarbeitet wird. Sie können beispielsweise nicht zugestellte Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten (auch als Dead-Letter-Warteschlange bezeichnet), in dem Sie persistente Fehler speichern und analysieren können.
Weitere Informationen finden Sie in den folgenden Cloud Run-Leitfäden: Wiederholungsversuche für ereignisgesteuerte Funktionen konfigurieren und Trigger mit Eventarc erstellen.
Wiederholungsversuche konfigurieren
Möglicherweise möchten Sie das Standardverhalten für Wiederholungsversuche anpassen. Alle Einstellungen für Wiederholungsversuche und Aufbewahrung werden über die Pub/Sub-Abo-Wiederholungsrichtlinie konfiguriert, die mit Ihrem Eventarc-Trigger verknüpft ist.
Wenn Sie die Abo-Wiederholungsrichtlinie ändern möchten, ermitteln Sie zuerst das Pub/Sub-Abo, 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 aufzurufen.
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- Google Cloud Dokumentation.
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 folgende Werte in den 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 Pub/Sub-Abo-Wiederholungsrichtlinie, 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 aufzurufen.
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 muss 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 muss 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 Abo-Wiederholungsrichtlinie 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 jedes ausgelassene Flag der Standardwert verwendet:
MIN_RETRY_DELAY: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und muss 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 muss zwischen 0 und 600 liegen.
Optional können Sie mit dem Flag --clear-retry-policy die Wiederholungsrichtlinie löschen und das Abo so konfigurieren, dass Wiederholungsversuche sofort ausgeführt werden.
Terraform
Sie können eine Pub/Sub-Abo-Wiederholungsrichtlinie 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 muss 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 muss 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 folgende Werte in den Anfragedaten:
MIN_RETRY_DELAY: die minimale Verzögerung in Sekunden zwischen aufeinanderfolgenden Zustellungen einer bestimmten Nachricht. Der Standardwert ist 10 Sekunden und muss 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 muss 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 Hinweise 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 stellt Pub/Sub Nachrichten wieder zu. 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.