Praktik terbaik untuk memublikasikan ke topik Pub/Sub

Dalam proses publikasi, 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 publikasi pesan ke topik Pub/Sub.

Jika Anda baru menggunakan Pub/Sub, baca salah satu Panduan memulai dan pelajari cara menjalankan Pub/Sub menggunakan konsol, gCloud CLI, atau library klien.

Lampirkan langganan atau aktifkan retensi topik sebelum Anda mulai memublikasikan

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

Mengonfigurasi pesan batch

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

Latensi di Pub/Sub dapat berupa salah satu dari dua jenis berikut:

  • Latensi end-to-end adalah waktu yang diperlukan agar pesan dipublikasikan oleh penayang dan dikirimkan ke pelanggan terkait untuk diproses.

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

Saat menggunakan pengelompokan, meningkatkan kedua jenis latensi merupakan kompromi untuk meningkatkan efisiensi dan throughput.

Anda dapat mengelompokkan 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 sesuai dengan kasus penggunaan Anda.

Nilai default untuk variabel pesan batch dan nama variabel mungkin berbeda di setiap 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 pesan dalam jumlah besar, permintaan publikasi mungkin mulai terakumulasi di memori sampai pesan gagal dipublikasikan dengan error Deadline exceeded.

Untuk mengatasi lonjakan sementara dalam publikasi pesan, Anda dapat menggunakan kontrol alur di setelan penayang. Kontrol alur sisi penayang mencegah resource klien penayang menjadi kewalahan dengan terlalu banyak permintaan yang belum terselesaikan. Jika klien penayang menjadi terbatas 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 maksimum pesan yang belum diproses dan byte pesan maksimum yang belum diproses. Nilai-nilai ini menyeimbangkan throughput pesan dan kapasitas sistem.

Untuk memeriksa apakah library klien Anda mendukung kontrol alur penayang dan untuk mengonfigurasinya, lihat Kontrol flow.

Memahami bandwidth dan latensi jaringan Anda

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

Throughput penayang juga terikat CPU dan memori. Dengan core mesin yang lebih banyak, Anda dapat menetapkan jumlah thread yang lebih tinggi 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 coba lagi untuk publikasi yang gagal

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

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

  • InitialRetryDelay. Penundaan awal yang menunggu penayang sebelum mencoba kembali operasi publikasi. Nilai defaultnya adalah 100 milliseconds.

  • retryDelayMultiplier. Faktor perkalian yang digunakan untuk menghitung keterlambatan antar-percobaan ulang. Nilai defaultnya adalah 4. Ini berarti penundaan antara percobaan ulang maksimal 100 milliseconds * 4 = 400 milliseconds untuk percobaan ulang kedua, dan maksimal 400 milliseconds * 4 = 1600 milliseconds untuk percobaan ulang ketiga.

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

  • initialRpcTimeout. Waktu tunggu awal yang ditunggu penayang hingga 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 panggilan RPC maksimal 5 seconds * 4 = 20 seconds untuk percobaan ulang kedua, dan maksimal 10 seconds * 4 = 40 seconds untuk percobaan ulang ketiga.

  • maxRpcTimeout. Waktu tunggu maksimum yang ditunggu penayang hingga panggilan RPC selesai. Nilai defaultnya adalah 600 seconds.

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

Hanya lakukan penyesuaian pada nilai yang ditentukan jika Anda merasa setelan percobaan ulang default tidak memadai untuk kasus penggunaan Anda. Misalnya, memublikasikan pesan dalam jumlah besar tidak akan mengharuskan Anda meningkatkan nilai initialRetryDelay dan maxRetryDelay. Namun, Anda dapat menyesuaikan kontrol alur dan pengelompokan dalam situasi tersebut. Jika memublikasikan dari koneksi internet yang tidak stabil atau koneksi yang memiliki bandwidth terbatas, Anda dapat bereksperimen dengan nilai untuk variabel initialRpcTimeout, maxRpcTimeout, dan rpcTimeoutMultiplier. Untuk mengetahui 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 suatu topik tidak pernah dipertahankan di luar kumpulan region Google Cloud yang Anda tentukan, terlepas dari asal permintaan publikasi.

Gunakan kebijakan penyimpanan pesan untuk menentukan daftar region Google Cloud tempat Pub/Sub diizinkan untuk 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 ini dapat dikonfigurasi berdasarkan topik atau sebagai kebijakan organisasi untuk project, folder project, atau seluruh organisasi. Saat kebijakan organisasi dikonfigurasi, setiap kebijakan topik hanya dapat diubah dengan cara yang tidak melanggar kebijakan organisasi.

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

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi kebijakan penyimpanan pesan.

Praktik terbaik untuk pesan yang diurutkan dalam publikasi

Jika Anda menggunakan pengurutan pesan, pastikan hal berikut:

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

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

Ringkasan praktik terbaik

Tabel berikut merangkum praktik terbaik yang direkomendasikan dalam dokumen ini:

Topik Tugas
Mengonfigurasi retensi pesan Lampirkan langganan sebelum Anda memublikasikan atau mengaktifkan retensi pesan.
Menumpuk pesan dalam permintaan publikasi Batch pesan atau grup untuk meningkatkan efisiensi penayang dan mengirim pesan pada throughput yang lebih tinggi.
Kontrol alur Konfigurasi kontrol alur di setelan penayang Anda untuk menangani lonjakan traffic sementara.
Menguji klien Pub/Sub untuk memaksimalkan performa streaming Skalakan throughput penayang dengan peningkatan core mesin dan bandwidth jaringan yang tersedia.
Permintaan percobaan ulang Lakukan penyesuaian pada nilai yang ditentukan dari kebijakan percobaan ulang penayang hanya jika Anda mendapati bahwa setelan default tidak memadai untuk kasus penggunaan Anda.
Mengonfigurasi kebijakan penyimpanan pesan Gunakan kebijakan penyimpanan pesan untuk menyimpan data pesan pada disk hanya di lokasi tertentu.
Menggunakan endpoint lokasi saat menggunakan kunci pengurutan dalam publikasi Saat menggunakan pesan yang diurutkan, gunakan endpoint lokasi dan konfigurasikan fungsi publikasi resume untuk kegagalan publikasi.

Langkah selanjutnya