Ringkasan layanan Pub/Sub

Pub/Sub adalah layanan publikasi/langganan (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 terhubungnya 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:

  • Penerbit (juga disebut pembuat pesan): membuat pesan dan mengirim (memublikasikan) pesan tersebut ke layanan pesan pada topik yang ditentukan.

  • 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 yang ditentukan.

Prosedur berikut membahas alur kerja layanan Pub/Sub:

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

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

  3. Topik juga dilampirkan ke 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. Dua aplikasi pelanggan menerima sebagian pesan dari topik. Dalam contoh ini, Pelanggan 1 menerima pesan B, sedangkan Pelanggan 2 menerima pesan A dari topik.

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

Masa berlaku pesan

Asumsikan bahwa satu klien penayang terhubung ke suatu topik. Topik memiliki satu langganan yang terpasang. 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. Bersama dengan menulis pesan ke penyimpanan, Pub/Sub mengirimkan pesan ke semua langganan topik yang terlampir.

    Dalam contoh ini, atribut berisi 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

Meskipun pesan belum terkirim kepada pelanggan, Pub/Sub tidak akan mencoba mengirimkannya kepada pelanggan lain di langganan yang sama. 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 tersedia untuk dikirimkan lagi.

Ada tiga status untuk pesan di layanan Pub/Sub:

  • Pesan yang dikonfirmasi (di-ack). Setelah aplikasi pelanggan memproses pesan yang dikirim dari topik ke langganan, aplikasi akan mengirimkan konfirmasi kembali ke Pub/Sub. Jika semua langganan di topik telah mengonfirmasi pesan, pesan 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 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, masa berlaku pesan akan berakhir.

  • Pesan yang ditolak (nacked). Meng-nack pesan oleh pelanggan akan menyebabkan Pub/Sub segera mengirimkan ulang pesan tersebut. Saat subscriber menolak pesan yang tidak valid atau saat tidak dapat memproses pesan, subscriber akan membantu memastikan bahwa pesan ini tidak hilang dan pada akhirnya berhasil diproses. Anda dapat menggunakan modifyAckDeadline dengan nilai 0 untuk menolak pesan.

Memilih pola publikasi dan langganan Pub/Sub

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

Gambar yang menunjukkan berbagai pola publikasi dan langganan.
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 subscribe publikasi Pub/Sub yang didukung mencakup hal berikut:

  • Fan in (banyak ke satu). Dalam contoh ini, beberapa aplikasi penayang memublikasikan pesan ke satu topik. Satu topik ini dilampirkan ke satu langganan. Langganan ini kemudian terhubung ke satu aplikasi pelanggan yang mendapatkan semua pesan yang dipublikasikan dari topik.

  • Load balancing (banyak ke banyak). Dalam contoh ini, satu atau beberapa aplikasi penerbit memublikasikan pesan ke satu topik. Satu topik ini disertakan ke satu langganan yang pada akhirnya 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 subscriber untuk memproses pesan dalam skala besar. Jika lebih banyak pesan 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 operasi data yang berbeda 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 diseimbangkan beban untuk setiap pelanggan.

Memilih 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 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 yang mendasarinya untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, dan fitur lainnya.

Library klien tingkat rendah adalah library gRPC yang dihasilkan secara otomatis dan digunakan 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 library klien versi terbaru untuk bahasa Anda.

  • Gunakan 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 beberapa saat untuk membuat koneksi yang diotorisasi. 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 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. Konfigurasikan klien penayang yang dapat memublikasikan pesan ke topik.

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

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

  10. Buat 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 sekali, pengelolaan sewa, pengiriman yang diurutkan, dan kontrol alur.

  13. Mulai memublikasikan pesan dari klien penayang ke topik.

  14. Secara bersamaan, siapkan klien pelanggan 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 berupa 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 ., tilde ~, tanda tambah +, 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