Praktik terbaik untuk memublikasikan ke topik Pub/Sub

Dalam penerbitan, klien penerbit mengirim pesan ke topik Pub/Sub. Berikut adalah beberapa praktik terbaik untuk memublikasikan pesan ke Pub/Sub.

Dokumen ini mengasumsikan bahwa Anda sudah memahami proses memublikasikan pesan ke topik Pub/Sub.

Jika Anda baru menggunakan Pub/Sub, lihat salah satu panduan Memulai dan pelajari cara menjalankan Pub/Sub menggunakan konsol, gcloud CLI, atau library klien.

Mengambil tindakan berdasarkan respons dari publikasi

Saat panggilan publikasi library klien tingkat tinggi selesai, panggilan akan menampilkan objek future yang berisi hasil operasi. Untuk menghindari pemblokiran permintaan publikasi individual, tangani hasilnya secara asinkron. Anda harus memutuskan cara terbaik untuk menangani kegagalan untuk kasus penggunaan Anda. Beberapa opsi mencakup:

  • Mencatat error dan tidak melakukan apa pun (jika kasus penggunaan Anda tidak memerlukan penerbitan semua pesan yang berhasil).
  • Coba lagi publikasi jika terjadi kegagalan yang mungkin bersifat sementara seperti error Deadline exceeded.
  • Simpan pesan ke file atau penyimpanan untuk mencoba kembali publikasinya nanti, terutama jika terjadi error yang memerlukan intervensi pengguna seperti Not found atau Permission denied.
  • Sebarkan error ke layanan upstream yang mengirimkan pesan yang Anda coba publikasikan.

Jika Anda yakin bahwa Pub/Sub tidak mengirimkan pesan seperti yang diharapkan kepada pelanggan Anda, pastikan Anda melacak hasil publikasi dan bahwa publikasi berhasil.

Lampirkan langganan atau aktifkan retensi topik sebelum Anda mulai memublikasikan

Jika Anda mulai memublikasikan ke topik yang tidak memiliki pelanggan terlampir, pesan tidak akan dipertahankan. Pesan ini tidak dapat dikirim ke langganan yang dilampirkan setelahnya. Oleh karena itu, sebelum Anda mulai memublikasikan pesan, lakukan salah satu hal berikut:

Mengonfigurasi pesan batch

Dalam Pub/Sub, pesan batch mengacu pada proses penggabungan beberapa pesan menjadi satu batch yang dipublikasikan dalam satu permintaan publikasi. Jika Anda menggunakan library klien untuk memublikasikan pesan, pengelompokan diaktifkan secara default. Pengelompokan pesan membantu penayang meningkatkan efisiensi dan mengirim pesan dengan throughput yang lebih tinggi. Pengelompokan mengurangi biaya untuk memublikasikan data. Namun, pengelompokan juga menimbulkan latensi untuk setiap pesan karena penayang menunggu hingga batch terisi sebelum memublikasikan batch.

Latensi di Pub/Sub dapat berupa dua jenis:

  • Latensi end-to-end adalah waktu yang dibutuhkan agar pesan dipublikasikan oleh penayang dan dikirim ke pelanggan yang sesuai untuk diproses.

  • Latensi publikasi adalah jumlah waktu yang diperlukan untuk memublikasikan pesan.

Saat menggunakan batching, peningkatan kedua jenis latensi adalah pertukaran untuk meningkatkan efisiensi dan throughput.

Anda dapat mengelompokkan pesan dalam library klien berdasarkan ukuran permintaan pesan, jumlah pesan, dan waktu. Saat mengonfigurasi setelan batch, Anda dapat menemukan keseimbangan yang tepat antara biaya, throughput, dan latensi yang sesuai dengan kasus penggunaan Anda.

Nilai default untuk variabel pesan batch dan nama variabel mungkin berbeda di seluruh library klien. Anda dapat menentukan satu atau ketiga nilai di library klien. Jika salah satu nilai untuk variabel pesan batch terpenuhi, library klien akan memublikasikan batch pesan berikutnya.

Untuk mengonfigurasi pesan batch untuk klien penayang, lihat Pesan batch dalam permintaan publikasi.

Mengonfigurasi kontrol alur untuk lonjakan pesan sementara

Jika klien penayang harus memproses sejumlah besar pesan, permintaan publikasi mungkin mulai menumpuk di memori hingga pesan gagal dipublikasikan dengan error Deadline exceeded.

