Die Wiederholungsmerkmale von Eventarc entsprechen denen der Transportebene, Cloud Pub/Sub. Weitere Informationen finden Sie unter Anfragen wiederholen und Push-Backoff.
Die von Eventarc festgelegte Standardaufbewahrungsdauer für Nachrichten beträgt 24 Stunden mit einer exponentiellen Backoff-Verzögerung.
Sie können die Wiederholungsrichtlinie über das Pub/Sub-Abo aktualisieren, das dem Eventarc-Trigger zugeordnet ist:
- Öffnen Sie die Seite "Trigger-Details".
- Klicken Sie auf das Thema.
- Klicken Sie auf den Tab Abos.
Alle von Eventarc automatisch erstellten Abos haben folgendes Format: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Weitere Informationen zu Abolimits finden Sie unter Pub/Sub-Ressourcenlimits.
Wenn Pub/Sub eine Nachricht zustellen soll, das Ziel sie jedoch nicht bestätigen kann, sendet Pub/Sub die Nachricht noch einmal mit einem minimalen exponentiellen Backoff von zehn Sekunden. Wenn das Ziel die Nachricht weiterhin nicht bestätigt, wird der Verzögerung bei jedem Wiederholungsversuch (bis zu einem Maximum von 600 Sekunden) mehr Zeit hinzugefügt und die Nachricht wird noch einmal an das Ziel gesendet.
Beachten Sie, dass Workflows Ereignisse bestätigt, sobald die Workflowausführung beginnt.
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 Umgang mit Nachrichtenfehlern.
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 das Workflowziel von einer beliebigen Quelle werden nicht wiederholt, wenn der Workflow nicht ausgeführt wird. 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.
Event-Handler idempotent machen
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.