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 cari memperluas kemampuan pelanggan dengan memungkinkan Anda mengubah status konfirmasi pesan secara massal. Misalnya, Anda dapat memutar ulang pesan yang sebelumnya direspons atau menghapus pesan secara massal. Selain itu, Anda dapat menyalin status konfirmasi dari satu langganan ke langganan lain menggunakan pencarian yang dikombinasikan dengan snapshot.

Untuk demonstrasi singkat tentang 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 andal, konsisten, dan dapat diandalkan dari status konfirmasi pesan (ack) langganan. Snapshot mencatat status konfirmasi semua pesan dalam langganan pada saat pembuatannya. Snapshot mempertahankan pesan yang tidak 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 langganan sumber yang ada. Masa berlakunya sama dengan 7 hari dikurangi usia pesan terlama yang tidak dikonfirmasi dalam langganan. Misalnya, pertimbangkan snapshot langganan dengan backlog yang pesan tertuanya yang tidak terkonfirmasi sudah berumur 1 hari. Masa berlaku snapshot akan berakhir setelah 6 hari. Linimasa ini diperlukan agar snapshot menawarkan jaminan pengiriman setidaknya satu kali yang kuat.

Masa aktif maksimum snapshot 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 mengirim pesan dari titik waktu tertentu atau dari snapshot tertentu.

Untuk mencari ke waktu sebelumnya dan memutar ulang pesan yang sebelumnya dikonfirmasi, Anda harus terlebih dahulu mengonfigurasi retensi pesan pada topik atau mengonfigurasi langganan untuk mempertahankan pesan yang dikonfirmasi.

Konsistensi tertunda operasi pencarian

Operasi pencarian sangat konsisten sehubungan dengan jaminan pengiriman pesan. Artinya, setiap pesan yang tidak akan direspons berdasarkan kondisi pencarian dijamin akan dikirimkan pada akhirnya setelah operasi pencarian berhasil. Namun, pesan yang dikirim tidak langsung menjadi konsisten dengan operasi pencarian. 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 pada akhirnya konsisten sehubungan dengan operasi pencarian; mungkin perlu waktu hingga satu menit agar operasi tersebut berlaku sepenuhnya.

Kasus penggunaan untuk operasi pencarian

  • Memperbarui kode pelanggan dengan aman. Masalah terkait deployment kode subscriber baru adalah bahwa file yang dapat dieksekusi baru mungkin salah mengonfirmasi pesan, sehingga menyebabkan hilangnya pesan. Menggabungkan snapshot ke dalam proses deployment memberi Anda cara untuk memulihkan dari bug dalam kode pelanggan baru.
  • Pulihkan dari masalah pelanggan yang tidak terduga. Jika masalah pelanggan tidak dikaitkan dengan peristiwa deployment tertentu, Anda mungkin tidak memiliki snapshot yang relevan. Dalam hal ini, jika Anda telah mengaktifkan retensi pesan yang direspons untuk langganan, mencari waktu di masa lalu akan memberi Anda cara untuk memulihkan dari error.
  • Hemat waktu dan biaya pemrosesan. Lakukan konfirmasi massal pada backlog pesan yang besar dan tidak lagi relevan.
  • Menguji kode pelanggan pada data yang diketahui. Saat menguji kode subscriber untuk performa dan konsistensi, sebaiknya gunakan data yang sama di setiap operasi. 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.

Mengonfigurasi retensi pesan

Anda dapat mengonfigurasi retensi pesan pada topik dan mengonfigurasi salah satu langganannya untuk mempertahankan pesan yang terkonfirmasi. Anda dapat mengonfigurasi retensi pesan topik jika ingin pesan dipertahankan untuk diputar ulang selama durasi yang lebih lama dari retensi pesan yang dikonfigurasi di langganan. Dalam situasi ini, project topik dan project langganan akan dikenai biaya penyimpanan pesan sesuai dengan setelan retensi pesan masing-masing.

Jika retensi pesan topik tidak dikonfigurasi, pesan yang tidak dikonfirmasi akan dihapus dari langganan jika usianya melebihi properti message_retention_duration langganan. Di sisi lain, jika retensi pesan topik dikonfigurasi, pesan yang tidak dikonfirmasi akan dihapus dari langganan hanya jika usianya melebihi maksimum message_retention_duration topik dan langganan.