Untuk mengatasi lonjakan sementara dalam memublikasikan pesan, Anda dapat menggunakan kontrol alur di setelan penayang. Kontrol alur sisi penayang mencegah resource klien penayang kewalahan dengan terlalu banyak permintaan yang belum selesai. Jika klien penayang dibatasi dalam hal memori, CPU, atau thread, sejumlah besar error Deadline exceeded akan dihasilkan.

Untuk mengonfigurasi kontrol alur di library klien, tetapkan nilai yang sesuai untuk variabel maximum outstanding messages dan maximum outstanding message bytes. Nilai ini menyeimbangkan throughput pesan dan kapasitas sistem.

Untuk memeriksa apakah pustaka klien Anda mendukung kontrol alur penayang dan cara mengonfigurasinya, lihat Kontrol alur.

Memahami bandwidth dan latensi jaringan Anda

Throughput penayang Anda dibatasi oleh bandwidth jaringan dan jumlah permintaan yang dikirim. Jika bandwidth Anda bagus, tetapi latensi jaringan tinggi, Anda tidak ingin membebani sistem dengan banyak permintaan kecil. Kontrol alur sisi penayang dapat membantu mengatasi masalah jaringan sisi klien.

Throughput penayang Anda juga terikat pada CPU dan memori. Lebih banyak core mesin yang tersedia memungkinkan Anda menetapkan jumlah thread yang lebih tinggi untuk throughput publikasi yang lebih baik. Untuk lebih memahami cara memaksimalkan performa streaming, lihat Menguji klien Cloud Pub/Sub untuk memaksimalkan performa streaming.

Menyesuaikan variabel permintaan percobaan ulang untuk publikasi yang gagal

Saat pesan dipublikasikan oleh klien penayang, Anda mungkin melihat kegagalan publikasi. Kegagalan ini biasanya disebabkan oleh hambatan di sisi klien, seperti CPU layanan yang tidak memadai, kondisi thread yang buruk, atau kemacetan jaringan. publisher retry policy menentukan perilaku jika pengiriman pesan gagal. Kebijakan percobaan ulang menentukan berapa kali Pub/Sub mencoba mengirimkan pesan dan durasi waktu antara setiap upaya.

Misalnya, di library klien Java untuk Pub/Sub, klien penayang berisi nilai berikut:

  • initialRetryDelay. Penundaan awal yang ditunggu penayang sebelum mencoba lagi operasi publikasi. Nilai defaultnya adalah 100 milliseconds.

  • retryDelayMultiplier. Faktor perkalian yang digunakan untuk menghitung penundaan di antara percobaan ulang. Nilai defaultnya adalah 4. Artinya, penundaan antara percobaan ulang adalah hingga 100 milliseconds * 4 = 400 milliseconds untuk percobaan ulang kedua, dan hingga 400 milliseconds * 4 = 1600 milliseconds untuk percobaan ulang ketiga.

  • maxRetryDelay. Penundaan maksimum yang ditunggu penayang sebelum mencoba ulang operasi publikasi. Nilai defaultnya adalah 60 seconds.

  • initialRpcTimeout. Waktu tunggu awal yang digunakan penayang untuk menunggu panggilan RPC selesai. Nilai defaultnya adalah 5 seconds.

  • rpcTimeoutMultiplier. Faktor perkalian yang digunakan untuk menghitung waktu tunggu RPC. Nilai defaultnya adalah 4.0. Artinya, waktu tunggu untuk panggilan RPC adalah hingga 5 seconds * 4 = 20 seconds untuk percobaan ulang kedua, dan hingga 10 seconds * 4 = 40 seconds untuk percobaan ulang ketiga.

  • maxRpcTimeout. Waktu tunggu maksimum yang digunakan penayang untuk menunggu panggilan RPC selesai. Nilai defaultnya adalah 600 seconds.

  • totalTimeout. Total waktu tunggu untuk operasi publikasi. Ini mencakup waktu yang dihabiskan untuk menunggu panggilan RPC selesai dan waktu yang dihabiskan untuk menunggu di antara percobaan ulang. Nilai defaultnya adalah 600 seconds.

