Ringkasan layanan Pub/Sub

Pub/Sub adalah layanan publish/subscribe (Pub/Sub), layanan pesan yang memisahkan pengirim pesan dari penerima pesan. Ada beberapa konsep utama dalam layanan Pub/Sub yang dijelaskan dengan bantuan gambar berikut.

Gambar yang menunjukkan komponen layanan Pub/Sub yang berbeda dan cara keduanya terhubung satu sama lain.
Gambar 1 Dua klien penayang mengirim dua pesan yang berbeda ke topik Pub/Sub yang sama.

Berikut adalah komponen layanan Pub/Sub:

  • Penayang (juga disebut produser): membuat pesan dan mengirimkannya (menerbitkan) ke layanan pesan terkait topik yang ditentukan.

  • Pesan: data yang berpindah melalui layanan.

  • Topik: entitas bernama yang mewakili feed pesan.

  • Skema: entity bernama yang mengatur format data pesan Pub/Sub.

  • Langganan: entitas bernama yang mewakili minat untuk menerima pesan tentang topik tertentu.

  • Subscriber (juga disebut konsumen): menerima pesan di langganan yang ditentukan.

Prosedur berikut membahas alur kerja layanan Pub/Sub:

  1. Dua aplikasi penerbit, Publisher 1 dan Publisher 2, mengirim pesan ke satu topik Pub/Sub. Penayang 1 mengirim pesan A dan Penayang 2 mengirim pesan B.

  2. Topiknya sendiri disertakan pada dua langganan. Keduanya adalah Langganan 1 dan Langganan 2.

  3. Topik ini juga dilampirkan pada skema.

  4. Setiap langganan menerima salinan pesan A dan B dari topik.

  5. Langganan 1 terhubung ke dua aplikasi pelanggan, Pelanggan 1 dan Pelanggan 2. Kedua aplikasi pelanggan tersebut menerima subkumpulan pesan dari topik. Dalam contoh ini, Pelanggan 1 menerima pesan B, sementara Pelanggan 2 menerima pesan A dari topik.

  6. Langganan 2 hanya terhubung ke satu aplikasi pelanggan yang disebut Pelanggan 3. Dengan demikian, Pelanggan 3 menerima semua pesan dari topik.

Siklus proses pesan di Pub/Sub

Asumsikan bahwa ada satu klien penerbit yang terhubung ke sebuah topik. Topik ini memiliki satu langganan yang disertakan. Satu pelanggan terhubung ke langganan.

Gambar yang menunjukkan alur pesan dalam Pub/Sub.
Gambar 2 Pesan mengalir dari klien penayang ke klien pelanggan melalui Pub/Sub.

Langkah-langkah berikut menjelaskan alur pesan di Pub/Sub:

  1. Aplikasi penayang mengirim pesan ke topik Pub/Sub.

  2. Pesan ditulis ke penyimpanan.

  3. Selain menulis pesan ke penyimpanan, Pub/Sub mengirimkan pesan ke semua langganan topik yang terlampir.

    Dalam contoh ini, berupa langganan tunggal.

  4. Langganan mengirim pesan ke aplikasi pelanggan terlampir.

  5. Pelanggan mengirimkan konfirmasi ke Pub/Sub bahwa mereka telah memproses pesan.

    Setelah setidaknya satu pelanggan untuk setiap langganan mengonfirmasi pesan, Pub/Sub akan menghapus pesan tersebut dari penyimpanan.

Status pesan di Pub/Sub

Meskipun ada pesan yang belum terkirim kepada pelanggan, Pub/Sub akan mencoba untuk tidak mengirimkannya kepada pelanggan lain pada langganan yang sama. Pelanggan memiliki waktu terbatas yang dapat dikonfigurasi, yang dikenal sebagai ackDeadline, untuk mengonfirmasi pesan yang belum terkirim. Setelah batas waktu terlewati, pesan tidak akan lagi dianggap belum selesai, dan Pub/Sub akan mencoba mengirim ulang pesan tersebut.

