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 penelusuran

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 maksimum yang mungkin untuk snapshot adalah tujuh hari. Anda tidak dapat membuat snapshot yang akan berakhir dalam waktu kurang dari 1 jam setelah waktu pembuatannya.

Fitur penelusuran memungkinkan Anda menelusuri 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 waktu di masa lalu dan memutar ulang pesan yang telah dikonfirmasi sebelumnya, Anda harus mengonfigurasi retensi pesan di topik terlebih dahulu atau mengonfigurasi langganan untuk mempertahankan pesan yang telah dikonfirmasi.

Konsistensi tertunda operasi pencarian

Operasi penelusuran 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 diakui 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 berlaku sepenuhnya.

Kasus penggunaan untuk operasi penelusuran

• 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 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 yang besar dan 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.

Mengonfigurasi retensi pesan

Anda dapat mengonfigurasi retensi pesan pada topik dan mengonfigurasi langganan apa pun untuk mempertahankan pesan yang terkonfirmasi. Anda mungkin ingin mengonfigurasi retensi pesan topik jika Anda ingin pesan dipertahankan untuk diputar ulang selama durasi yang lebih lama daripada retensi pesan yang dikonfigurasi pada langganan. Dalam situasi ini, project topik dan project langganan dikenai biaya penyimpanan pesan sesuai dengan setelan retensi pesannya 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_durations topik dan langganan.

Mengonfigurasi retensi pesan topik

Secara default, topik Pub/Sub akan menghapus pesan segera setelah pesan tersebut dikonfirmasi oleh semua langganan yang terlampir pada topik. Mengonfigurasi topik dengan retensi pesan memberi Anda lebih banyak fleksibilitas, sehingga langganan apa pun yang dilampirkan ke topik dapat mencari kembali ke masa lalu dan memutar ulang pesan yang sebelumnya dikonfirmasi 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 selama maksimal 31 hari (dapat dikonfigurasi oleh properti message_retention_duration topik) bahkan setelah pesan tersebut dikonfirmasi oleh semua langganan yang terlampir. Jika message_retention_duration topik lebih besar daripada message_retention_duration langganan, Pub/Sub akan menghapus pesan hanya jika usia pesan tersebut melebihi message_retention_duration topik.

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

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

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

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 menghapus pesan dari langganan segera setelah pesan dikonfirmasi. Pesan yang tidak terkonfirmasi dipertahankan 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 terkonfirmasi yang dipertahankan oleh langganan. Anda dapat mengonfigurasi pesan agar dipertahankan selama maksimal 31 hari dalam langganan. Konfigurasi ini berlaku untuk pesan yang sudah dan belum dikonfirmasi.

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

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

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

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

Membuat snapshot

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

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

Mencari stempel waktu

Mencari ke waktu tertentu akan menandai setiap pesan yang diterima oleh Pub/Sub sebelum waktu tersebut sebagai telah dikonfirmasi, dan semua pesan yang diterima setelah waktu tersebut sebagai belum 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.

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

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

gcloud pubsub subscriptions seek SUBSCRIPTION_ID \
    --snapshot=SNAPSHOT_ID

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 coba lagi

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.