Sottoscrizioni push

Questo documento fornisce una panoramica di una sottoscrizione push, del relativo flusso di lavoro e 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. Funzionano bene anche con serverless e con scalabilità automatica tecnologie di servizio, come le funzioni di Cloud Run, Cloud Run e Google Kubernetes Engine.

Prima di iniziare

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

Flusso di lavoro della sottoscrizione push

In una sottoscrizione push, un server Pub/Sub avvia una richiesta il client sottoscrittore per la consegna dei messaggi.

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

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 a il client sottoscrittore in un endpoint preconfigurato. Questa richiesta viene visualizzata come PushRequest nell'immagine.
  2. L'endpoint conferma il messaggio restituendo uno stato HTTP di operazione riuscita le API nel tuo codice. Una risposta non riuscita indica che Pub/Sub deve inviare di nuovo i messaggi. Questa risposta viene visualizzata come PushResponse nel dell'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 di scrivere messaggi nella sottoscrizione. Per ulteriori informazioni, consulta la sezione sulle proprietà di abbonamento.

In che modo gli endpoint push ricevono i messaggi

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

  • Avvolto. Pub/Sub invia il messaggio nel corpo JSON di un Richiesta di POST.
  • Senza imballaggio. Pub/Sub invia i dati non elaborati dei messaggi direttamente il 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 dei messaggi si trovano message.data con codifica 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 una 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 serie 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 il scadenza di conferma scade, Pub/Sub invia nuovamente il messaggio. Non puoi modificare scadenza di conferma dei singoli messaggi che ricevi dal push abbonamenti.

Autenticazione per le sottoscrizioni push

Se un abbonamento 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 della modifica può richiedere diversi minuti.

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

Push backoff

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 respingimento, interrompe la consegna dei messaggi per una quantità predeterminata nel tempo. 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 dei 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 una conferma negativa al secondo, Pub/Sub restituisce ogni 500 millisecondi circa. 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 del push:

  • Il backoff push non può essere attivato o disattivato. Inoltre, non puoi modificare i valori utilizzati per calcolare il ritardo.
  • Il backoff di push viene attivato nelle seguenti azioni:
    • Quando viene ricevuta una conferma negativa.
    • Quando scade la scadenza di conferma di un messaggio.
  • Il push backoff si applica a tutti i messaggi in una sottoscrizione (globale).

Percentuale di pubblicazione

Pub/Sub regola il numero di richieste push simultanee utilizzando un slow-start algoritmo. Il numero massimo consentito di richieste push simultanee è la finestra push. La finestra push aumenta per ogni distribuzione riuscita diminuisce in caso di errori. Il sistema inizia con una piccola finestra di una sola cifra dimensioni.

Quando un abbonato conferma i messaggi, la finestra aumenta in modo esponenziale. Per sottoscrizioni in cui i sottoscrittori confermano di oltre il 99% dei messaggi meno di un secondo di latenza delle richieste push, la finestra di push dovrebbe abbastanza da rimanere al passo con la velocità effettiva 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