Dokumen ini memberikan beberapa tips pemecahan masalah umum untuk langganan Pub/Sub StreamingPull. Langganan StreamingPull menggunakan StreamingPull API.
Baca lebih lanjut tentang langganan StreamingPull di Panduan menarik pelanggan.
StreamingPull memiliki rasio error 100%
Streaming StreamingPull selalu ditutup dengan status non-OK. Tidak seperti RPC unary, status untuk StreamingPull hanya merupakan indikasi bahwa streaming rusak. Permintaan tidak gagal. Oleh karena itu, meskipun StreamingPull API mungkin memiliki rasio error 100% yang mengejutkan, perilaku ini sengaja dibuat.
Error prasyarat gagal, tidak tersedia, atau tidak ditemukan
Karena streaming StreamingPull selalu disertai error, sebaiknya periksa metrik penghentian streaming saat mendiagnosis error. Namun, berfokuslah pada metrik respons StreamingPull seperti subscription/streaming_pull_response_count.
Cari error ini:
Error Prakondisi gagal yang dapat terjadi dalam kasus berikut:
Pub/Sub mencoba mendekripsi pesan dengan kunci Cloud KMS yang dinonaktifkan.
Langganan ditangguhkan untuk sementara jika ada pesan dalam backlog langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan.
Error tidak tersedia yang dapat terjadi saat Pub/Sub tidak dapat memproses permintaan. Kemungkinan besar ini adalah kondisi sementara dan library klien akan mencoba kembali permintaan tersebut.
Error tidak ditemukan yang dapat terjadi saat langganan dihapus atau langganan tidak pernah ada. Kasus terakhir terjadi saat Anda memberikan jalur langganan yang tidak valid.
Backlog besar berisi pesan kecil dalam langganan StreamingPull
Stack StreamingPull gRPC dioptimalkan untuk throughput tinggi, sehingga pesan menjadi buffer. Jika Anda mencoba memproses backlog besar untuk pesan kecil, Anda mungkin melihat pesan dikirim beberapa kali. Pesan-pesan ini mungkin tidak diseimbangkan bebannya secara efektif di seluruh klien.
Buffer antara layanan Pub/Sub dan ruang pengguna library klien sekitar 10 MB. Untuk memahami efek buffer ini pada perilaku library klien, pertimbangkan contoh ini:
Ada backlog 10.000 pesan 1 KB untuk langganan.
Setiap pesan memerlukan waktu satu detik untuk pemrosesan berurutan oleh instance klien thread tunggal.
Instance klien pertama yang membuat koneksi StreamingPull ke layanan untuk langganan tersebut akan mengisi buffer-nya dengan 10.000 pesan.
Dibutuhkan waktu 10.000 detik (hampir tiga jam) untuk memproses buffer.
Pada waktu tersebut, beberapa pesan yang di-buffer melebihi batas waktu konfirmasinya dan dikirim ulang ke klien yang sama, sehingga menghasilkan duplikat.
Saat beberapa instance klien berjalan, pesan yang tertahan di buffer satu klien tidak akan tersedia untuk instance klien lainnya. Situasi ini tidak terjadi jika Anda menggunakan kontrol alur untuk StreamingPull. Layanan ini tidak pernah memiliki keseluruhan pesan sebesar 10 MB sekaligus dan dapat melakukan load balancing terhadap pesan di beberapa pelanggan.