Ringkasan layanan Pub/Sub

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.

Gambar yang menunjukkan berbagai komponen layanan Pub/Sub dan cara komponen tersebut terhubung satu sama lain.
Gambar 1 Dua klien publisher mengirimkan dua pesan berbeda ke topik Pub/Sub yang sama.

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:

  1. 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.

  2. Topik itu sendiri terpasang ke dua langganan. Langganan tersebut adalah Subscription 1 dan Subscription 2.

  3. Topik juga dilampirkan ke skema.

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

  5. 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 pesan B, sedangkan Subscriber 2 menerima pesan A dari topik.

  6. 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.

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

Langkah-langkah berikut menjelaskan cara pesan mengalir di Pub/Sub:

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

  2. Pesan ditulis ke penyimpanan.

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

    Dalam contoh ini, ini adalah satu langganan.

  4. Langganan mengirimkan pesan ke aplikasi pelanggan yang 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 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 diproses. 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 mengirim 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.

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

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 terpasang 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 akan 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 lebih banyak pesan yang perlu didukung, Anda dapat menambahkan lebih banyak subscriber untuk menerima pesan dari langganan yang sama.

  • Sebarkan (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 set 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.

Memilih opsi konfigurasi Pub/Sub

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

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

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

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

Library klien tingkat tinggi direkomendasikan untuk kasus saat Anda memerlukan throughput 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 pokok untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, dan fitur lainnya.

Library klien tingkat rendah adalah library gRPC yang dibuat secara otomatis dan berperan 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 menskalakan secara vertikal daripada library klien Python, dan dapat menangani lebih banyak throughput. Java, C++, dan Go adalah bahasa yang lebih efisien dalam hal resource komputasi yang diperlukan untuk menangani beban publikasi atau langganan.

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

  • Menggunakan kembali klien penayang. Saat memublikasikan pesan, akan lebih efisien jika menggunakan kembali klien penayang yang sama, bukan 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 publish. Misalnya, di Node, simpan dan gunakan kembali objek topik.

Cara menyiapkan Pub/Sub

Berikut adalah langkah-langkah tingkat teratas 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 penerbit 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. Buat langganan untuk topik yang dipilih.

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

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

  13. Mulai publikasikan pesan dari klien penerbit 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 dari 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 sesuai dengan 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 ., tilde ~, tanda tambah +, dan tanda persen %

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

Langkah berikutnya