Hanya lakukan penyesuaian pada nilai yang ditentukan jika Anda merasa setelan coba lagi default tidak cukup untuk kasus penggunaan Anda. Misalnya, memublikasikan sejumlah besar pesan tidak mengharuskan Anda meningkatkan nilai initialRetryDelay dan maxRetryDelay. Namun, Anda dapat menyesuaikan kontrol alur dan pengelompokan dalam situasi tersebut. Jika Anda memublikasikan dari koneksi internet yang tidak stabil atau koneksi yang memiliki batasan bandwidth, Anda dapat bereksperimen dengan nilai untuk variabel initialRpcTimeout, maxRpcTimeout, dan rpcTimeoutMultiplier. Untuk nilai yang direkomendasikan, lihat Operasi publikasi gagal dengan DEADLINE_EXCEEDED.

Menggunakan kebijakan penyimpanan pesan untuk memastikan lokalitas data

Kebijakan penyimpanan pesan topik Pub/Sub menawarkan cara untuk memastikan bahwa pesan yang dipublikasikan ke topik tidak pernah dipertahankan di luar serangkaianGoogle Cloud region yang Anda tentukan, terlepas dari asal permintaan publikasi.

Gunakan kebijakan penyimpanan pesan untuk menentukan daftar Google Cloud region tempat Pub/Sub diizinkan menyimpan data pesan di disk. Jika pesan dipublikasikan ke region yang tidak ada dalam daftar ini, permintaan akan diteruskan ke region terdekat yang diizinkan untuk diproses. Kebijakan dapat dikonfigurasi pada topik atau sebagai kebijakan organisasi untuk project, folder project, atau seluruh organisasi. Jika kebijakan organisasi dikonfigurasi, kebijakan topik individual hanya dapat diubah dengan cara yang tidak melanggar kebijakan organisasi.

Misalnya, perusahaan yang beroperasi di Eropa dapat menggunakan kebijakan penyimpanan pesan untuk memastikan bahwa semua data disimpan di region Uni Eropa untuk mematuhi hukum setempat.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi kebijakan penyimpanan pesan.

Praktik terbaik untuk pengiriman pesan berurutan dalam penerbitan

Jika Anda menggunakan pengurutan pesan, pastikan hal berikut:

  • Gunakan endpoint lokasi. Urutan pesan dipertahankan di sisi publikasi dan dalam suatu region. Dengan kata lain, jika Anda memublikasikan pesan ke beberapa region, hanya pesan dalam region yang sama yang dikirimkan dalam urutan yang konsisten. Jika semua pesan Anda dipublikasikan ke region yang sama, tetapi pelanggan Anda tersebar di berbagai region, maka pelanggan akan menerima semua pesan secara berurutan. Gunakan endpoint lokasi untuk memublikasikan pesan ke region yang sama.

  • Mengonfigurasi fungsi melanjutkan publikasi. Saat library klien mencoba lagi permintaan dan pesan memiliki kunci pengurutan, library klien akan mencoba lagi permintaan tersebut berulang kali, terlepas dari setelan percobaan ulang. Jika terjadi error yang tidak dapat dicoba lagi, library klien tidak akan memublikasikan pesan dan berhenti memublikasikan pesan lain dengan kunci pengurutan yang sama. Jika Anda siap melanjutkan publikasi dengan kunci pengurutan yang gagal dipublikasikan, panggil metode resumePublish.

Ringkasan praktik terbaik

Tabel berikut meringkas praktik terbaik yang direkomendasikan dalam dokumen ini:

Topik Tugas
Mengonfigurasi retensi pesan Lampirkan langganan sebelum Anda memublikasikan atau mengaktifkan retensi pesan.
Mengelompokkan pesan dalam permintaan publikasi Mengelompokkan atau mengumpulkan pesan untuk meningkatkan efisiensi penayang dan mengirim pesan dengan throughput yang lebih tinggi.
Kontrol alur Konfigurasi kontrol alur di setelan penayang untuk menangani lonjakan traffic sementara.
Pengujian Klien Pub/Sub untuk memaksimalkan performa streaming Menskalakan throughput penayang dengan peningkatan core mesin dan bandwidth jaringan yang tersedia.
Mencoba kembali permintaan Lakukan penyesuaian pada nilai yang ditentukan dari kebijakan coba lagi penerbit hanya jika Anda merasa setelan default tidak cukup untuk kasus penggunaan Anda.
Mengonfigurasi kebijakan penyimpanan pesan Gunakan kebijakan penyimpanan pesan untuk menyimpan data pesan di disk hanya di lokasi tertentu.
Menggunakan endpoint lokasi saat menggunakan kunci pemesanan dalam publikasi Saat menggunakan pesan berurutan, gunakan endpoint lokasi dan konfigurasi fungsi publikasi lanjutan untuk kegagalan publikasi.

Langkah berikutnya