Memutar ulang dan menghapus permanen pesan dengan fitur cari

Setelah mengonfirmasi pesan di Pub/Sub, pesan ini tidak akan 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 telah dikonfirmasi sebelumnya atau menghapus permanen pesan secara massal. Selain itu, Anda dapat menyalin status konfirmasi dari satu langganan ke langganan lainnya menggunakan pencarian yang dikombinasikan dengan snapshot.

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

Ringkasan snapshot dan cari

Snapshot Pub/Sub adalah tampilan point-in-time yang tahan lama, konsisten, dan andal dari status konfirmasi pesan (ack) suatu langganan. Snapshot mencatat status konfirmasi semua pesan dalam langganan pada saat pembuatannya. Snapshot menyimpan pesan yang tidak dikonfirmasi dari langganan sumber pada saat pembuatan snapshot, dan setiap pesan yang dipublikasikan ke topik setelah snapshot dibuat.

Masa aktif snapshot ditentukan oleh backlog langganan sumber yang sudah ada. Masa aktif sama dengan 7 hari dikurangi usia pesan terlama yang tidak dikonfirmasi dalam langganan. Misalnya, lihat ringkasan langganan dengan backlog dengan pesan terlama yang tidak terkonfirmasi adalah 1 hari. Ringkasan tidak berlaku lagi setelah 6 hari. Linimasa ini diperlukan agar snapshot dapat menawarkan jaminan pengiriman yang kuat minimal satu kali.

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

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

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

Konsistensi tertunda dari operasi pencarian

Operasi pencarian sangat konsisten dalam hal jaminan pengiriman pesan. Artinya, setiap pesan yang tidak dikonfirmasi berdasarkan kondisi pencarian dijamin akan terkirim 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 akan dikirimkan setelah operasi pencarian. Dalam beberapa hal, pengiriman pesan beroperasi sebagai sistem yang konsisten pada akhirnya sehubungan dengan operasi pencarian; mungkin perlu waktu selama satu menit agar operasi berjalan sepenuhnya.

Kasus penggunaan untuk operasi pencarian

  • Memperbarui kode pelanggan dengan aman. Kekhawatiran saat men-deploy kode pelanggan baru adalah bahwa file baru yang dapat dieksekusi mungkin salah mengakui pesan, yang menyebabkan hilangnya pesan. Menyertakan snapshot ke dalam proses deployment akan memberi Anda cara untuk memulihkan diri dari bug dalam kode pelanggan baru.
  • Pulihkan 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 dikonfirmasi untuk langganan, mencari waktu di masa lalu akan memberi Anda cara untuk pulih dari error tersebut.
  • Menghemat waktu dan biaya pemrosesan. Lakukan konfirmasi massal pada backlog besar pesan yang tidak lagi relevan.
  • Uji kode pelanggan pada data yang diketahui. Saat menguji performa dan konsistensi kode pelanggan, sebaiknya gunakan data yang sama setiap kali dijalankan. 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 langganannya untuk mempertahankan pesan yang dikonfirmasi. Sebaiknya konfigurasi retensi pesan topik jika Anda ingin pesan dipertahankan untuk diputar ulang selama durasi yang lebih lama dari retensi pesan yang dikonfigurasi pada langganan. Dalam situasi ini, project topik dan project langganan akan dikenai biaya untuk penyimpanan pesan sesuai dengan setelan retensi pesannya masing-masing.

Jika retensi pesan topik tidak dikonfigurasi, pesan yang tidak dikonfirmasi akan dihapus dari langganan saat 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 batas maksimum topik dan message_retention_duration langganan.

Mengonfigurasi retensi pesan topik

Secara default, topik Pub/Sub akan menghapus pesan segera setelah pesan tersebut dikonfirmasi oleh semua langganan yang terkait dengan topik tersebut. Mengonfigurasi topik dengan retensi pesan akan memberi Anda fleksibilitas yang lebih besar, sehingga langganan apa pun yang terkait dengan topik dapat mencari mundur waktu dan memutar ulang pesan yang telah dikonfirmasi sebelumnya hingga message_retention_duration topik. Retensi pesan topik juga memungkinkan langganan untuk memutar ulang pesan yang dipublikasikan sebelum Anda membuat langganan.

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

