Mencoba kembali peristiwa

Peristiwa dapat ditolak karena beberapa alasan. Misalnya, layanan penerima peristiwa mungkin tidak tersedia untuk sementara karena gangguan; layanan mungkin mengalami error 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 seperti itu akan menghasilkan error persisten.

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 digandakan setelah setiap upaya yang gagal (hingga maksimum 60 detik dan lima upaya).

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

Perhatikan bahwa faktor backoff default 2 tidak dapat diubah.

Konsol

  1. Di Google Cloud konsol, 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 upaya pengiriman; default-nya adalah 5 upaya. Dapat berupa bilangan bulat positif apa pun. Jika ditetapkan ke 1, tidak ada kebijakan percobaan ulang yang diterapkan dan hanya satu upaya yang dilakukan untuk mengirim pesan.
    • Min delay (seconds): penundaan awal dalam detik; default-nya 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 Save.

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 yang memenuhi syarat sepenuhnya dari pipeline.
  • MIN_DELAY: penundaan awal dalam detik; default-nya adalah 1 detik. Harus antara 1 dan 600.
  • MAX_DELAY: penundaan maksimum dalam detik; default-nya adalah 60 detik. Harus antara 1 dan 600.
  • MAX_ATTEMPTS: jumlah upaya pengiriman; default-nya adalah 5 upaya. Dapat berupa bilangan bulat positif apa pun. Jika ditetapkan ke 1, tidak ada kebijakan percobaan ulang yang diterapkan dan hanya satu upaya yang dilakukan untuk mengirim pesan.

Contoh berikut mengonfigurasi backoff linear 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. Hal ini memungkinkan Anda mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

Berikut ringkasan langkah-langkah yang diperlukan untuk mengarsipkan pesan peristiwa, mengidentifikasi error persisten, dan mencoba lagi peristiwa 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. Konfigurasi 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. Rutekan 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 yang menyimpan log pipeline Anda.

  6. Untuk mengidentifikasi pesan yang gagal, gunakan a 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 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 sumber dan ID peristiwa sebagai kunci idempotensi. (Produsen harus memastikan bahwa sumber + 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