Eventarc Standard mendukung pengiriman peristiwa setidaknya sekali. Artinya, jika tujuan gagal mengonfirmasi peristiwa, Eventarc akan otomatis mencoba mengirimkannya kembali.
Karakteristik percobaan ulang Eventarc Standard cocok dengan karakteristik lapisan transportnya, Cloud Pub/Sub, yang menangani kegagalan pemrosesan menggunakan kebijakan percobaan ulang langganan.
Cara kerja percobaan ulang
Saat Anda membuat pemicu Eventarc, topik dan langganan transport Pub/Sub akan otomatis dibuat untuk Anda. (Peristiwa dari sumber Pub/Sub dapat menggunakan topik Pub/Sub yang ada.)
ID langganan apa pun yang dibuat secara otomatis oleh Eventarc akan memiliki a
format yang dimulai dengan eventarc-REGION-.
Secara default, jika tujuan tidak dapat mengonfirmasi pesan, Pub/Sub akan mengirim pesan lagi dengan penundaan backoff eksponensial. Backoff eksponensial memungkinkan Anda menambahkan penundaan yang semakin lama di antara upaya percobaan ulang. Penundaan default dimulai dari minimal 10 detik dan meningkat dengan setiap kegagalan berikutnya, hingga maksimum 600 detik. Eventarc menetapkan durasi retensi pesan default menjadi 24 jam.
Untuk mengetahui informasi selengkapnya tentang cara Pub/Sub menangani percobaan ulang, lihat Menangani kegagalan pesan dan Meminta percobaan ulang.
Praktik terbaik untuk menangani percobaan ulang
Jika pesan peristiwa tidak dapat berhasil dikirim dalam jangka waktu retensi pesan, pesan tersebut akan dihapus kecuali jika topik pesan yang dihentikan pengirimannya dikonfigurasi. Topik pesan yang dihentikan pengirimannya memungkinkan Anda menyimpan dan menganalisis kegagalan persisten. Dalam dokumen ini, lihat Topik pesan yang dihentikan pengirimannya.
Karena pengiriman setidaknya sekali, pengendali peristiwa Anda mungkin menerima peristiwa duplikat. Praktik terbaiknya adalah mendesain pengendali agar bersifat idempoten. Dalam dokumen ini, lihat Pengendali peristiwa idempoten.
Mengonfigurasi percobaan ulang
Anda mungkin ingin menyesuaikan perilaku percobaan ulang default. Semua setelan percobaan ulang dan retensi dikonfigurasi melalui kebijakan percobaan ulang langganan Pub/Sub yang terkait dengan pemicu Eventarc Anda.
Untuk mengubah kebijakan percobaan ulang langganan, pertama-tama identifikasi langganan Pub/Sub yang terkait dengan pemicu Eventarc Anda. Kemudian, perbarui langganan itu sendiri.
Untuk mengetahui informasi selengkapnya tentang properti langganan, lihat Properti langganan. Untuk mengetahui informasi tentang batas langganan, lihat Batas resource Pub/Sub.
Mengidentifikasi langganan
Untuk mengidentifikasi langganan Pub/Sub yang terkait dengan pemicu Eventarc Anda, lakukan hal berikut:
Konsol
Di Google Cloud konsol, buka halaman Pemicu Eventarc.
Dari daftar pemicu, klik pemicu yang detailnya ingin Anda ketahui.
Klik nama topik.
Untuk menampilkan ID langganan, klik tab Langganan.
gcloud
Anda dapat menggunakan perintah
gcloud eventarc triggers describe
untuk mengambil ID langganan.
gcloud eventarc triggers describe TRIGGER_NAME \ --location=LOCATION
Ganti kode berikut:
TRIGGER_NAME: nama pemicu atau ID yang sepenuhnya memenuhi syarat.LOCATION: lokasi pemicu Eventarc.
Perintah ini menampilkan informasi tentang pemicu yang mirip dengan berikut ini dan yang menyertakan ID langganan:
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
Untuk mendeskripsikan resource Terraform, Anda dapat menggunakan perintah state show.google_eventarc_trigger
terraform state show google_eventarc_trigger.default
Perintah state show menampilkan informasi tentang pemicu yang menyertakan ID langganan. Contoh:
# 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"
}
}
}
Untuk mengetahui informasi selengkapnya tentang penggunaan Terraform, lihat dokumentasi Terraform. Google Cloud
REST
Untuk mendeskripsikan pemicu dalam project dan lokasi tertentu, gunakan metode
projects.locations.triggers.get.
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
TRIGGER_NAME: nama pemicu yang ingin Anda deskripsikan.PROJECT_ID: ID project Anda. Google CloudLOCATION: region tempat pemicu dibuat—misalnya,us-central1.
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Jika berhasil, isi respons berisi instance
Trigger
yang mirip dengan berikut ini:
{
"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"
}
}
}
Memperbarui langganan
Untuk memperbarui kebijakan percobaan ulang langganan Pub/Sub yang terkait dengan pemicu Eventarc Anda, lakukan hal berikut:
Konsol
Di Google Cloud konsol, buka halaman Pemicu Eventarc.
Dari daftar pemicu, klik pemicu yang detailnya ingin Anda ketahui.
Klik nama topik.
Untuk menampilkan ID langganan, klik tab Langganan.
Klik ID langganan, lalu klik Edit.
Di bagian Kebijakan percobaan ulang, pilih Coba lagi segera.
Atau, untuk mencoba lagi setelah penundaan backoff eksponensial, masukkan nilai berikut dalam detik:
Backoff minimum: penundaan minimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 10 detik dan harus antara 0 dan 600.
Backoff maksimum: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 600 detik dan harus antara 0 dan 600.
Untuk mengetahui informasi selengkapnya, lihat Kebijakan percobaan ulang.
Klik Perbarui.
gcloud
Anda dapat menggunakan perintah
gcloud pubsub subscriptions update
untuk memperbarui kebijakan percobaan ulang langganan.
gcloud pubsub subscriptions update SUBSCRIPTION_ID \ --min-retry-delay=MIN_RETRY_DELAY \ --max-retry-delay=MAX_RETRY_DELAY
Ganti kode berikut:
SUBSCRIPTION_ID: ID langganan atau ID yang sepenuhnya memenuhi syarat.Kedua flag berikut harus ditentukan untuk mencoba lagi setelah penundaan backoff eksponensial; jika tidak, flag yang dihilangkan akan kembali ke nilai default-nya:
MIN_RETRY_DELAY: penundaan minimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 600 detik dan harus antara 0 dan 600.
Secara opsional, Anda dapat menggunakan flag --clear-retry-policy untuk menghapus kebijakan percobaan ulang dan menetapkan langganan untuk mencoba lagi segera.
Terraform
Anda dapat memperbarui kebijakan percobaan ulang langganan Pub/Sub dengan
mengonfigurasi
google_pubsub_subscription
resource Terraform. Gunakan blok
import untuk mengimpor langganan yang ada sehingga Terraform dapat melacak resource
dalam file status Anda. Kemudian, Anda dapat mengelola resource yang diimpor seperti resource lainnya,
menggunakan
ignore_changes
untuk menentukan atribut yang harus diabaikan Terraform saat memperbarui
resource.
Contoh:
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] } }
Ganti kode berikut:
SUBSCRIPTION_ID: ID langganan.TOPIC_ID: ID topik.MIN_RETRY_DELAY: penundaan minimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 600 detik dan harus antara 0 dan 600.
REST
Untuk memperbarui kebijakan percobaan ulang langganan dalam project tertentu, gunakan metode
projects.subscriptions.patch.
Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:
MIN_RETRY_DELAY: penundaan minimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Nilai defaultnya adalah 600 detik dan harus antara 0 dan 600.PROJECT_ID: ID project Anda. Google CloudSUBSCRIPTION_ID: ID langganan Pub/Sub yang Anda perbarui.
Meminta isi JSON:
{
"subscription": {
"retryPolicy": {
"minimumBackoff": "MIN_RETRY_DELAYs",
"maximumBackoff": "MAX_RETRY_DELAYs"
}
},
"updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
Untuk mengirim permintaan Anda, perluas salah satu opsi berikut:
Jika berhasil, isi respons berisi instance
Subscription
yang mirip dengan berikut ini:
{
"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"
}
Pertimbangan percobaan ulang lainnya
Anda harus mengetahui pertimbangan berikut saat menangani kegagalan pemrosesan atau meneruskan pesan yang tidak terkirim.
Backoff push
Jika pelanggan push mengirim terlalu banyak konfirmasi negatif, Pub/Sub mungkin mulai mengirim pesan menggunakan backoff push. Saat Pub/Sub menggunakan backoff push, Pub/Sub akan berhenti mengirim pesan selama jangka waktu yang telah ditentukan. Rentang waktu ini dapat berkisar antara 100 milidetik hingga 60 detik. Setelah waktu berlalu, Pub/Sub akan mulai mengirim pesan lagi. Untuk mengetahui informasi selengkapnya, lihat Backoff push.
Topik pesan yang dihentikan pengirimannya
Jika tujuan tidak menerima pesan, Anda dapat meneruskan pesan yang tidak terkirim ke topik pesan yang dihentikan pengirimannya (juga dikenal sebagai antrean pesan yang dihentikan pengirimannya). Topik pesan yang dihentikan pengirimannya dapat menyimpan pesan yang tidak dapat dikonfirmasi oleh tujuan. Anda harus menetapkan topik pesan yang dihentikan pengirimannya saat membuat atau memperbarui langganan Pub/Sub, bukan saat Anda membuat topik Pub/Sub atau saat Eventarc membuat topik Pub/Sub. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi topik pesan yang dihentikan pengirimannya.
Error yang tidak memerlukan percobaan ulang
Saat aplikasi menggunakan Pub/Sub sebagai sumber peristiwa dan peristiwa tidak dikirim, peristiwa akan otomatis dicoba lagi, kecuali untuk error yang tidak memerlukan percobaan ulang. Peristiwa ke tujuan Workflows dari sumber mana pun tidak akan dicoba lagi jika alur kerja tidak dijalankan. Perhatikan bahwa Workflows mengonfirmasi peristiwa segera setelah eksekusi alur kerja dimulai. Jika eksekusi alur kerja dimulai tetapi kemudian gagal, eksekusi tidak akan dicoba lagi. Untuk mengatasi masalah layanan tersebut, Anda harus menangani error dan percobaan ulang dalam alur kerja.
Peristiwa duplikat
Peristiwa duplikat mungkin dikirim ke pengendali peristiwa. Menurut
spesifikasi CloudEvents,
kombinasi atribut source dan id dianggap unik, sehingga
peristiwa apa pun dengan kombinasi yang sama dianggap duplikat. Anda harus menerapkan pengendali peristiwa idempoten sebagai praktik terbaik umum.
Pengendali peristiwa idempoten
Pengendali peristiwa yang dapat dicoba lagi harus bersifat idempoten, menggunakan panduan umum berikut:
- Banyak API eksternal yang dapat Anda gunakan untuk menyuplai kunci idempotensi sebagai parameter. Jika menggunakan API seperti itu, Anda harus menggunakan ID peristiwa sebagai kunci idempotensi.
- Idempotensi berfungsi dengan baik pada pengiriman "setidaknya sekali" karena memberikan keamanan untuk mencoba ulang. Jadi, salah satu praktik terbaik yang umum untuk menulis kode tepercaya adalah dengan menggabungkan idempotensi dengan percobaan ulang.
- Pastikan kode Anda idempoten secara internal. Contoh:
- Pastikan mutasi bisa terjadi lebih dari sekali tanpa mengubah hasilnya.
- Jalankan kueri pada status database dalam transaksi sebelum memutasikan status tersebut.
- Pastikan semua efek samping bersifat idempoten.
- Lakukan pemeriksaan transaksi di luar layanan Anda, terlepas dari kode. Sebagai contoh, pertahankan status di suatu tempat yang mencatat bahwa ID peristiwa tertentu telah diproses.
- Tangani panggilan duplikat yang tidak umum. Misalnya, jalankan proses pembersihan terpisah yang akan melakukan pembersihan setelah panggilan duplikat.