Memutar ulang dan menghapus permanen pesan dengan fitur cari

Setelah Anda mengonfirmasi pesan di Pub/Sub, pesan ini menjadi tidak dapat diakses oleh klien pelanggan. Selain itu, klien pelanggan harus memproses setiap pesan dalam langganan meskipun hanya sebagian yang diperlukan.

Fitur pencarian memperluas kemampuan subscriber dengan memungkinkan Anda mengubah status konfirmasi pesan secara massal. Misalnya, Anda dapat memutar ulang pesan yang sebelumnya telah dikonfirmasi atau menghapus pesan secara massal. Selain itu, Anda dapat menyalin status konfirmasi satu langganan ke langganan lain dengan menggunakan pencarian bersama dengan snapshot.

Untuk melihat demonstrasi singkat cara kerja fitur ini, lihat Memutar ulang pesan di Pub/Sub dengan mencari snapshot atau stempel waktu.

Ringkasan snapshot dan pencarian

Snapshot Pub/Sub adalah tampilan titik waktu yang tahan lama, konsisten, dan andal dari status konfirmasi (ack) pesan suatu langganan. Snapshot mencatat status konfirmasi semua pesan dalam langganan pada saat pembuatannya. Snapshot mempertahankan pesan yang belum dikonfirmasi dari langganan sumber pada saat pembuatan snapshot, dan pesan apa pun yang dipublikasikan ke topik setelah snapshot dibuat.

Masa aktif snapshot ditentukan oleh backlog yang ada pada langganan sumber. Masa berlaku sama dengan 7 hari dikurangi usia pesan terlama yang belum dikonfirmasi dalam langganan. Misalnya, pertimbangkan snapshot langganan dengan backlog yang pesan terlamanya yang belum dikonfirmasi berusia 1 hari. Snapshot akan habis masa berlakunya setelah 6 hari. Linimasa ini diperlukan agar snapshot dapat menawarkan jaminan pengiriman setidaknya sekali yang kuat.

Masa aktif snapshot maksimum yang memungkinkan adalah tujuh hari. Anda tidak dapat membuat snapshot yang akan berakhir dalam waktu kurang dari 1 jam setelah waktu pembuatannya.

Fitur pencarian memungkinkan Anda mencari snapshot atau stempel waktu tertentu untuk langganan. Fitur ini memungkinkan Anda mengontrol cara Pub/Sub dapat mengirimkan pesan dari titik waktu tertentu atau dari snapshot tertentu.

Untuk mencari ke waktu di masa lalu dan memutar ulang pesan yang sebelumnya dikonfirmasi, Anda harus mengonfigurasi retensi pesan di topik, atau mengonfigurasi langganan untuk mempertahankan pesan yang dikonfirmasi. Untuk informasi selengkapnya, lihat referensi berikut:

Konsistensi tertunda operasi pencarian

Operasi pencarian sangat konsisten dalam hal jaminan pengiriman pesan. Artinya, setiap pesan yang akan menjadi belum dikonfirmasi berdasarkan kondisi pencarian dijamin akan dikirimkan pada akhirnya setelah operasi pencarian berhasil. Namun, pesan yang dikirim tidak langsung konsisten dengan operasi penelusuran. Jadi, pesan yang dipublikasikan sebelum stempel waktu pencarian atau yang dikonfirmasi dalam snapshot mungkin dikirim setelah operasi pencarian. Dalam arti tertentu, pengiriman pesan beroperasi sebagai sistem yang konsisten pada akhirnya sehubungan dengan operasi penelusuran; mungkin diperlukan waktu hingga satu menit agar operasi tersebut diterapkan sepenuhnya.

