Dokumen ini mengasumsikan bahwa Anda sudah memahami proses berlangganan topik Pub/Sub dan menerima pesan di klien pelanggan.
Jika Anda baru menggunakan Pub/Sub, lihat 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, dengan klien pelanggan tidak mengetahui daftar langganan.
Untuk kasus umum, sebaiknya gunakan
library klien tingkat tinggi. Jika Anda
menggunakan pull unary, jangan tetapkan
returnImmediately
ke true. Menetapkan ke true akan berdampak negatif pada performa pull.
Kolom returnImmediately kini tidak digunakan lagi.
Untuk membandingkan semua jenis langganan dan memilih langganan 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 laporan dan pemrosesan gagal, layanan tidak akan mengirim ulang pesan. Pengecualian adalah jika Anda telah mengonfigurasi retensi pesan yang dikonfirmasi atau retensi topik dan Anda melakukan operasi penelusuran.
Jika memiliki pelanggan dengan latensi tinggi, Anda mungkin perlu menetapkan nilai kustom untuk kontrol alur dan pengelolaan sewa.
Mengonfigurasi kontrol alur pelanggan untuk lonjakan traffic sementara
Kontrol alur di sisi pelanggan memungkinkan Anda mencegah pelanggan dibebani oleh lonjakan traffic. Hal ini dapat memberi waktu bagi mekanisme penskalaan otomatis untuk merespons peningkatan beban atau dapat menyebarkan pemrosesan beban selama jangka waktu yang lebih lama. Metode pertama menghemat latensi, sedangkan metode 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
aliran ini dan nama variabel mungkin berbeda di seluruh library klien.
Pesan tertunda maksimum menentukan jumlah maksimum pesan yang dikirim ke klien yang belum menerima konfirmasi atau konfirmasi negatif dari Pub/Sub.
Total byte pesan yang belum terkirim menentukan ukuran total maksimum pesan yang dikirim ke klien yang belum menerima konfirmasi atau konfirmasi negatif dari Pub/Sub.
Jika batas untuk salah satu opsi ini terlampaui, klien pelanggan tidak akan mengambil lebih banyak pesan. Perilaku ini berlanjut hingga pesan yang sudah ditarik dikonfirmasi atau dikonfirmasi secara negatif. Dengan cara ini, Anda dapat mengorbankan throughput dengan biaya yang terkait dengan menjalankan lebih banyak subscriber.
Praktik terbaik untuk pesan terurut 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 terkirim untuk setiap kunci pengurutan dalam satu waktu. Mengirim permintaan push paralel dalam skenario tersebut akan mirip dengan mengirim beberapa batch pesan untuk kunci pengurutan yang sama guna menarik subscriber secara bersamaan. Oleh karena itu, langganan push tidak direkomendasikan untuk topik yang memiliki beberapa pesan yang sering dipublikasikan dengan kunci pengurutan yang sama atau jika latensi sangat penting.
Aktifkan pengurutan pesan di langganan. Di sisi penayang, jika mengirim pesan dengan kunci pengurutan dan di wilayah 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 pesan urutannya. Bergantung pada status properti, setiap langganan yang dilampirkan ke topik dapat menentukan apakah langganan tersebut memerlukan pengiriman yang diurutkan tanpa memengaruhi satu sama lain.
Mengonfirmasi pesan secara berurutan. Saat menggunakan pengiriman yang diurutkan, konfirmasi untuk pesan berikutnya tidak diproses hingga konfirmasi untuk pesan sebelumnya diproses per kunci pengurutan. Misalnya, jika Anda memiliki pesan 1, 2, dan 3 dengan kunci pengurutan yang sama dan Anda menerimanya semuanya dan hanya mengonfirmasi pesan 3, layanan tidak menganggap pesan 3 sebagai dikonfirmasi hingga pesan 1 dan 2 juga dikonfirmasi. Jika konfirmasi untuk pesan 1 dan 2 tidak pernah diterima, pesan 1, 2, dan 3 akan dikirim ulang.
Ringkasan praktik terbaik
Tabel berikut meringkas 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 tingkat tinggi. |
| Memutar ulang pesan yang dikonfirmasi | Memproses pesan sebelum Anda mengonfirmasinya. Atau, konfigurasikan untuk operasi pencarian agar Anda tidak kehilangan pesan yang terkonfirmasi. |
| Kontrol alur | Konfigurasikan kontrol alur di setelan pelanggan untuk memastikan bahwa pelanggan tidak kelebihan beban hingga penskalaan otomatis diterapkan atau waktu berlalu. |
| Mengurutkan pesan | Saat menggunakan pesan urut, pilih StreamingPull atau Pull, aktifkan urutan pesan dalam langganan, dan konfirmasi pesan secara berurutan. |