Praktik terbaik untuk berlangganan topik Pub/Sub

Saat berlangganan, klien pelanggan menerima pesan dari topik Pub/Sub. Berikut beberapa praktik terbaik untuk berlangganan Pub/Sub.

Dokumen ini mengasumsikan bahwa Anda sudah memahami proses berlangganan ke topik Pub/Sub dan menerima pesan di klien pelanggan.

Jika Anda baru menggunakan Pub/Sub, lihat salah satu panduan Memulai Cepat 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 resourceGoogle Cloud , tanpa memerlukan Dataflow sebagai perantara. Misalnya, langganan BigQuery menyimpan pesan dalam tabel BigQuery.

Sebaiknya gunakan langganan push untuk skenario berikut:

  • Anda tidak dapat menyertakan kode apa pun di aplikasi pelanggan yang mengimpor library klien sebagai dependensi.

  • Klien subscriber tidak dapat membuat permintaan keluar.

  • Anda ingin menggunakan instance yang sama untuk memproses pesan dari topik dan langganan yang berbeda, tempat klien pelanggan tidak mengetahui daftar langganan.

Untuk kasus umum, sebaiknya gunakan library klien tingkat tinggi. Jika Anda menggunakan penarikan unary, jangan tetapkan returnImmediately ke true. Menyetelnya ke true akan berdampak buruk pada performa penarikan. Kolom returnImmediately kini tidak digunakan lagi.

Memproses pesan sebelum mengonfirmasinya

Secara default, Pub/Sub menghapus pesan dari langganan setelah pesan dikonfirmasi. Jika Anda tidak memproses pesan sebelum mengirimkan konfirmasi dan pemrosesan gagal, layanan tidak akan mengirim ulang pesan. Pengecualiannya adalah jika Anda telah mengonfigurasi retensi pesan yang telah dibaca atau retensi topik dan Anda melakukan operasi pencarian.

Jika memiliki pelanggan dengan latensi tinggi, Anda mungkin perlu menetapkan nilai kustom untuk kontrol alur dan pengelolaan sewa.

Mengonfigurasi kontrol aliran 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 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 alur ini dan nama variabel mungkin berbeda di seluruh library klien.

  • Pesan yang belum diproses 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 menarik pesan lainnya. 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 subscriber.

Menangani pengiriman duplikat

Secara default, Pub/Sub menyediakan pengiriman pesan minimal satu kali kepada pelanggan. Artinya, pesan dapat dikirim beberapa kali, meskipun pesan tersebut telah dikonfirmasi. Bagian berikut membahas cara mengatasi skenario pengiriman ulang umum.

Pengiriman ulang banyak pesan yang konsisten

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 memperpanjang setelan batas waktu konfirmasi. Anda juga dapat mengikuti praktik terbaik terkait cara mempertahankan langganan yang sehat.

Pengiriman ulang pesan sesekali

Jika Anda melihat pesan dikirim ulang sebelum batas waktu konfirmasi penerimaan terlewati atau setelah pesan dikonfirmasi penerimaannya dalam beberapa detik, Pub/Sub berperilaku seperti yang diharapkan. Anda tidak akan sering melihat lonjakan pengiriman ulang ini, tetapi jika pengiriman ulang terjadi, kemungkinan akan terjadi pada beberapa pesan secara bersamaan. Sistem Anda harus dibuat untuk mentoleransi duplikat sesekali ini.

Pengiriman ulang beberapa pesan berulang kali

Jika Anda melihat sejumlah kecil pesan dikirimkan beberapa kali, pertama-tama konfirmasi bahwa Anda telah membacanya. Jika tidak, cari tahu mengapa pelanggan Anda tidak menangani pesan dengan benar. Anda mungkin ingin mengonfigurasi topik pesan yang dihentikan pengirimannya untuk mencegah pengiriman ulang lebih lanjut. Jika Anda mengonfirmasi pesan, Pub/Sub mungkin masih beroperasi seperti yang diharapkan. Meskipun sangat jarang terjadi, sejumlah kecil pesan masih dapat dikirim beberapa kali jika terjadi gangguan jaringan atau hardware internal. Layanan mencoba memperbaiki diri sendiri dalam kasus ini, tetapi mungkin diperlukan waktu beberapa menit agar perbaikan dapat diaktifkan.

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 mentoleransi duplikat, Anda dapat mengaktifkan pengiriman tepat satu kali. Ingatlah bahwa fitur ini hanya tersedia untuk langganan tarik dan juga menghasilkan latensi publish-to-subscribe yang lebih tinggi. Evaluasi apakah konsekuensi latensi yang lebih tinggi dapat diterima untuk kasus penggunaan Anda sebelum mengaktifkan fitur ini.

Praktik terbaik untuk pengiriman pesan berurutan dalam berlangganan

Jika Anda menggunakan pengurutan pesan, pastikan hal berikut:

  • Pilih StreamingPull atau Tarik langganan. Untuk langganan push, Pub/Sub hanya mendukung satu pesan yang belum diproses untuk setiap kunci pengurutan dalam satu waktu. Mengirim permintaan push paralel dalam skenario seperti itu akan serupa 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 dalam 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 terlampir pada topik dapat menentukan apakah mereka memerlukan pengiriman yang berurutan tanpa saling memengaruhi.

  • Mengonfirmasi pesan secara berurutan. Saat menggunakan pengiriman berurutan, konfirmasi untuk pesan selanjutnya 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 menerima semuanya dan hanya mengonfirmasi pesan 3, layanan tidak menganggap pesan 3 sebagai 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 meringkas praktik terbaik yang direkomendasikan dalam dokumen ini:

Topik Tugas
Pilih 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 Memproses pesan sebelum Anda mengonfirmasinya. Atau, konfigurasikan untuk operasi penelusuran agar Anda tidak kehilangan pesan yang terkonfirmasi.
Kontrol alur Konfigurasi kontrol alur di setelan pelanggan Anda untuk memastikan bahwa 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.

Langkah berikutnya