Langganan push

Dokumen ini memberikan ringkasan tentang langganan push, alur kerjanya, dan properti terkait.

Dalam pengiriman push, Pub/Sub memulai permintaan ke aplikasi pelanggan Anda untuk mengirim pesan. Pesan dikirim ke server yang dapat dialamatkan secara publik atau webhook, seperti permintaan POST HTTPS.

Langganan push meminimalkan dependensi pada mekanisme autentikasi dan library klien khusus Pub/Sub. Fitur ini juga berfungsi dengan baik dengan teknologi layanan serverless dan penskalaan otomatis, seperti Cloud Functions, Cloud Run, dan Google Kubernetes Engine.

Sebelum memulai

Sebelum membaca dokumen ini, pastikan Anda sudah memahami hal-hal berikut:

Cara kerja Pub/Sub dan persyaratan Pub/Sub yang berbeda.
Berbagai jenis langganan yang didukung Pub/Sub dan alasan Anda perlu menggunakan langganan push.

Alur kerja langganan push

Dalam langganan push, server Pub/Sub menginisiasi permintaan ke klien pelanggan Anda untuk mengirim pesan.

Gambar berikut menunjukkan alur kerja antara klien pelanggan dan langganan push.

Alur pesan untuk langganan push — **Gambar 3.** Alur kerja untuk langganan push

Berikut adalah deskripsi singkat tentang alur kerja yang merujuk pada Gambar 3:

Server Pub/Sub mengirim setiap pesan sebagai permintaan HTTPS ke klien pelanggan di endpoint yang telah dikonfigurasi sebelumnya. Permintaan ini ditampilkan sebagai PushRequest pada gambar.
Endpoint mengonfirmasi pesan tersebut dengan menampilkan kode status HTTP berhasil. Respons yang gagal menunjukkan bahwa Pub/Sub harus mengirim ulang pesan. Respons ini ditampilkan sebagai PushResponse dalam gambar.
Pub/Sub secara dinamis menyesuaikan kecepatan permintaan push berdasarkan kecepatan respons yang berhasil diterima.

Properti langganan push

Properti yang dikonfigurasi untuk langganan push menentukan cara Anda menulis pesan ke langganan. Untuk informasi selengkapnya, lihat properti langganan.

Cara endpoint push menerima pesan

Saat Pub/Sub mengirimkan pesan ke endpoint push, Anda dapat memilih untuk mengirimkannya dalam keadaan utuh atau terbuka. Secara default, pesan dikirim dalam kondisi digabungkan.

Dibungkus. Pub/Sub mengirim pesan dalam isi JSON permintaan POST.
Dibuka. Pub/Sub mengirimkan data pesan mentah secara langsung sebagai isi HTTP.

Contoh berikut menunjukkan isi permintaan POST JSON yang digabungkan ke endpoint push yang berisi string Hello there di kolom message.data

Isi permintaan POST adalah objek JSON. Data pesan ada di kolom message.data dan dienkode dengan base64.

Contoh permintaan dengan nilai minimum

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }

Contoh permintaan dengan nilai maksimum

Perhatikan bahwa contoh ini menunjukkan nilai maksimum saat ini, yang dapat berubah dari waktu ke waktu. Selain itu, peta atribut dapat berisi berbagai nilai.

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
}

Untuk menerima pesan dari langganan push, gunakan webhook dan proses permintaan POST yang dikirim Pub/Sub ke endpoint push. Untuk mengetahui informasi selengkapnya tentang memproses permintaan POST ini di App Engine, lihat Menulis dan merespons pesan Pub/Sub.

Setelah Anda menerima permintaan push, tampilkan kode status HTTP. Untuk mengonfirmasi pesan, tampilkan salah satu kode status berikut:

102
200
201
202
204

Untuk mengirim konfirmasi negatif atas pesan tersebut, tampilkan kode status lainnya. Jika Anda mengirim konfirmasi negatif atau batas waktu konfirmasi berakhir, Pub/Sub akan mengirim ulang pesan tersebut. Anda tidak dapat mengubah batas waktu konfirmasi setiap pesan yang diterima dari langganan push.

