Ringkasan langganan

Untuk menerima pesan yang dipublikasikan ke suatu topik, Anda harus membuat langganan ke topik tersebut. Hanya pesan yang dipublikasikan ke topik setelah langganan dibuat yang tersedia untuk klien pelanggan. Klien pelanggan akan menerima dan memproses pesan yang dipublikasikan ke topik. Sebuah topik dapat memiliki beberapa langganan, tetapi satu langganan hanya dimiliki oleh satu topik.

Fitur retensi topik memungkinkan langganan yang dilampirkan ke topik untuk mencari kembali waktu dan memutar ulang pesan yang dipublikasikan sebelumnya. Anda dapat mempelajari lebih lanjut fitur ini di topik Memutar ulang dan menghapus pesan.

Alur kerja langganan

  1. Setelah pesan dikirim ke pelanggan, pelanggan harus mengonfirmasi pesan tersebut.

  2. Jika pesan dikirim untuk pengiriman dan pelanggan belum mengonfirmasinya, pesan tersebut disebut belum dikonfirmasi.

  3. Pub/Sub berulang kali mencoba mengirimkan pesan yang belum dikonfirmasi. Namun, Pub/Sub mencoba untuk tidak mengirimkan pesan yang belum terkirim ke pelanggan lain pada langganan yang sama.

  4. Pelanggan memiliki jangka waktu terbatas yang dapat dikonfigurasi, yang dikenal sebagai ackDeadline, untuk mengonfirmasi pesan yang belum dikonfirmasi. Setelah batas waktu terlewati, pesan tidak lagi dianggap belum terselesaikan, dan Pub/Sub mencoba mengirim ulang pesan.

Jenis langganan

Saat membuat langganan, Anda harus menentukan jenis pengiriman pesan. Pub/Sub menawarkan jenis langganan berikut:

  • Langganan pull menggunakan klien pelanggan untuk meminta pesan dari server Pub/Sub.

  • Langganan push menggunakan server Pub/Sub untuk menginisiasi permintaan ke aplikasi pelanggan Anda untuk mengirim pesan.

  • Ekspor langganan mengekspor pesan Anda langsung ke resource Cloud de Confiance by S3NS. Langganan ini mencakup:

    • Langganan BigQuery mengekspor data ke tabel BigQuery.

    • Langganan Cloud Storage mengekspor data ke bucket Cloud Storage.

Untuk memilih langganan yang tepat untuk persyaratan bisnis Anda, lihat Memilih jenis langganan. Anda dapat memperbarui jenis pengiriman pesan untuk langganan kapan saja setelah dibuat.

Properti langganan default

Secara default, Pub/Sub menawarkan pengiriman setidaknya sekali tanpa jaminan pengurutan pada semua jenis langganan. Atau, jika pesan memiliki kunci pengurutan yang sama dan berada di region yang sama, Anda dapat mengaktifkan pengurutan pesan. Setelah Anda menetapkan properti pengurutan pesan, layanan Pub/Sub akan mengirimkan pesan dengan kunci pengurutan yang sama dan sesuai urutan saat layanan Pub/Sub menerima pesan.

Pub/Sub juga mendukung pengiriman tepat satu kali.

Secara umum, Pub/Sub mengirimkan setiap pesan satu kali dan dalam urutan saat pesan tersebut dipublikasikan. Namun, terkadang pesan dapat dikirim tidak berurutan atau lebih dari sekali. Pub/Sub dapat mengirim ulang pesan meskipun setelah permintaan konfirmasi untuk pesan tersebut berhasil ditampilkan. Pengiriman ulang ini dapat disebabkan oleh masalah seperti memulai ulang sisi server atau masalah sisi klien. Oleh karena itu, meskipun jarang terjadi, pesan apa pun dapat dikirim ulang kapan saja.

Untuk mengakomodasi pengiriman lebih dari sekali, pelanggan Anda harus idempoten saat memproses pesan.

Masa berlaku langganan

Secara default, langganan berakhir setelah 31 hari pelanggan tidak aktif atau jika tidak ada update yang dilakukan pada langganan. Contoh aktivitas pelanggan mencakup koneksi terbuka, pull yang aktif, atau push yang berhasil dilakukan. Jika Pub/Sub mendeteksi aktivitas pelanggan atau pembaruan pada properti langganan, timer penghapusan langganan akan dimulai ulang. Dengan kebijakan masa berlaku langganan, Anda dapat mengonfigurasi durasi tidak aktif atau membuat langganan tetap ada terlepas dari aktivitas. Anda juga dapat menghapus langganan secara manual.

Meskipun Anda dapat membuat langganan baru dengan nama yang sama dengan langganan yang dihapus, langganan baru tidak memiliki hubungan dengan langganan lama. Meskipun langganan yang dihapus memiliki banyak pesan yang belum dikonfirmasi, langganan baru yang dibuat dengan nama yang sama tidak akan memiliki backlog (tidak ada pesan yang menunggu pengiriman) pada saat dibuat.

Langkah berikutnya