Mencoba kembali peristiwa

Peristiwa dapat ditolak karena beberapa alasan. Misalnya, layanan penerima peristiwa mungkin tidak tersedia untuk sementara karena pemadaman layanan; error mungkin ditemukan oleh layanan saat memproses peristiwa; atau resource layanan mungkin habis. Error sementara seperti ini dapat dicoba lagi.

Peristiwa juga dapat gagal dikirim ke penerima peristiwa. Misalnya, peristiwa mungkin tidak cocok dengan skema yang diharapkan yang dikonfigurasi, atau mediasi peristiwa mungkin gagal sebelum pesan peristiwa dapat dirutekan ke tujuan akhirnya. Kasus tersebut akan menyebabkan error persisten.

Error sementara

Eventarc Advanced memberi Anda kemampuan untuk menangani error sementara. Error sementara ini dapat dicoba ulang 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 ulang; misalnya, kode error selain yang tercantum untuk error sementara

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

Mencoba ulang error sementara

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

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

Perhatikan bahwa faktor backoff 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 maksimum: jumlah percobaan ulang; defaultnya adalah 5 upaya. Dapat berupa bilangan riil positif apa pun. Jika disetel ke 1, tidak ada kebijakan percobaan ulang yang diterapkan dan hanya satu upaya yang dilakukan untuk mengirimkan pesan.
    • Min delay (seconds): penundaan awal dalam detik; defaultnya adalah 1 detik. Harus antara 1 dan 600.
    • Max delay (seconds): penundaan maksimum dalam detik; default-nya adalah 60 detik. Harus antara 1 dan 600.

    Anda dapat mengonfigurasi backoff linear dengan menetapkan penundaan minimum dan maksimum ke nilai yang sama.

  5. Klik Simpan.

gcloud 

gcloud beta 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 yang sepenuhnya memenuhi syarat dari pipeline.
  • 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 percobaan ulang; default-nya adalah upaya 5. Dapat berupa bilangan riil 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 backoff linear dengan menetapkan penundaan minimum dan maksimum ke nilai yang sama:

gcloud beta 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 begitu, Anda dapat mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

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

  1. Buat bus. Konfigurasikan 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 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. Konfigurasikan kebijakan percobaan ulang untuk pipeline.

    Misalnya, perintah berikut membuat pipeline dan pendaftaran:

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

    gcloud beta 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. Arahkan log pipeline Anda ke set data BigQuery lain.

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

  6. Untuk mengidentifikasi pesan yang gagal, gunakan pernyataan kueri untuk menggabungkan kedua set data BigQuery di 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 langsung ke bus Eventarc Advanced.

Membuat pengendali peristiwa bersifat 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 menggunakan API seperti itu, Anda harus menggunakan sumber dan ID peristiwa sebagai kunci idempotensi. (Produser harus memastikan bahwa source + id bersifat unik untuk setiap peristiwa yang berbeda.)
  • Selain itu, Anda dapat menggunakan atribut CloudEvents, xgooglemessageuid, untuk memberikan idempotensi. Nilai atribut ini sama dengan kolom message_uid dalam pesan Eventarc Advanced. ID ini secara unik mengidentifikasi tindakan memublikasikan peristiwa. 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