Eventarc Standard mendukung pengiriman peristiwa minimal satu kali. Artinya, jika tujuan gagal mengonfirmasi penerimaan peristiwa, Eventarc akan otomatis mencoba mengirim ulang peristiwa tersebut.
Karakteristik percobaan ulang Eventarc Standard cocok dengan karakteristik lapisan transportnya, Cloud Pub/Sub, yang menangani kegagalan pemrosesan dengan 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.)
Semua ID langganan yang dibuat secara otomatis oleh Eventarc akan memiliki
format yang dimulai dengan eventarc-REGION-.
Secara default, saat 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 ke 24 jam.
Untuk mengetahui informasi selengkapnya tentang cara Pub/Sub menangani percobaan ulang, lihat Menangani kegagalan pesan dan Permintaan percobaan ulang.
Praktik terbaik untuk menangani percobaan ulang
Jika pesan peristiwa tidak dapat dikirimkan dengan berhasil dalam periode retensi pesan, pesan tersebut akan dihapus kecuali jika topik yang dihentikan pengirimannya dikonfigurasi. Topik yang dihentikan pengirimannya memungkinkan Anda menyimpan dan menganalisis kegagalan persisten. Dalam dokumen ini, lihat Topik yang dihentikan pengirimannya.
Karena pengiriman minimal sekali, pengendali peristiwa Anda mungkin menerima peristiwa duplikat. Praktik terbaiknya adalah mendesain handler agar bersifat idempoten. Dalam dokumen ini, lihat Handler peristiwa idempoten.
Percobaan ulang untuk tujuan Cloud Run
Secara opsional, untuk tujuan Cloud Run (termasuk Cloud Run Functions), Anda dapat mengonfigurasi satu upaya pengiriman tanpa percobaan ulang. Saat Anda membuat pemicu Eventarc di Google Cloud konsol dari halaman Cloud Run, konfigurasi ini adalah konfigurasi default. Jika tidak, saat membuat pemicu menggunakan Google Cloud CLI, Terraform, atau di Google Cloud konsol dari halaman Eventarc, percobaan ulang diaktifkan secara default.
Sebaiknya nonaktifkan percobaan ulang saat mengembangkan atau menguji kode Anda untuk menghindari percobaan ulang yang tidak terkendali yang dapat menyebabkan peningkatan biaya dan penggunaan resource. Sebaliknya, sebaiknya aktifkan percobaan ulang saat kode Anda dalam produksi, dan ikuti praktik terbaik untuk menangani percobaan ulang agar setiap pesan diproses sesuai yang diharapkan. Misalnya, Anda dapat meneruskan pesan yang tidak terkirim ke topik pesan yang dihentikan pengirimannya (juga dikenal sebagai antrean pesan yang dihentikan pengirimannya) yang memungkinkan Anda menyimpan dan menganalisis kegagalan persisten.
Untuk mengetahui informasi selengkapnya, lihat panduan Cloud Run berikut: Mengonfigurasi percobaan ulang fungsi berbasis peristiwa dan Membuat pemicu dengan Eventarc.
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, identifikasi terlebih dahulu 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 konsol Google Cloud , 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 dan yang mencakup 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 google_eventarc_trigger, Anda dapat menggunakan perintah state show.
terraform state show google_eventarc_trigger.default
Perintah state show menampilkan informasi tentang pemicu yang mencakup
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 cara menggunakan Terraform, lihat dokumentasi Terraform di 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: Google Cloud Project ID Anda.LOCATION: region tempat pemicu dibuat—misalnya,us-central1.
Untuk mengirim permintaan Anda, luaskan 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, lakukan hal berikut:
Konsol
Di konsol Google Cloud , 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 Retry policy, pilih Retry immediately.
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. Defaultnya adalah 10 detik dan harus berada di antara 0 dan 600.
Backoff maksimum: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Default-nya adalah 600 detik dan harus antara 0 dan 600.
Untuk mengetahui informasi selengkapnya, lihat Kebijakan percobaan ulang.
Klik Update.
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 memenuhi syarat sepenuhnya.Kedua flag berikut harus ditentukan untuk mencoba lagi setelah backoff eksponensial; jika tidak, flag yang dihilangkan akan kembali ke nilai defaultnya:
MIN_RETRY_DELAY: penundaan minimum dalam detik antara pengiriman pesan tertentu yang berurutan. Defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Default-nya adalah 600 detik dan harus antara 0 dan 600.
Secara opsional, Anda dapat menggunakan tanda --clear-retry-policy untuk menghapus kebijakan
coba lagi dan menyetel langganan untuk mencoba lagi secara langsung.
Terraform
Anda dapat memperbarui kebijakan percobaan ulang langganan Pub/Sub dengan
mengonfigurasi
resource Terraform google_pubsub_subscription. 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. Defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Default-nya 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. Defaultnya adalah 10 detik dan harus antara 0 dan 600.MAX_RETRY_DELAY: penundaan maksimum dalam detik antara pengiriman pesan tertentu yang berurutan. Default-nya adalah 600 detik dan harus antara 0 dan 600.PROJECT_ID: Google Cloud Project ID Anda.SUBSCRIPTION_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.
Penundaan push
Jika pelanggan push mengirim terlalu banyak konfirmasi negatif, Pub/Sub mungkin mulai mengirim pesan menggunakan penundaan push. Saat menggunakan jeda pengiriman 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 mengirimkan pesan lagi. Untuk mengetahui informasi selengkapnya, lihat Penerapan kembali.
Topik yang dihentikan pengirimannya
Jika tujuan tidak menerima pesan, Anda dapat meneruskan pesan yang tidak terkirim ke topik yang dihentikan pengirimannya (juga dikenal sebagai antrean pesan yang dihentikan pengirimannya). Topik yang dihentikan pengirimannya dapat menyimpan pesan yang tidak dapat dikonfirmasi oleh tujuan. Anda harus menetapkan topik yang dihentikan pengirimannya saat membuat atau memperbarui langganan Pub/Sub, bukan saat membuat topik Pub/Sub atau saat Eventarc membuat topik Pub/Sub. Untuk informasi selengkapnya, lihat Mengonfigurasi topik yang dihentikan pengirimannya.
Error yang tidak memerlukan percobaan ulang
Jika 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 akan 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 coba lagi dalam alur kerja.
Acara duplikat
Peristiwa duplikat mungkin dikirim ke handler peristiwa. Menurut
spesifikasi CloudEvents,
kombinasi atribut source dan id dianggap unik, dan
oleh karena itu, setiap peristiwa dengan kombinasi yang sama dianggap duplikat. Anda
harus menerapkan handler peristiwa idempoten sebagai praktik terbaik umum.
Pengendali peristiwa idempoten
Pengendali peristiwa yang dapat dicoba ulang harus bersifat idempoten, menggunakan panduan umum berikut:
- Banyak API eksternal yang dapat Anda gunakan untuk menyuplai kunci idempotensi sebagai parameter. Jika Anda 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.