Mengonfigurasi retensi pesan topik

Secara default, topik Pub/Sub akan menghapus pesan segera setelah dikonfirmasi oleh semua langganan yang terpasang ke topik tersebut. Mengonfigurasi topik dengan retensi pesan memberi Anda lebih banyak fleksibilitas, sehingga memungkinkan langganan apa pun yang dilampirkan ke topik untuk mencari kembali ke waktu yang lalu dan memutar ulang pesan yang sebelumnya diakui hingga message_retention_duration topik. Retensi pesan topik juga memungkinkan langganan memutar ulang pesan yang dipublikasikan sebelum Anda membuat langganan.

Topik dapat mempertahankan pesan yang dipublikasikan maksimal 31 hari (dapat dikonfigurasi oleh properti message_retention_duration topik) bahkan setelah dikonfirmasi oleh semua langganan yang terpasang. Jika message_retention_duration topik lebih besar dari message_retention_duration langganan, Pub/Sub hanya akan menghapus pesan jika usianya melebihi message_retention_duration topik.

Jika retensi pesan topik diaktifkan, biaya penyimpanan untuk pesan yang dipertahankan oleh topik akan ditagih ke project topik.

Konsol

Untuk membuat topik dengan retensi pesan yang diaktifkan, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Pub/Sub topics.

    Buka halaman topik

  2. Klik Create topic.

  3. Di kolom ID Topik, masukkan ID untuk topik Anda.

  4. Aktifkan Setel durasi retensi pesan.

    Biarkan opsi lainnya dalam setelan defaultnya.

  5. Gunakan menu drop-down Durasi retensi pesan untuk memilih jumlah hari, jam, dan menit untuk mempertahankan pesan.

  6. Klik Create topic untuk menyimpan topik.

Untuk memperbarui setelan retensi pesan topik:

  1. Pilih topik Anda dari halaman Pub/Sub topics.

    Buka halaman topik

  2. Klik Edit di bagian atas halaman detail topik.

  3. Sesuaikan waktu retensi atau aktifkan atau nonaktifkan retensi pesan dengan mencentang atau menghapus centang pada opsi Aktifkan retensi pesan.

  4. Klik Perbarui untuk menyimpan perubahan pada topik.

gcloud

Untuk membuat topik dengan durasi retensi pesan 7 hari, gunakan perintah gcloud pubsub topics create berikut:

gcloud pubsub topics create TOPIC_ID --message-retention-duration=7d

Anda dapat memperbarui setelan ini menggunakan gcloud pubsub topics update. Tindakan ini juga memungkinkan Anda mengaktifkan retensi pesan untuk topik yang sudah ada:

gcloud pubsub topics update TOPIC_ID --message-retention-duration=1d

Anda juga dapat menonaktifkan retensi pesan untuk topik dengan perintah update:

gcloud pubsub topics update TOPIC_ID --clear-message-retention-duration

Mengonfigurasi retensi pesan langganan

Pub/Sub mulai menyimpan pesan atas nama langganan saat langganan dibuat. Secara default, Pub/Sub akan menghapus pesan dari langganan segera setelah pesan dikonfirmasi. Pesan yang tidak terkonfirmasi disimpan selama 7 hari secara default (dapat dikonfigurasi oleh properti message_retention_duration langganan).

Mengonfigurasi langganan untuk mempertahankan pesan yang terkonfirmasi (menggunakan properti retain_acked_messages) memungkinkan Anda memutar ulang pesan yang sebelumnya dikonfirmasi dan disimpan oleh langganan. Anda dapat mengonfigurasi pesan untuk disimpan selama maksimal 31 hari dalam langganan. Konfigurasi ini berlaku untuk pesan yang direspons dan tidak direspons.

Jika langganan dikonfigurasi untuk mempertahankan pesan yang terkonfirmasi, biaya penyimpanan untuk pesan yang terkonfirmasi yang dipertahankan oleh langganan akan ditagih ke project langganan.

Konsol

