Langganan push

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

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

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

Sebelum memulai

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

  • Cara kerja Pub/Sub dan berbagai istilah Pub/Sub.

  • Berbagai jenis langganan yang didukung Pub/Sub dan alasan Anda mungkin ingin menggunakan langganan push.

Alur kerja langganan push

Dalam langganan push, server Pub/Sub memulai 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 deskripsi singkat alur kerja yang merujuk pada Gambar 3:

  1. Server Pub/Sub mengirim setiap pesan sebagai permintaan HTTPS ke klien subscriber di endpoint yang telah dikonfigurasi sebelumnya. Permintaan ini ditampilkan sebagai PushRequest dalam gambar.
  2. Endpoint mengonfirmasi pesan dengan menampilkan kode status HTTP yang berhasil. Respons yang tidak berhasil menunjukkan bahwa Pub/Sub harus mengirim ulang pesan. Respons ini ditampilkan sebagai PushResponse dalam gambar.
  3. Pub/Sub menyesuaikan kecepatan permintaan push secara dinamis berdasarkan kecepatan penerimaan respons keberhasilan.

Properti langganan push

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

Cara endpoint push menerima pesan

Saat Pub/Sub mengirimkan pesan ke endpoint push, Anda dapat memilih untuk mengirimkannya dengan atau tanpa wrapper. Secara default, pesan dikirim dalam bentuk terbungkus.

  • Wrapped. Pub/Sub mengirim pesan dalam isi JSON permintaan POST.
  • Tidak terbungkus. Pub/Sub mengirim data pesan mentah secara langsung sebagai isi HTTP.

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

Isi permintaan POST adalah objek JSON. Data pesan berada 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 menampilkan 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 pemrosesan permintaan POST ini di App Engine, lihat Menulis dan merespons pesan Pub/Sub.

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

  • 102
  • 200
  • 201
  • 202
  • 204

Untuk mengirimkan konfirmasi negatif untuk pesan, kembalikan kode status lainnya. Jika Anda mengirimkan konfirmasi negatif atau tenggat waktu konfirmasi telah berakhir, Pub/Sub akan mengirim ulang pesan. Anda tidak dapat mengubah batas waktu konfirmasi setiap pesan yang Anda terima dari langganan push.

Autentikasi untuk langganan push

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

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

Menghentikan dan melanjutkan pengiriman pesan

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

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

Backoff push

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

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

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 mengirim pesan setiap 30 hingga 60 detik.

Perhatikan pertimbangan berikut tentang penundaan pengiriman:

  • Pemberhentian pengiriman tidak dapat diaktifkan atau dinonaktifkan. Anda juga tidak dapat mengubah nilai yang digunakan untuk menghitung penundaan.
  • Pemicu penundaan saat melakukan tindakan berikut:
    • Saat pengakuan negatif diterima.
    • Saat batas waktu konfirmasi pesan berakhir.
  • Penerapan penundaan pengiriman pesan berlaku untuk semua pesan dalam langganan (global).

Rasio penayangan

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

Saat pelanggan mengonfirmasi pesan, jendela akan meningkat secara eksponensial. Untuk langganan dengan pelanggan yang mengonfirmasi lebih dari 99% pesan dan latensi permintaan push rata-rata kurang dari satu detik, jendela push harus diperluas agar dapat mengimbangi throughput publikasi.

Latensi permintaan push mencakup hal berikut:

Setelah 3.000 pesan yang belum terkirim per wilayah, jendela akan meningkat secara linear untuk mencegah endpoint push menerima terlalu banyak pesan. Jika latensi rata-rata melebihi satu detik atau pelanggan mengonfirmasi kurang dari 99% permintaan, jendela akan berkurang ke batas bawah 3.000 pesan yang belum diproses.

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

Kuota dan batas

Langganan push tunduk pada serangkaian kuota dan batas resource.

Langkah berikutnya