Dokumen ini mengasumsikan bahwa Anda sudah memahami proses berlangganan ke topik Pub/Sub dan menerima pesan di klien pelanggan Anda.
Jika Anda baru menggunakan Pub/Sub, lihat salah satu panduan Panduan memulai dan pelajari cara menjalankan Pub/Sub menggunakan konsol, Google Cloud 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 resourceCloud de Confiance by S3NS , 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 klien pelanggannya tidak mengetahui daftar langganan.
Untuk kasus umum, sebaiknya gunakan
library klien tingkat tinggi. Jika Anda
menggunakan pull unary, 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 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 saat Anda telah mengonfigurasi retensi pesan yang dikonfirmasi atau retensi topik dan Anda melakukan operasi pencarian.
Jika Anda memiliki pelanggan dengan latensi tinggi, Anda mungkin perlu menetapkan nilai kustom untuk kontrol alur dan pengelolaan sewa.
Mempertahankan ID pesan
Untuk mempermudah pemecahan masalah, penayang dan pelanggan harus mempertahankan ID pesan dari pesan yang dipublikasikan. Anda dapat menyimpan ID setiap pesan yang dipublikasikan atau mengaktifkan logging ID pesan sesuai kebutuhan. Menyimpan ID pesan akan memudahkan pemecahan masalah pesan duplikat, pengiriman ulang, kehilangan data, dan masalah umum lainnya. Untuk mengetahui informasi selengkapnya, lihat Menangani duplikat.
Mengonfigurasi kontrol alur pelanggan untuk lonjakan traffic sementara
Kontrol alur di sisi pelanggan memungkinkan Anda mencegah pelanggan kelebihan beban akibat lonjakan traffic. Hal ini dapat memberikan waktu bagi mekanisme penskalaan otomatis untuk merespons peningkatan beban atau dapat menyebarkan pemrosesan beban dalam 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 alur ini dan nama variabel mungkin berbeda di berbagai library klien.
Pesan yang belum terselesaikan maksimum menentukan jumlah maksimum pesan yang dikirim ke klien yang belum menerima konfirmasi atau konfirmasi negatif dari Pub/Sub.
Total byte pesan yang belum diproses 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 pesan lagi. Perilaku ini berlanjut hingga pesan yang sudah ditarik dikonfirmasi atau dikonfirmasi secara negatif. Dengan cara ini, Anda dapat menyeimbangkan throughput dengan biaya yang terkait dengan menjalankan lebih banyak pelanggan.
Menangani pengiriman duplikat
Secara default, Pub/Sub menyediakan pengiriman pesan minimal satu kali kepada pelanggan. Artinya, pesan dapat dikirim beberapa kali, meskipun sudah dikonfirmasi. Bagian berikut membahas cara mengatasi skenario pengiriman ulang yang umum.
Pengiriman ulang yang konsisten untuk banyak pesan
Jika Anda mengalami kasus di mana banyak pesan selalu dikirim ulang, berarti pelanggan Anda kelebihan beban atau mereka tidak mengonfirmasi pesan sebelum batas waktu berakhir.
Jika menggunakan langganan pull, Anda mungkin perlu menetapkan nilai kustom ke nilai kontrol alur atau meningkatkan periode perpanjangan sewa menggunakan pengelolaan sewa.
Jika menggunakan langganan push, Anda mungkin perlu meningkatkan setelan batas waktu konfirmasi. Anda juga dapat mengikuti praktik terbaik terkait cara mempertahankan langganan yang sehat.
Pengiriman ulang pesan sesekali
Saat Anda melihat pesan dikirim ulang sebelum batas waktu konfirmasi berlalu atau setelah pesan dikonfirmasi dalam beberapa detik, Pub/Sub berperilaku seperti yang diharapkan. Anda seharusnya tidak sering melihat lonjakan pengiriman ulang ini, tetapi jika pengiriman ulang terjadi, kemungkinan akan terjadi pada beberapa pesan secara bersamaan. Sistem Anda harus dibangun untuk menoleransi duplikat yang sesekali muncul ini.
Pengiriman ulang berulang untuk beberapa pesan
Jika Anda melihat sejumlah kecil pesan dikirim beberapa kali, pastikan terlebih dahulu bahwa Anda mengonfirmasi pesan tersebut. Jika tidak, cari tahu mengapa pelanggan Anda tidak menangani pesan dengan benar. Anda mungkin ingin mengonfigurasi topik yang dihentikan pengirimannya untuk mencegah pengiriman ulang lebih lanjut. Jika Anda mengonfirmasi pesan, Pub/Sub mungkin masih beroperasi seperti yang diharapkan. Meskipun sangat jarang, sejumlah kecil pesan masih mungkin dikirim beberapa kali jika terjadi gangguan jaringan atau hardware internal. Layanan akan mencoba melakukan perbaikan mandiri dalam kasus ini, tetapi perlu waktu beberapa menit agar perbaikan tersebut aktif.
Sistem Anda harus toleran terhadap pengiriman ulang. Anda dapat mengurangi kemungkinannya dengan memastikan Anda memproses dan mengonfirmasi pesan secepat mungkin.
Jika aplikasi Anda tidak dapat menoleransi duplikat, Anda dapat mengaktifkan pengiriman tepat satu kali. Ingat bahwa fitur ini hanya tersedia untuk langganan pull dan juga menghasilkan latensi publikasi ke langganan yang lebih tinggi. Evaluasi apakah konsekuensi latensi yang lebih tinggi dapat diterima untuk kasus penggunaan Anda sebelum mengaktifkan fitur ini.
Praktik terbaik untuk pesan berurutan 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 terselesaikan untuk setiap kunci pengurutan dalam satu waktu. Mengirim permintaan push paralel dalam skenario seperti 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 sering memublikasikan beberapa pesan dengan kunci pengurutan yang sama atau yang latensinya sangat penting.
Aktifkan pengurutan pesan di langganan. Di sisi penayang, jika Anda 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 pesan yang diurutkan. Bergantung pada status properti, setiap langganan yang dilampirkan ke topik dapat menentukan apakah langganan tersebut memerlukan pengiriman yang diurutkan tanpa saling memengaruhi.
Mengonfirmasi pesan secara berurutan. Saat menggunakan pengiriman yang diurutkan, konfirmasi untuk pesan berikutnya tidak akan 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 menerima semuanya, tetapi hanya mengonfirmasi pesan 3, layanan tidak akan 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 telah dikonfirmasi | Proses pesan sebelum Anda mengonfirmasinya. Atau, konfigurasikan untuk operasi pencarian agar Anda tidak kehilangan pesan yang telah dikonfirmasi. |
| Kontrol alur | Konfigurasikan kontrol alur di setelan pelanggan untuk memastikan pelanggan tidak kelebihan beban hingga penskalaan otomatis dimulai atau waktu berlalu. |
| Menangani pengiriman duplikat dan mempertahankan ID pesan | Pertahankan atau aktifkan logging messageId yang diterima untuk menyederhanakan pemecahan masalah duplikat, pengiriman ulang, dan pesan yang hilang. |
| Mengurutkan pesan | Saat menggunakan pesan yang diurutkan, pilih StreamingPull atau Pull, aktifkan pengurutan pesan dalam langganan, dan konfirmasi pesan secara berurutan. |