Kasus penggunaan untuk operasi pencarian

  • Perbarui kode pelanggan dengan aman. Masalah saat men-deploy kode pelanggan baru adalah bahwa executable baru dapat secara keliru mengonfirmasi pesan, sehingga menyebabkan hilangnya pesan. Dengan menyertakan snapshot ke dalam proses deployment, Anda dapat memulihkan diri dari bug dalam kode pelanggan baru.
  • Pulihkan dari masalah pelanggan yang tidak terduga. Jika masalah pelanggan tidak terkait dengan peristiwa deployment tertentu, Anda mungkin tidak memiliki snapshot yang relevan. Dalam hal ini, jika Anda telah mengaktifkan retensi pesan yang telah dibaca untuk langganan, mencari waktu di masa lalu akan memberi Anda cara untuk memulihkan dari error.
  • Menghemat waktu dan biaya pemrosesan. Melakukan konfirmasi massal pada backlog pesan besar yang tidak lagi relevan.
  • Uji kode pelanggan pada data yang diketahui. Saat menguji kode pelanggan untuk performa dan konsistensi, sebaiknya gunakan data yang sama di setiap proses. Snapshot memungkinkan data yang konsisten dengan semantik yang kuat. Selain itu, snapshot dapat diterapkan ke langganan apa pun pada topik tertentu, termasuk langganan yang baru dibuat.

Membuat snapshot

Anda dapat membuat snapshot menggunakan konsol, Google API, atau Google Cloud CLI.

Konsol

Untuk membuat snapshot, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , buka halaman Snapshot.

    Buka halaman snapshot

  2. Klik Create snapshot.

  3. Untuk Select a Pub/Sub subscription, pilih langganan.

  4. Untuk Snapshot ID, masukkan nama untuk snapshot.

    Untuk mengetahui informasi selengkapnya tentang cara memberi nama resource Pub/Sub, lihat Pedoman untuk memberi nama topik, langganan, skema, atau snapshot.

  5. Klik Create untuk membuat snapshot.

Anda juga dapat membuat snapshot dari halaman Langganan. Jika Anda membuat snapshot segera setelah membuat langganan, Anda mungkin akan mendapatkan error karena penundaan propagasi untuk langganan yang baru dibuat.

gcloud

Untuk membuat snapshot, gunakan perintah gcloud pubsub snapshots create berikut:

gcloud pubsub snapshots create \
    --project=PROJECT_ID \
    --subscription=SUBSCRIPTION_ID \
    SNAPSHOT_ID

Ganti kode berikut:

  • PROJECT_ID. Menentukan ID project.

  • SUBSCRIPTION_ID. Menentukan ID langganan.

  • SNAPSHOT_ID. Menentukan ID snapshot.

Mencari stempel waktu

Mencari waktu menandai setiap pesan yang diterima oleh Pub/Sub sebelum waktu tersebut sebagai telah dikonfirmasi, dan semua pesan yang diterima setelah waktu tersebut sebagai tidak dikonfirmasi.

Anda dapat melakukan jenis operasi penelusuran berikut berdasarkan stempel waktu:

  • Untuk menghapus semua pesan, Anda dapat mencari ke waktu di masa mendatang.

  • Untuk memutar ulang dan memproses ulang pesan yang dikonfirmasi sebelumnya, cari ke waktu di masa lalu.

Waktu publikasi pesan dibuat oleh server Pub/Sub (lihat publishTime dalam referensi API). Pendekatan ini tidak akurat karena alasan berikut:

  • Kemungkinan perbedaan waktu di antara server Pub/Sub.

  • Fakta bahwa Pub/Sub harus bekerja dengan waktu kedatangan permintaan publikasi, bukan saat peristiwa terjadi di sistem sumber.

Anda dapat mencari stempel waktu menggunakan konsol, Google API, atau Google Cloud CLI CLI. Sebelum Anda mencari stempel waktu pada langganan, pastikan retensi pesan diaktifkan pada langganan.

Konsol

Untuk mencari stempel waktu, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , buka halaman Subscription.

    Buka Langganan

  2. Klik langganan yang mengaktifkan retensi pesan.

  3. Di halaman detail langganan, klik Putar ulang pesan.

  4. Untuk Cari, klik Ke titik waktu sebelumnya.

  5. Pilih tanggal dan waktu yang sesuai, lalu klik Cari.

gcloud

Untuk mencari stempel waktu, gunakan perintah gcloud pubsub subscriptions seek berikut:

gcloud pubsub subscriptions seek SUBSCRIPTION_ID \
    --time=TIME \

