Mencoba kembali peristiwa

Dengan mengonfigurasi kebijakan percobaan ulang, Anda dapat mengirim ulang peristiwa secara otomatis setelah pengiriman gagal. Hal ini membantu memastikan pemrosesan pesan yang andal saat penerima peristiwa mengalami gangguan layanan sementara.

Peristiwa dapat ditolak karena error sementara, seperti saat penerima peristiwa tidak tersedia untuk sementara, mengalami error saat memproses peristiwa, atau kehabisan resource layanan. Anda dapat mencoba lagi error sementara seperti ini. Sebaliknya, error persisten terjadi saat peristiwa gagal mencocokkan skema yang dikonfigurasi atau saat mediasi gagal sebelum pesan dapat dirutekan ke tujuannya.

Error sementara

Eventarc Advanced memberi Anda kemampuan untuk menangani error sementara. Error sementara ini dapat dicoba lagi dan mencakup error dengan kode error berikut:

  • HTTP 408 Request Timeout
  • HTTP 409 Conflict
  • HTTP 429 Too Many Requests
  • HTTP 500 Internal Server Error
  • HTTP 502 Bad Gateway
  • HTTP 503 Service Unavailable
  • HTTP 504 Gateway Time-out

Error persisten

Berbeda dengan error sementara, error persisten mencakup hal berikut:

  • Error yang terjadi saat jumlah percobaan ulang yang dikonfigurasi habis
  • Error yang terjadi saat peristiwa gagal sebelum dapat dirutekan ke tujuannya
  • Error yang menghasilkan kode error yang dianggap tidak dapat dicoba lagi; misalnya, kode error selain yang tercantum untuk error sementara

Anda dapat mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

Mencoba lagi error sementara

Eventarc Advanced menggunakan penundaan backoff eksponensial untuk menangani error yang dapat dicoba lagi. Kebijakan percobaan ulang default dimulai dengan penundaan satu detik, dan penundaan akan berlipat ganda setelah setiap upaya gagal (hingga maksimum 60 detik dan lima upaya).

Anda dapat mengubah kebijakan percobaan ulang default menggunakan konsol Google Cloud atau perintah gcloud eventarc pipelines update.

Perhatikan bahwa faktor penundaan default 2 tidak dapat diubah.

Konsol

  1. Di konsol Google Cloud , buka halaman Eventarc > Pipelines.

    Buka Pipeline

  2. Klik nama pipeline.

  3. Di halaman Pipeline details, klik Edit.

  4. Di halaman Edit pipeline, di bagian Retry policy, ubah kolom berikut:

    • Upaya maks: jumlah upaya pengiriman; defaultnya adalah 5 upaya. Dapat berupa bilangan bulat positif apa pun. Jika disetel ke 1, tidak ada kebijakan percobaan ulang yang diterapkan dan hanya satu upaya yang dilakukan untuk mengirimkan pesan.
    • Penundaan minimum (detik): penundaan awal dalam detik; defaultnya adalah 1 detik. Harus antara 1 dan 600.
    • Penundaan maks. (detik): penundaan maksimum dalam detik; defaultnya adalah 60 detik. Harus antara 1 dan 600.

    Anda dapat mengonfigurasi penundaan linier dengan menyetel penundaan minimum dan maksimum ke nilai yang sama.

  5. Klik Simpan.

gcloud 

gcloud eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

Ganti kode berikut:

  • PIPELINE_NAME: ID atau ID pipeline yang sepenuhnya memenuhi syarat.
  • MIN_DELAY: penundaan awal dalam detik; defaultnya adalah 1 detik. Harus antara 1 dan 600.
  • MAX_DELAY: penundaan maksimum dalam detik; defaultnya adalah 60 detik. Harus antara 1 dan 600.
  • MAX_ATTEMPTS: jumlah upaya pengiriman; defaultnya adalah 5 upaya. Dapat berupa bilangan bulat positif apa pun. Jika disetel ke 1, tidak ada kebijakan percobaan ulang yang diterapkan dan hanya satu upaya yang dilakukan untuk mengirimkan pesan.

Contoh berikut mengonfigurasi penundaan linier dengan menetapkan penundaan minimum dan maksimum ke nilai yang sama:

gcloud eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Mengarsipkan pesan untuk menangani error persisten

Anda dapat menulis pesan ke tabel BigQuery saat pesan diterima. Dengan demikian, Anda dapat mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

Berikut ringkasan langkah-langkah yang diperlukan untuk mengarsipkan pesan acara, mengidentifikasi error persisten, dan mencoba lagi acara yang terpengaruh.

  1. Buat bus. Konfigurasi bus dengan tepat; misalnya, untuk memublikasikan peristiwa dari sumber Google.
  2. Buat topik Pub/Sub. Topik Pub/Sub ini akan menjadi tujuan target untuk pipeline Anda.
  3. Buat langganan BigQuery untuk topik Pub/Sub. Langganan BigQuery adalah jenis langganan ekspor yang menulis pesan ke tabel BigQuery yang sudah ada saat pesan diterima. Atau, Anda dapat membuat tabel saat membuat langganan BigQuery.

  4. Buat pipeline dan pendaftaran yang merutekan setiap pesan yang diterima oleh bus (menggunakan --cel-match="true") ke topik Pub/Sub. Mengonfigurasi kebijakan percobaan ulang untuk pipeline.

    Misalnya, perintah berikut membuat pipeline dan pendaftaran:

    gcloud eventarc pipelines create my-archive-pipeline \
    --destinations=pubsub_topic='my-archive-topic' \
    --min-retry-delay=1 \
    --max-retry-delay=20 \
    --max-retry-attempts=6 \
    --location=us-central1

    gcloud eventarc enrollments create my-archive-enrollment \
    --cel-match="true" \
    --destination-pipeline=my-archive-pipeline \
    --message-bus=my-message-bus \
    --message-bus-project=my-google-cloud-project \
    --location=us-central1

  5. Rute log pipeline ke set data BigQuery lain.

    Sekarang Anda akan memiliki dua set data BigQuery terpisah: satu yang menyimpan setiap pesan yang diterima oleh bus Advanced Eventarc dan satu yang menyimpan log pipeline Anda.

  6. Untuk mengidentifikasi pesan yang gagal, gunakan pernyataan kueri untuk menggabungkan kedua set data BigQuery pada kolom message_uid.

  7. Setelah mengidentifikasi pesan yang gagal, Anda dapat memublikasikannya ke bus lagi menggunakan Eventarc Publishing API. Misalnya, Anda dapat men-deploy layanan atau tugas Cloud Run untuk membaca pesan dari BigQuery dan memublikasikannya secara langsung ke bus Eventarc Advanced.

Membuat pengendali peristiwa bersifat idempoten

Handler 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 Anda menggunakan API seperti itu, Anda harus menggunakan sumber dan ID peristiwa sebagai kunci idempotensi. (Produsen harus memastikan bahwa source + id bersifat unik untuk setiap peristiwa yang berbeda.)
  • Selain itu, Anda dapat menggunakan atribut CloudEvents, xgooglemessageuid, untuk menyediakan idempotensi. Nilai atribut ini sama dengan kolom message_uid di pesan Lanjutan Eventarc. Secara unik mengidentifikasi tindakan memublikasikan acara. Misalnya, jika peristiwa yang sama dipublikasikan dua kali ke bus, setiap peristiwa akan memiliki nilai xgooglemessageuid yang berbeda saat dikirim ke pengendali peristiwa.
  • 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.

Langkah berikutnya