Jika retensi pesan topik diaktifkan, biaya penyimpanan untuk pesan yang dipertahankan oleh topik akan ditagihkan 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 Tetapkan durasi retensi pesan.

    Biarkan opsi lain tetap di 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 selama 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 suatu topik dengan perintah update:

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

Mengonfigurasi retensi pesan langganan

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

Dengan mengonfigurasi langganan untuk mempertahankan pesan yang dikonfirmasi (menggunakan properti retain_acked_messages), Anda dapat memutar ulang pesan yang sebelumnya dikonfirmasi yang dipertahankan oleh langganan. Anda dapat mengonfigurasi pesan agar dipertahankan selama maksimum 7 hari dalam langganan. Konfigurasi ini berlaku untuk pesan yang dikonfirmasi dan tidak dikonfirmasi. Namun, pesan dapat dipertahankan dalam langganan selama lebih dari 7 hari jika durasi retensi pesan yang dikonfigurasi pada topiknya lebih dari 7 hari.

Jika langganan dikonfigurasi untuk mempertahankan pesan yang dikonfirmasi, biaya penyimpanan untuk pesan yang dikonfirmasi 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 ID Langganan, 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 lain tetap di setelan defaultnya.

  6. Klik Buat langganan untuk menyimpan langganan.

Untuk memperbarui setelan retensi pesan langganan:

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

    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 Pertahankan pesan yang dikonfirmasi.

  4. Klik Update untuk menyimpan perubahan pada langganan.

gcloud

Untuk membuat langganan dengan retensi pesan yang dikonfirmasi, 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 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 Memilih langganan Pub/Sub, pilih langganan.

  4. Untuk ID snapshot, masukkan nama untuk snapshot.

    Untuk mengetahui informasi lebih lanjut mengenai cara memberi nama resource Pub/Sub, baca Panduan untuk menamai topik, langganan, skema, atau snapshot.

  5. Klik Create untuk membuat snapshot.

Anda juga dapat membuat snapshot dari halaman Langganan.

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.

Cari ke stempel waktu

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

Anda dapat melakukan jenis operasi pencarian berikut berdasarkan stempel waktu:

  • Untuk menghapus permanen semua pesan, Anda dapat mencari waktu pada masa mendatang.

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

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

  • Kemungkinan clock biasing di antara server Pub/Sub.

  • Fakta bahwa Pub/Sub harus berfungsi dengan waktu kedatangan permintaan publikasi, bukan saat suatu 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 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 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 ke stempel waktu, gunakan perintah gcloud pubsub subscriptions seek berikut:

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

Ganti kode berikut:

  • TIME: waktu saat Anda ingin melakukan operasi pencarian.
  • SUBSCRIPTION_ID: ID langganan.

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

Cari ke snapshot

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

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

Jika backlog dalam langganan sudah terlalu lama dan snapshot yang dihasilkan akan habis masa berlakunya dalam waktu kurang dari 1 jam, operasi pencarian 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 Langganan.

    Buka Langganan

  2. Klik langganan.

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

  4. Untuk Seek, klik To a 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.

Cari 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 daripada snapshot, termasuk pesan yang tidak cocok dengan filter.
  • Pesan yang tidak dikonfirmasi 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 pencarian.

Untuk informasi lebih lanjut tentang filter, lihat Memfilter pesan.

Cari 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 yang dihentikan pengirimannya, lihat Meneruskan ke topik yang dihentikan pengirimannya.

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 akan berakhir atau pelanggan mengirimkan konfirmasi negatif.
  2. Pub/Sub mengirim ulang pesan.

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

Cari dengan pengiriman tepat satu kali

Jika Anda mencari pesan dalam langganan dengan pengiriman tepat satu kali, Pub/Sub akan mengirim ulang pesan yang telah dikonfirmasi sebelumnya dan memenuhi syarat untuk pengiriman. Setiap konfirmasi, untuk pengiriman yang dilakukan sebelum operasi pencarian, akan gagal. Operasi pencarian pada akhirnya akan konsisten.

Untuk mengetahui informasi selengkapnya tentang kebijakan percobaan ulang, lihat Hanya setelah dikirim.