Pesan dalam layanan Pub/Sub dapat memiliki tiga status:

  • Pesan yang dikonfirmasi (acked). Setelah memproses pesan yang dikirim dari topik ke langganan, aplikasi pelanggan akan mengirimkan konfirmasi kembali ke Pub/Sub. Jika semua langganan pada suatu topik telah mengonfirmasi pesan, pesan tersebut akan dihapus secara asinkron dari sumber pesan publikasi dan dari penyimpanan.

  • Pesan yang tidak dikonfirmasi (tidak dikonfirmasi). Jika Pub/Sub tidak menerima konfirmasi dalam batas waktu konfirmasi, pesan mungkin akan dikirim lebih dari sekali. Misalnya, pelanggan mungkin mengirim konfirmasi setelah batas waktu berakhir atau konfirmasi mungkin hilang karena masalah jaringan sementara. Pesan yang tidak dikonfirmasi akan terus dikirimkan hingga durasi retensi pesan berakhir sejak pesan dipublikasikan. Pada tahap ini, pesan akan kedaluwarsa.

  • Pesan yang dikonfirmasi secara negatif (disederhanakan). Mempersempit pesan dari pelanggan menyebabkan Pub/Sub langsung mengirim ulang pesan tersebut. Saat pelanggan mengambil pesan yang tidak valid atau tidak dapat memproses pesan, pelanggan akan membantu memastikan bahwa pesan tersebut tidak hilang dan pada akhirnya berhasil diproses. Anda dapat menggunakan modifyAckDeadline dengan nilai 0 untuk membuat camilan pesan.

Pilih pola publikasi dan berlangganan Pub/Sub

Jika ada beberapa klien penayang dan pelanggan, Anda juga harus memilih jenis arsitektur publikasi dan langganan yang ingin disiapkan.

Gambar yang menunjukkan pola publikasi dan langganan yang berbeda.
Gambar 3 Hubungan penayang-pelanggan dapat berupa many-to-one (fan-in), many-to-many (load-balanced), dan one-to-many (fan-out).

Beberapa pola berlangganan publikasi Pub/Sub yang didukung mencakup hal berikut:

  • Fan in (many-to-one). Dalam contoh ini, beberapa aplikasi penayang memublikasikan pesan ke satu topik. Satu topik ini dilampirkan pada satu langganan. Langganan tersebut kemudian terhubung ke satu aplikasi pelanggan yang menerima semua pesan yang dipublikasikan dari topik.

  • Beban seimbang (many-to-many). Dalam contoh ini, satu atau beberapa aplikasi penayang memublikasikan pesan ke satu topik. Satu topik ini terlampir pada satu langganan yang, pada akhirnya, terhubung ke beberapa aplikasi pelanggan. Setiap aplikasi pelanggan mendapatkan subset dari pesan yang dipublikasikan, dan tidak ada dua aplikasi pelanggan yang mendapatkan subset pesan yang sama. Dalam kasus load balancing ini, Anda menggunakan beberapa pelanggan untuk memproses pesan dalam skala besar. Jika perlu lebih banyak pesan yang didukung, Anda dapat menambah lebih banyak pelanggan untuk menerima pesan dari langganan yang sama.

  • Fan out (satu ke banyak). Dalam contoh ini, satu atau beberapa aplikasi penerbit memublikasikan pesan ke satu topik. Satu topik ini dilampirkan ke beberapa langganan. Setiap langganan terhubung ke satu aplikasi pelanggan. Setiap aplikasi pelanggan mendapatkan kumpulan pesan yang sama yang dipublikasikan dari topik. Jika topik memiliki beberapa langganan, setiap pesan harus dikirim ke pelanggan yang menerima pesan atas nama setiap langganan. Jika Anda perlu melakukan operasi data yang berbeda pada kumpulan pesan yang sama, fan-out adalah pilihan yang bagus. Anda juga dapat menambahkan beberapa pelanggan ke setiap langganan dan mendapatkan subset pesan yang di-load balanced untuk setiap pelanggan.

Pilih opsi konfigurasi Pub/Sub

Anda dapat mengonfigurasi lingkungan Pub/Sub menggunakan salah satu opsi berikut:

  • Konsol Google Cloud
  • Google Cloud CLI
  • Library Klien Cloud (library klien tingkat tinggi)
  • REST dan RPC API (library klien tingkat rendah)

Pilihan opsi konfigurasi Pub/Sub Anda bergantung pada kasus penggunaan Anda.

Jika Anda baru menggunakan Google Cloud Console dan ingin menguji Pub/Sub, gunakan konsol atau gcloud CLI.

Library klien tingkat tinggi direkomendasikan untuk kasus ketika Anda memerlukan throughput yang tinggi dan latensi rendah dengan overhead operasional dan biaya pemrosesan yang minimal. Secara default, library klien tingkat tinggi menggunakan StreamingPull API. Library klien tingkat tinggi berisi fungsi dan class bawaan yang menangani panggilan API dasar untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, serta fitur lainnya.

