Pub/Sub adalah layanan publish/subscribe (Pub/Sub), yaitu layanan pesan yang memisahkan pengirim pesan dari penerima pesan. Ada beberapa konsep utama dalam layanan Pub/Sub yang dijelaskan dengan bantuan gambar berikut.
Berikut adalah komponen layanan Pub/Sub:
Penerbit (juga disebut produsen): membuat pesan dan mengirimkannya (memublikasikan) ke layanan perpesanan pada topik tertentu.
Pesan: data yang bergerak melalui layanan.
Topik: entitas bernama yang mewakili feed pesan.
Skema: entitas bernama yang mengatur format data pesan Pub/Sub.
Langganan: entitas bernama yang mewakili minat untuk menerima pesan tentang topik tertentu.
Pelanggan (juga disebut konsumen): menerima pesan di langganan tertentu.
Prosedur berikut membahas alur kerja layanan Pub/Sub:
Dua aplikasi penerbit, Publisher 1 dan Publisher 2, mengirim pesan ke satu topik Pub/Sub. Publisher 1 mengirim pesan A dan Publisher 2 mengirim pesan B.
Topik itu sendiri terpasang ke dua langganan. Langganan tersebut adalah Subscription 1 dan Subscription 2.
Topik juga dilampirkan ke skema.
Setiap langganan menerima salinan pesan A dan B dari topik.
Subscription 1 terhubung ke dua aplikasi pelanggan, Subscriber 1 dan Subscriber 2. Kedua aplikasi pelanggan menerima sebagian pesan dari topik. Dalam contoh ini, Subscriber 1 menerima message B, sedangkan Subscriber 2 menerima message A dari topik.
Subscription 2 hanya terhubung ke satu aplikasi subscriber yang disebut Subscriber 3. Dengan demikian, Subscriber 3 menerima semua pesan dari topik.
Masa aktif pesan
Asumsikan bahwa satu klien penayang terhubung ke topik. Topik memiliki satu langganan yang terpasang padanya. Satu pelanggan terhubung ke langganan.
Langkah-langkah berikut menjelaskan cara alur pesan di Pub/Sub:
Aplikasi penerbit mengirim pesan ke topik Pub/Sub.
Pesan ditulis ke penyimpanan.
Selain menulis pesan ke penyimpanan, Pub/Sub mengirimkan pesan ke semua langganan yang terlampir pada topik.
Dalam contoh ini, langganannya adalah langganan tunggal.
Langganan mengirimkan pesan ke aplikasi pelanggan yang terlampir.
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 dari penyimpanan.
Status pesan di Pub/Sub
Selama pesan belum dikirim ke pelanggan, Pub/Sub tidak akan mencoba mengirimkannya ke 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 lagi dianggap belum terkirim, dan tersedia untuk pengiriman lagi.
Ada tiga status untuk pesan dalam layanan Pub/Sub:
Pesan yang dikonfirmasi (acked). Setelah aplikasi pelanggan memproses pesan yang dikirim dari topik ke langganan, aplikasi tersebut akan mengirimkan konfirmasi kembali ke Pub/Sub. Jika semua langganan pada topik telah mengonfirmasi pesan, pesan akan dihapus secara asinkron dari sumber pesan publikasi dan dari penyimpanan.
Pesan yang belum dikonfirmasi (unacked). Jika Pub/Sub tidak menerima konfirmasi dalam batas waktu konfirmasi, pesan mungkin dikirimkan lebih dari sekali. Misalnya, pelanggan dapat mengirimkan konfirmasi setelah batas waktu berakhir atau konfirmasi dapat hilang karena masalah jaringan sementara. Pesan yang belum dikonfirmasi akan terus dikirimkan hingga durasi retensi pesan berakhir sejak pesan dipublikasikan. Pada tahap ini, pesan akan berakhir.
Pesan yang diakui secara negatif (nacked). Penolakan pesan oleh pelanggan menyebabkan Pub/Sub segera mengirim ulang pesan berdasarkan setelan percobaan ulang default, yang dapat diubah. Saat menolak pesan yang tidak valid atau saat tidak dapat memproses pesan, pelanggan membantu memastikan bahwa pesan ini tidak hilang dan berhasil diproses. Anda dapat menggunakan modifyAckDeadline dengan nilai 0 untuk menolak pesan.
Memilih pola publikasi dan langganan Pub/Sub
Jika ada beberapa klien penerbit dan pelanggan Pub/Sub, Anda juga harus memilih jenis arsitektur publikasi dan langganan yang ingin disiapkan.
Beberapa pola publish-subscribe Pub/Sub yang didukung meliputi:
Fan in (many-to-one). Dalam contoh ini, beberapa aplikasi penayang memublikasikan pesan ke satu topik. Satu topik ini dilampirkan ke satu langganan. Langganan ini, pada gilirannya, terhubung ke satu aplikasi pelanggan yang mendapatkan semua pesan yang dipublikasikan dari topik.
Load balanced (many-to-many). Dalam contoh ini, satu atau beberapa aplikasi penerbit memublikasikan pesan ke satu topik. Satu topik ini dilampirkan ke satu langganan yang, pada gilirannya, terhubung ke beberapa aplikasi subscriber. Setiap aplikasi pelanggan mendapatkan subset 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 ada lebih banyak pesan yang perlu didukung, Anda dapat menambahkan lebih banyak subscriber untuk menerima pesan dari langganan yang sama.
Fan out (satu ke banyak). Dalam contoh ini, satu atau beberapa aplikasi penayang 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 dipublikasikan yang sama dari topik. Jika topik memiliki beberapa langganan, setiap pesan harus dikirim ke pelanggan yang menerima pesan atas nama setiap langganan. Jika Anda perlu melakukan berbagai operasi data pada kumpulan pesan yang sama, fan out adalah opsi yang baik. Anda juga dapat melampirkan beberapa pelanggan ke setiap langganan dan mendapatkan subset pesan yang seimbang untuk setiap pelanggan.