Ganti kode berikut:

  • TIME: waktu yang ingin Anda gunakan untuk melakukan operasi penelusuran.
  • SUBSCRIPTION_ID: ID langganan.

Untuk mengetahui informasi selengkapnya tentang format waktu yang didukung, lihat gcloud topic datetimes.

Mencari snapshot

Anda dapat memutar ulang pesan yang belum dikonfirmasi menggunakan snapshot untuk mencari langganan topik.

Tidak seperti saat mencari waktu, Anda tidak perlu melakukan konfigurasi langganan khusus untuk mencari snapshot. Anda hanya perlu membuat snapshot terlebih dahulu. Misalnya, Anda dapat membuat snapshot saat men-deploy kode pelanggan baru, jika Anda perlu memulihkan dari konfirmasi yang tidak terduga atau salah.

Jika backlog dalam langganan terlalu lama dan snapshot yang dihasilkan akan berakhir dalam waktu kurang dari 1 jam, operasi penelusuran akan gagal.

Anda dapat mencari snapshot menggunakan konsol, Google API, atau Google Cloud CLI CLI.

Konsol

Untuk mencari snapshot, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , buka halaman Subscription.

    Buka Langganan

  2. Klik langganan.

  3. Di halaman detail langganan, klik Putar ulang pesan.

  4. Untuk Cari, klik Ke snapshot.

  5. Pilih snapshot yang sesuai, lalu klik Cari.

gcloud

Untuk mencari snapshot, gunakan perintah gcloud pubsub subscriptions seek berikut:

gcloud pubsub subscriptions seek SUBSCRIPTION_ID \
    --snapshot=SNAPSHOT_ID

Ganti kode berikut:

  • SNAPSHOT_ID: ID snapshot. Topik snapshot harus sama dengan topik langganan.
  • SUBSCRIPTION_ID: ID langganan.

Mencari dengan filter

Anda dapat memutar ulang pesan dari langganan dengan filter. Jika Anda mencari stempel waktu menggunakan langganan dengan filter, layanan Pub/Sub hanya mengirim ulang pesan yang cocok dengan filter.

Snapshot langganan dengan filter berisi pesan berikut:

  • Semua pesan yang lebih baru dari snapshot, termasuk pesan yang tidak cocok dengan filter.
  • Pesan yang tidak terkonfirmasi yang lebih lama dari snapshot.

Jika Anda mencari snapshot menggunakan langganan dengan filter, layanan Pub/Sub hanya mengirim ulang pesan dalam snapshot yang cocok dengan filter langganan yang membuat permintaan pencarian.

Untuk mengetahui informasi selengkapnya tentang filter, lihat Memfilter pesan.

Mencari dengan topik yang dihentikan pengirimannya

Jika Anda mencari pesan dalam langganan dengan topik yang dihentikan pengirimannya, Pub/Sub akan menyetel upaya pengiriman ke 0. Pesan yang Anda terima dari langganan ini memiliki kolom yang mencatat jumlah upaya pengiriman.

Untuk mengetahui informasi selengkapnya tentang topik pesan yang tidak terkirim, lihat Meneruskan ke topik pesan yang tidak terkirim.

Mencari dengan kebijakan percobaan ulang

Jika Anda mencari pesan dalam langganan dengan kebijakan percobaan ulang, Pub/Sub akan mereset penundaan antara:

  1. Batas waktu konfirmasi habis atau pelanggan mengirimkan konfirmasi negatif.
  2. Pub/Sub mengirim ulang pesan.

Untuk mengetahui informasi selengkapnya tentang kebijakan percobaan ulang, lihat Menggunakan kebijakan percobaan ulang.

Mencari dengan pengiriman tepat satu kali

Jika Anda mencari pesan dalam langganan dengan pengiriman tepat satu kali, Pub/Sub akan mengirim ulang pesan yang sebelumnya dikonfirmasi dan memenuhi syarat untuk dikirim. Setiap konfirmasi, untuk pengiriman yang dilakukan sebelum operasi seek, akan gagal. Operasi penelusuran memiliki konsistensi tertunda.

Untuk mengetahui informasi selengkapnya tentang kebijakan percobaan ulang, lihat Pengiriman tepat satu kali.