Library klien tingkat rendah adalah library gRPC yang dibuat secara otomatis dan berfungsi saat Anda menggunakan API layanan secara langsung.

Berikut adalah beberapa praktik terbaik untuk menggunakan library klien:

  • Pilih bahasa library klien yang tepat. Performa library klien Pub/Sub bervariasi menurut bahasa. Misalnya, library klien Java lebih efektif dalam meningkatkan skala secara vertikal dibandingkan library klien Python, dan dapat menangani throughput yang lebih besar. Java, C++, dan Go adalah bahasa yang lebih efisien dalam hal resource komputasi yang diperlukan untuk menangani pemuatan publikasi atau langganan.

  • Gunakan library klien versi terbaru. Library klien Pub/Sub terus diupdate dengan fitur baru dan perbaikan bug. Pastikan Anda menggunakan library klien versi terbaru untuk bahasa Anda.

  • Menggunakan kembali klien penayang. Saat memublikasikan pesan, akan lebih efisien untuk menggunakan kembali klien penayang yang sama, daripada membuat klien penayang baru untuk setiap permintaan publikasi. Hal ini karena permintaan publikasi pertama setelah membuat klien penayang baru memerlukan waktu untuk membuat koneksi yang sah. Dalam beberapa bahasa seperti Node yang tidak memiliki klien penayang eksplisit, gunakan kembali objek tempat Anda memanggil metode publikasi. Misalnya, di Node, simpan dan gunakan kembali objek topik.

Cara menyiapkan Pub/Sub

Berikut langkah-langkah tingkat atas untuk mengonfigurasi Pub/Sub:

  1. Buat atau pilih project Google Cloud tempat Anda dapat menyiapkan Pub/Sub.

  2. Aktifkan Pub/Sub API.

  3. Dapatkan peran dan izin yang diperlukan untuk menjalankan Pub/Sub.

  4. Membuat topik

  5. Jika struktur pesan sangat penting, tentukan skema untuk pesan Anda.

  6. Lampirkan skema ke topik.

  7. Konfigurasi klien penayang yang dapat memublikasikan pesan ke topik.

  8. Jika diperlukan, konfigurasikan opsi publikasi lanjutan seperti kontrol alur, pengiriman pesan batch, dan kontrol serentak.

  9. Pilih jenis langganan berdasarkan cara Anda ingin menerima pesan.

  10. Membuat langganan untuk topik yang dipilih.

  11. Konfigurasikan klien pelanggan yang dapat menerima pesan dari langganan.

  12. Jika diperlukan, konfigurasikan opsi pengiriman pesan lanjutan seperti pengiriman tepat satu kali, pengelolaan sewa, pengiriman berurutan, dan kontrol alur.

  13. Mulai publikasikan pesan dari klien penayang Anda ke topik.

  14. Secara bersamaan, siapkan klien pelanggan Anda untuk menerima dan memproses pesan ini.

Panduan untuk memberi nama topik, langganan, skema, atau snapshot

Nama resource Pub/Sub secara unik mengidentifikasi resource Pub/Sub, seperti topik, langganan, skema, atau snapshot. Nama resource harus sesuai dengan format berikut:

projects/project-identifier/collection/ID

  • project-identifier: Harus berupa project ID atau nomor project, yang tersedia di Konsol Google Cloud. Misalnya, my-cool-project adalah project ID. 123456789123 adalah nomor project.

  • collection: Harus salah satu dari topics, subscriptions, schemas, atau snapshots.

  • ID: Harus mematuhi panduan berikut:

    • Tidak diawali dengan string goog
    • Diawali dengan huruf
    • Berisi antara 3 hingga 255 karakter
    • Hanya berisi karakter berikut: Huruf [A-Za-z], angka [0-9], tanda hubung -, garis bawah _, titik ., tanda gelombang ~, tanda plus +, dan tanda persen %

    Anda dapat menggunakan karakter khusus dalam daftar sebelumnya dalam nama resource tanpa encoding URL. Namun, Anda harus memastikan bahwa karakter khusus lainnya dienkode atau didekode dengan benar saat Anda menggunakannya dalam URL. Misalnya, mi-tópico adalah ID yang tidak valid. Namun, mi-t%C3%B3pico valid. Format ini penting saat Anda melakukan panggilan REST.

Langkah selanjutnya