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 dalam waktu dan memutar ulang pesan yang dipublikasikan sebelumnya. Anda dapat mempelajari fitur ini lebih lanjut dalam 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 dikirimkan dan pelanggan belum mengonfirmasinya, pesan tersebut disebut belum terkirim.

  3. Pub/Sub berulang kali mencoba mengirimkan pesan apa pun yang belum dikonfirmasi. Namun, Pub/Sub mencoba untuk tidak mengirimkan pesan yang belum terkirim kepada pelanggan lain di langganan yang sama.

  4. Pelanggan memiliki jumlah waktu terbatas yang dapat dikonfigurasi, yang dikenal sebagai ackDeadline, untuk mengonfirmasi pesan yang belum terkirim. Setelah batas waktu berlalu, pesan tidak lagi dianggap tertunda, dan Pub/Sub akan 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 memulai permintaan ke aplikasi pelanggan Anda guna mengirimkan pesan.

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

    • Langganan BigQuery mengekspor data ke tabel BigQuery.

    • Langganan Cloud Storage mengekspor data ke bucket Cloud Storage.

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

Properti langganan default

Secara default, Pub/Sub menawarkan pengiriman minimal satu kali tanpa jaminan urutan 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 layanan Pub/Sub menerima pesan.

Pub/Sub juga mendukung pengiriman tepat satu kali.

Secara umum, Pub/Sub mengirimkan setiap pesan sekali dan dalam urutan publikasinya. Namun, pesan terkadang mungkin dikirim secara acak atau lebih dari sekali. Pub/Sub mungkin mengirim ulang pesan bahkan setelah permintaan konfirmasi untuk pesan berhasil ditampilkan. Pengiriman ulang ini dapat disebabkan oleh masalah seperti mulai ulang sisi server atau masalah sisi klien. Dengan demikian, meskipun jarang terjadi, pesan apa pun dapat dikirim ulang kapan saja.

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

Akhir masa berlaku langganan

Secara default, langganan akan berakhir setelah 31 hari tidak ada aktivitas pelanggan atau jika tidak ada pembaruan yang dilakukan pada langganan. Contoh aktivitas pelanggan meliputi koneksi terbuka, pull yang aktif, atau push yang berhasil dilakukan. 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 aktif, terlepas dari aktivitasnya. 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 tidak terkonfirmasi, langganan baru yang dibuat dengan nama yang sama tidak akan memiliki backlog (tidak ada pesan yang menunggu pengiriman) pada saat dibuat.

Langkah selanjutnya