Sottoscrizioni push

Questo documento fornisce una panoramica di un abbonamento push, del relativo flusso di lavoro e delle proprietà associate.

Nella consegna push, Pub/Sub avvia richieste all'applicazione sottoscrittore per consegnare i messaggi. I messaggi vengono recapitati a un server indirizzabile pubblicamente o a un webhook, ad esempio una richiesta POST HTTPS.

Le iscrizioni push riducono al minimo le dipendenze dalle librerie client e dai meccanismi di autenticazione specifici di Pub/Sub. Inoltre, funzionano bene con le tecnologie di servizi serverless e di scalabilità automatica, come le funzioni Cloud Run, Cloud Run e Google Kubernetes Engine.

Prima di iniziare

Prima di leggere questo documento, assicurati di conoscere quanto segue:

Flusso di lavoro delle sottoscrizioni push

In una sottoscrizione push, un server Pub/Sub avvia una richiesta al client sottoscrittore per consegnare i messaggi.

L'immagine seguente mostra il flusso di lavoro tra un client sottoscrittore e un abbonamento push.

Flusso di messaggi per una sottoscrizione push
Figura 3. Flusso di lavoro per una sottoscrizione push

Ecco una breve descrizione del flusso di lavoro che fa riferimento alla Figura 3:

  1. Il server Pub/Sub invia ogni messaggio come richiesta HTTPS al client sottoscrittore in un endpoint preconfigurato. Questa richiesta è mostrata come PushRequest nell'immagine.
  2. L'endpoint conferma il messaggio restituendo un codice di stato HTTP di operazione riuscita. Una risposta di errore indica che Pub/Sub deve nuovamente inviare i messaggi. Questa risposta viene visualizzata come PushResponse nell'immagine.
  3. Pub/Sub regola dinamicamente la frequenza delle richieste push in base alla frequenza con cui riceve risposte di successo.

Proprietà di una sottoscrizione push

Le proprietà che configuri per una sottoscrizione push determinano il modo in cui scrivi i messaggi nella sottoscrizione. Per ulteriori informazioni, consulta la sezione sulle proprietà di sottoscrizione.

In che modo gli endpoint push ricevono i messaggi

Quando Pub/Sub recapita un messaggio a un endpoint push, puoi scegliere di inviarlo con o senza wrapping. Per impostazione predefinita, i messaggi vengono inviati con a capo.

  • Incartato. Pub/Sub invia il messaggio nel corpo JSON di una richiesta POST.
  • Senza imballaggio. Pub/Sub invia i dati non elaborati del messaggio direttamente come corpo HTTP.

Gli esempi seguenti mostrano un corpo con wrapping di una richiesta POST JSON a un endpoint push che contiene la stringa Hello there nel campo message.data

Il corpo di una richiesta POST è un oggetto JSON. I dati del messaggio si trovano nel campo message.data e sono codificati in base64.

Esempio di richiesta con i valori minimi

  {
      "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"
  }

Esempio di richiesta con i valori massimi

Tieni presente che questo esempio mostra i valori massimi attuali, che potrebbero cambiare nel tempo. Inoltre, la mappa degli attributi può contenere una varietà di valori.

  {
      "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"
}

Per ricevere messaggi dalle sottoscrizioni push, utilizza un webhook ed elabora le richiestePOST inviate da Pub/Sub all'endpoint push. Per ulteriori informazioni sull'elaborazione di queste richieste POST in App Engine, consulta Scrittura di messaggi Cloud Pub/Sub e risposta a questi messaggi.

Dopo aver ricevuto una richiesta push, restituisci un codice di stato HTTP. Per confermare il messaggio, restituisci uno dei seguenti codici di stato:

  • 102
  • 200
  • 201
  • 202
  • 204

Per inviare un messaggio di conferma negativo, restituisci un altro codice stato. Se invii una conferma negativa o se scade la scadenza della conferma, Pub/Sub invia di nuovo il messaggio. Non puoi modificare la scadenza per l'acknowledgment dei singoli messaggi che ricevi dalle iscrizioni push.

Autenticazione per le iscrizioni push

Se una sottoscrizione push utilizza l'autenticazione, il servizio Pub/Sub firma un JWT e lo invia nell'intestazione di autorizzazione della richiesta push.

Per ulteriori informazioni sulla configurazione dell'autenticazione, consulta Autenticare le richieste push.

Interrompere e riprendere l'invio dei messaggi

Per interrompere temporaneamente l'invio di richieste da parte di Pub/Sub all'endpoint push, modifica l'abbonamento in pull. L'applicazione del passaggio può richiedere diversi minuti.

Per riprendere l'invio push, imposta di nuovo l'URL su un endpoint valido. Per interrompere definitivamente la pubblicazione, elimina l'abbonamento.

Backoff push

Se un sottoscrittore push invia troppi riconoscimenti negativi, Pub/Sub potrebbe iniziare a inviare i messaggi utilizzando un backoff push. Quando Pub/Sub utilizza un backoff push, interrompe il recapito dei messaggi per un periodo di tempo predeterminato. Questo intervallo di tempo può variare da 100 millisecondi a 60 secondi. Una volta trascorso il tempo, Pub/Sub inizia a recapitare di nuovo i messaggi.

Il backoff push utilizza un algoritmo di backoff esponenziale per determinare il ritardo utilizzato da Pub/Sub tra l'invio di messaggi. Questo periodo di tempo viene calcolato in base al numero di conferme negative inviate dagli iscritti.

Ad esempio, se un sottoscrittore push riceve cinque messaggi al secondo e invia un conferma negativa al secondo, Pub/Sub consegna i messaggi ogni circa 500 millisecondi. In alternativa, se l'abbonato push invia cinque riconoscimenti negativi al secondo, Pub/Sub recapita i messaggi ogni 30-60 secondi.

Tieni presente le seguenti considerazioni sul backoff push:

  • Il backoff push non può essere attivato o disattivato. Inoltre, non puoi modificare i valori utilizzati per calcolare il ritardo.
  • Applica gli attivatori di backoff alle seguenti azioni:
    • Quando viene ricevuto un riconoscimento negativo.
    • Alla scadenza della scadenza di conferma di un messaggio.
  • Il backoff push si applica a tutti i messaggi di una sottoscrizione (globale).

Percentuale di pubblicazione

Pub/Sub regola il numero di richieste push concorrenti utilizzando un algoritmo di inizio graduale. Il numero massimo consentito di richieste push in parallelo è la finestra push. La finestra push aumenta in caso di invio riuscito e diminuisce in caso di errore. Il sistema inizia con una piccola dimensione della finestra di una sola cifra.

Quando un abbonato conferma i messaggi, la finestra aumenta in modo esponenziale. Per le sottoscrizioni in cui gli iscritti confermano più del 99% dei messaggi e hanno una latenza media delle richieste push inferiore a un secondo, la finestra push deve essere ampliata in modo da stare al passo con il throughput di pubblicazione.

La latenza della richiesta push include quanto segue:

Dopo 3000 messaggi in attesa per regione, la finestra aumenta in modo lineare per impedire all'endpoint push di ricevere troppi messaggi. Se la latenza media supera un secondo o l'abbonato conferma meno del 99% delle richieste, la finestra diminuisce fino al limite inferiore di 3000 messaggi in attesa.

Per ulteriori informazioni sulle metriche che puoi utilizzare per monitorare l'invio push, consulta Monitorare le sottoscrizioni push.

Quote e limiti

Gli abbonamenti push sono soggetti a un insieme di quote e limiti di risorse.

Passaggi successivi