Autentikasi untuk langganan push

Jika langganan push menggunakan autentikasi, layanan Pub/Sub akan menandatangani JWT dan mengirimkan JWT di header otorisasi permintaan push.

Untuk mengetahui informasi selengkapnya tentang cara menyiapkan autentikasi, lihat Mengautentikasi permintaan push.

Menghentikan dan melanjutkan pengiriman pesan

Untuk menghentikan sementara Pub/Sub agar tidak mengirim permintaan ke endpoint push, ubah langganan menjadi pull. Perubahan ini memerlukan waktu beberapa menit untuk diterapkan.

Untuk melanjutkan pengiriman push, tetapkan URL ke endpoint yang valid lagi. Untuk menghentikan pengiriman secara permanen, hapus langganan.

Dorongan backoff

Jika pelanggan push mengirim terlalu banyak konfirmasi negatif, Pub/Sub mungkin akan mulai mengirim pesan menggunakan backoff push. Saat menggunakan backoff push, Pub/Sub akan berhenti mengirim pesan selama jumlah waktu yang telah ditentukan. Rentang waktu ini bisa berkisar antara 100 milidetik hingga 60 detik. Setelah waktu berlalu, Pub/Sub akan mulai mengirim pesan lagi.

Backoff push menggunakan algoritma backoff eksponensial untuk menentukan penundaan Pub/Sub yang digunakan di antara pengiriman pesan. Jumlah waktu ini dihitung berdasarkan jumlah konfirmasi negatif yang dikirim oleh pelanggan.

Misalnya, jika pelanggan push menerima lima pesan per detik dan mengirim satu konfirmasi negatif per detik, Pub/Sub akan mengirimkan pesan kira-kira setiap 500 milidetik. Atau, jika pelanggan push mengirim lima konfirmasi negatif per detik, Pub/Sub akan mengirimkan pesan setiap 30 hingga 60 detik.

Perhatikan pertimbangan berikut tentang push backoff:

Backoff push tidak dapat diaktifkan atau dinonaktifkan. Anda juga tidak dapat mengubah nilai yang digunakan untuk menghitung penundaan.
Pemicu backoff push pada tindakan berikut:
- Ketika pengakuan negatif diterima.
- Saat batas waktu konfirmasi pesan berakhir.
Backoff push berlaku untuk semua pesan di langganan (global).

Rasio pengiriman

Pub/Sub menyesuaikan jumlah permintaan push serentak menggunakan algoritma mulai lambat. Jumlah maksimum permintaan push serentak yang diizinkan adalah jendela push. Jendela push akan meningkat pada setiap pengiriman yang berhasil dan mengurangi setiap kegagalan. Sistem dimulai dengan ukuran jendela satu digit yang kecil.

Saat pelanggan mengonfirmasi pesan, periodenya akan meningkat secara eksponensial. Untuk langganan yang pelanggannya mengonfirmasi lebih dari 99% pesan dan rata-rata latensi permintaan push kurang dari satu detik, jendela push harus cukup perlu diperluas untuk mengikuti throughput publikasi.

Latensi permintaan push mencakup hal berikut:

Latensi jaringan bolak-balik antara server Pub/Sub dan endpoint push
Waktu pemrosesan pelanggan

Setelah 3.000 pesan yang belum diterima per region, periode akan meningkat secara linear untuk mencegah endpoint push menerima terlalu banyak pesan. Jika latensi rata-rata melebihi satu detik atau pelanggan mengonfirmasi permintaan kurang dari 99%, periode waktu ini akan menurun hingga ke batas bawah 3.000 pesan yang belum diproses.

Untuk informasi selengkapnya tentang metrik yang dapat Anda gunakan untuk memantau pengiriman push, lihat Memantau langganan push.

Kuota dan batas

Langganan push tunduk pada sekumpulan quotas dan batas resource.

Langkah selanjutnya

Buat langganan push untuk topik Anda.
Membuat atau mengubah langganan dengan gcloud CLI.
Membuat atau mengubah langganan dengan REST API.
Buat atau ubah langganan dengan RPC API.