Dokumen ini mengasumsikan bahwa Anda sudah memahami proses berlangganan topik Pub/Sub dan menerima pesan di klien pelanggan.
Jika Anda baru menggunakan Pub/Sub, baca salah satu Panduan memulai dan pelajari cara menjalankan Pub/Sub menggunakan konsol, gCloud CLI, atau library klien.
Memilih langganan yang tepat
Pub/Sub menawarkan langganan standar, seperti langganan push dan pull. Selain langganan standar, Pub/Sub juga menawarkan langganan ekspor yang memungkinkan Anda menyimpan pesan langsung ke resource Google Cloud, tanpa memerlukan Dataflow sebagai perantara. Misalnya, langganan BigQuery menyimpan pesan dalam tabel BigQuery.
Langganan push direkomendasikan untuk skenario berikut:
Anda tidak dapat menyertakan kode apa pun dalam aplikasi pelanggan yang mengimpor library klien sebagai dependensi.
Klien pelanggan tidak dapat membuat permintaan keluar.
Anda ingin menggunakan instance yang sama untuk memproses pesan dari berbagai topik dan langganan yang daftar langganannya tidak diketahui oleh klien pelanggan.
Untuk kasus umum, sebaiknya gunakan
library klien tingkat tinggi. Jika Anda
menggunakan unary pull, jangan tetapkan
returnImmediately
ke true. Menyetelnya ke true akan berdampak buruk pada performa pull.
Kolom returnImmediately kini tidak digunakan lagi.
Untuk membandingkan semua jenis langganan dan memilih yang paling sesuai dengan kebutuhan bisnis Anda, lihat tabel perbandingan langganan Pub/Sub.
Untuk mempelajari manfaat langganan ekspor, lihat Kapan harus menggunakan langganan ekspor.
Memproses pesan sebelum mengonfirmasinya
Secara default, Pub/Sub akan menghapus pesan dari langganan setelah pesan dikonfirmasi. Jika Anda tidak memproses pesan sebelum mengirim konfirmasi dan pemrosesan gagal, layanan tidak akan mengirim ulang pesan. Pengecualiannya adalah jika Anda telah mengonfigurasi mempertahankan pesan atau retensi topik yang dikonfirmasi, dan melakukan operasi pencarian.
Jika memiliki pelanggan berlatensi tinggi, Anda mungkin perlu menetapkan nilai kustom untuk kontrol alur dan pengelolaan sewa.
Konfigurasi kontrol alur pelanggan untuk lonjakan traffic sementara
Dengan kontrol alur di sisi pelanggan, Anda dapat mencegah pelanggan kelebihan beban oleh lonjakan traffic. Hal ini dapat memberikan waktu bagi mekanisme penskalaan otomatis untuk merespons beban yang meningkat atau dapat menyebarkan pemrosesan beban dalam jangka waktu yang lebih lama. Metode pertama menghemat latensi, sedangkan metode yang kedua menghemat biaya.
Untuk mengonfigurasi kontrol alur, Anda harus menetapkan
nilai yang sesuai untuk maximum outstanding messages dan
total outstanding message bytes. Nilai default untuk variabel kontrol alur ini dan nama variabel tersebut mungkin berbeda di berbagai library klien.
Pesan maksimum yang belum terselesaikan menentukan jumlah maksimum pesan yang dikirim ke klien yang belum diterima oleh Pub/Sub atau konfirmasi negatif.
Total byte pesan yang belum diproses menentukan total ukuran maksimum pesan yang dikirim ke klien yang mana Pub/Sub belum menerima konfirmasi atau konfirmasi negatif.
Jika batas untuk salah satu opsi ini terlampaui, klien pelanggan tidak akan menarik lebih banyak pesan. Perilaku ini berlanjut sampai pesan yang sudah ditarik dikonfirmasi atau diakui secara negatif. Dengan cara ini, Anda dapat mengorbankan throughput dengan biaya yang diperlukan untuk menjalankan lebih banyak pelanggan.
Praktik terbaik untuk pesan yang diurutkan dalam berlangganan
Jika Anda menggunakan pengurutan pesan, pastikan hal berikut:
Pilih langganan StreamingPull atau Pull. Untuk langganan push, Pub/Sub hanya mendukung satu pesan yang belum diproses untuk setiap kunci pengurutan pada satu waktu. Mengirim permintaan push paralel dalam skenario semacam itu akan mirip dengan mengirim beberapa batch pesan untuk kunci pengurutan yang sama guna menarik pelanggan secara bersamaan. Oleh karena itu, langganan push tidak direkomendasikan untuk topik yang beberapa pesannya sering dipublikasikan dengan kunci pengurutan yang sama atau ketika latensi sangat penting.
Mengaktifkan pengurutan pesan dalam langganan. Di sisi penayang, jika mengirim pesan dengan kunci pengurutan dan di region yang sama, Anda dapat mengonfigurasi pelanggan untuk menerima pesan tersebut secara berurutan. Di sisi pelanggan, aktifkan properti pengurutan pesan hanya untuk langganan yang ingin Anda terima pesannya. Bergantung pada status properti, setiap langganan yang terkait dengan topik dapat menentukan apakah mereka memerlukan pengiriman yang dipesan tanpa saling memengaruhi.
Mengonfirmasi pesan secara berurutan. Saat menggunakan pengiriman yang dipesan, konfirmasi untuk pesan berikutnya tidak akan diproses hingga konfirmasi untuk pesan sebelumnya diproses per kunci pemesanan. Misalnya, jika Anda memiliki pesan 1, 2, dan 3 dengan kunci pengurutan yang sama dan Anda menerima semuanya serta hanya mengonfirmasi pesan 3, layanan tidak akan menganggap pesan 3 telah dikonfirmasi hingga pesan 1 dan 2 juga dikonfirmasi. Jika konfirmasi untuk pesan 1 dan 2 tidak pernah diterima, maka pesan 1, 2, dan 3 akan dikirim ulang.
Ringkasan praktik terbaik
Tabel berikut merangkum praktik terbaik yang direkomendasikan dalam dokumen ini:
| Topik | Tugas |
|---|---|
| Memilih jenis langganan | Pilih jenis langganan yang tepat untuk kebutuhan bisnis Anda. Jika didukung oleh langganan Anda, gunakan juga library klien level tinggi. |
| Memutar ulang pesan yang dikonfirmasi | Proses pesan sebelum Anda mengonfirmasinya. Atau, konfigurasikan operasi pencarian agar Anda tidak kehilangan pesan yang dikonfirmasi. |
| Kontrol alur | Konfigurasikan kontrol alur di setelan pelanggan Anda untuk memastikan pelanggan tidak kelebihan beban hingga penskalaan otomatis dimulai atau waktu berlalu. |
| Mengurutkan pesan | Saat menggunakan pesan berurutan, pilih StreamingPull atau Pull, aktifkan pengurutan pesan dalam langganan, dan konfirmasi pesan secara berurutan. |