Untuk membuat langganan dengan retensi pesan yang dikonfirmasi diaktifkan, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Langganan Pub/Sub.

    Buka halaman langganan

  2. Klik Buat langganan.

  3. Di kolom Subscription ID, masukkan ID untuk langganan Anda.

  4. Gunakan menu drop-down Durasi retensi pesan untuk memilih jumlah hari, jam, dan menit untuk mempertahankan pesan.

  5. Aktifkan Pertahankan pesan yang dikonfirmasi. Biarkan opsi lainnya dalam setelan defaultnya.

  6. Klik Buat langganan untuk menyimpan langganan.

Untuk memperbarui setelan retensi pesan langganan:

  1. Pilih langganan Anda dari halaman Pub/Sub subscriptions.

    Buka halaman langganan

  2. Klik Edit di bagian atas halaman detail langganan.

  3. Sesuaikan durasi retensi pesan, atau aktifkan atau nonaktifkan retensi pesan yang dikonfirmasi dengan mencentang atau menghapus centang pada kolom berlabel Simpan pesan yang dikonfirmasi.

  4. Klik Perbarui untuk menyimpan perubahan pada langganan.

gcloud

Untuk membuat langganan dengan retensi pesan yang dikonfirmasi diaktifkan, gunakan perintah gcloud pubsub subscriptions create berikut:

gcloud pubsub subscriptions create SUBSCRIPTION_ID
    --retain-acked-messages
    --message-retention-duration=5d

Anda dapat memperbarui setelan ini menggunakan gcloud pubsub subscriptions update . Tindakan ini juga memungkinkan Anda mengaktifkan retensi pesan yang dikonfirmasi untuk langganan yang ada:

gcloud pubsub subscriptions update SUBSCRIPTION_ID --message-retention-duration=1d

Anda juga dapat menonaktifkan retensi pesan yang dikonfirmasi untuk langganan dengan perintah update:

gcloud pubsub subscriptions update SUBSCRIPTION_ID --no-retain-acked-messages

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 Snapshots.

    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 Panduan untuk memberi nama topik, langganan, skema, atau snapshot.

  5. Klik Create untuk membuat snapshot.

Anda juga dapat membuat snapshot dari halaman Langganan. Jika membuat snapshot langsung setelah membuat langganan, Anda mungkin 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 akan menandai setiap pesan yang diterima oleh Pub/Sub sebelum waktu tersebut sebagai dikonfirmasi, dan semua pesan yang diterima setelah waktu tersebut sebagai tidak dikonfirmasi.

Anda dapat melakukan jenis operasi pencarian berikut berdasarkan stempel waktu:

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

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

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

  • Kemungkinan penyimpangan clock di antara server Pub/Sub.

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

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

Konsol

Untuk mencari stempel waktu, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Langganan.

    Buka Langganan

  2. Klik langganan yang telah 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 Telusuri.

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 Anda inginkan untuk melakukan operasi penelusuran.
  • SUBSCRIPTION_ID: ID langganan.

Untuk mengetahui informasi selengkapnya tentang format waktu yang didukung, lihat tanggal dan waktu topik gcloud.

Mencari snapshot

Anda dapat memutar ulang pesan yang tidak dikonfirmasi dengan menggunakan snapshot untuk mencari ke salah satu langganan topik.

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

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

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

Konsol

Untuk mencari snapshot, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Langganan.

    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 akan mengirim ulang pesan yang cocok dengan filter.

Ringkasan 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 akan mengirim ulang pesan dalam snapshot yang cocok dengan filter langganan yang membuat permintaan penelusuran.

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 menetapkan upaya pengiriman ke 0. Pesan yang Anda terima dari langganan ini memiliki kolom yang menghitung jumlah upaya pengiriman.

Untuk informasi selengkapnya tentang topik dead letter, lihat Mengirimkan ke topik dead letter.

Mencari dengan kebijakan percobaan ulang

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

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

Untuk 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 sekali, Pub/Sub akan mengirim ulang pesan yang sebelumnya dikonfirmasi dan memenuhi syarat untuk dikirim. Setiap konfirmasi, untuk pengiriman yang dilakukan sebelum operasi pencarian, akan gagal. Operasi pencarian pada akhirnya konsisten.

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