Praktik terbaik untuk memublikasikan ke topik Pub/Sub

Dalam publikasi, klien penayang mengirim pesan ke topik Pub/Sub. Berikut 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 mendatang 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 tindakan lain (jika kasus penggunaan Anda tidak memerlukan publikasi semua pesan yang berhasil).
  • Mencoba kembali publikasi pada kegagalan yang berpotensi sementara seperti error Deadline exceeded.
  • Mempertahankan pesan ke file atau penyimpanan untuk mencoba kembali publikasinya nanti, terutama pada error yang memerlukan intervensi pengguna seperti Not found atau Permission denied.
  • Menyebarkan error ke layanan upstream yang mengirimkan pesan yang Anda coba publikasikan.

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

Melampirkan langganan atau mengaktifkan 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 berikutnya. Oleh karena itu, sebelum Anda mulai memublikasikan pesan, lakukan salah satu hal berikut:

Mengonfigurasi pesan batch

Dalam Pub/Sub, pesan batch mengacu pada proses menggabungkan beberapa pesan ke dalam satu batch yang dipublikasikan dalam satu permintaan publikasi. Jika Anda menggunakan library klien untuk memublikasikan pesan, batching akan diaktifkan secara default. Batching (atau pengelompokan) pesan membantu penayang meningkatkan efisiensinya dan mengirim pesan dengan throughput yang lebih tinggi. Batching mengurangi biaya untuk memublikasikan data. Namun, batching juga membuat latensi untuk setiap pesan karena penayang menunggu batch terisi sebelum memublikasikan batch.

Latensi di Pub/Sub dapat memiliki dua jenis:

  • Latensi end-to-end adalah waktu yang diperlukan 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 membuat batch pesan di 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 dalam 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 terakumulasi dalam 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 library klien Anda mendukung kontrol alur penayang dan cara mengonfigurasi nya, lihat Kontrol alur.

Memahami bandwidth dan latensi jaringan

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

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

Menyesuaikan variabel permintaan percobaan ulang untuk publikasi yang gagal