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 menerima dan memproses pesan yang dipublikasikan ke topik. Sebuah topik dapat memiliki beberapa langganan, tetapi langganan tertentu termasuk dalam satu topik.

Fitur retensi topik memungkinkan langganan yang terkait ke suatu topik untuk menelusuri waktu dan memutar ulang pesan yang dipublikasikan sebelumnya. Anda dapat mempelajari fitur ini lebih lanjut dengan topik Memutar ulang dan menghapus permanen pesan.

Alur kerja langganan

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

  2. Jika pesan dikirim untuk dikirim dan pelanggan belum mengonfirmasinya, pesan akan disebut sebagai "tunggal".

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

  4. Pelanggan memiliki waktu terbatas yang dapat dikonfigurasi, yang dikenal sebagai ackDeadline, untuk mengonfirmasi pesan yang belum diterima. Setelah batas waktu lewat, pesan tidak lagi dianggap belum selesai, dan Pub/Sub akan berupaya mengirim ulang pesan tersebut.

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 memulai permintaan ke aplikasi pelanggan Anda untuk mengirim pesan.

  • Ekspor langganan membantu Anda mengekspor pesan langsung ke resource Google Cloud. Langganan ini meliputi:

    • Langganan BigQuery mengekspor data ke tabel BigQuery.

    • Langganan Cloud Storage mengekspor data ke bucket Cloud Storage.

Untuk memilih langganan yang benar bagi 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 minimal satu kali tanpa jaminan pemesanan di 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 dalam urutan yang diterima layanan Pub/Sub.

Pub/Sub juga mendukung pengiriman tepat satu kali.

Secara umum, Pub/Sub mengirimkan setiap pesan satu kali dan sesuai urutan publikasinya. Namun, pesan terkadang dapat dikirim secara tidak berurutan atau lebih dari sekali. Pub/Sub mungkin akan mengirim ulang pesan bahkan setelah permintaan konfirmasi agar pesan berhasil ditampilkan. Pengiriman ulang ini dapat disebabkan oleh masalah seperti mulai ulang sisi server atau masalah sisi klien. Jadi, meskipun jarang terjadi, pesan apa pun dapat dikirimkan ulang kapan saja.

Mengakomodasi pengiriman lebih dari satu kali mengharuskan pelanggan Anda menjadi idempoten saat memproses pesan.

Masa berlaku langganan

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

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

Langkah selanjutnya