Sottoscrizioni push

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

Nella distribuzione push, Pub/Sub avvia richieste alla tua applicazione sottoscrittore per consegnare i messaggi. I messaggi vengono inviati a un server o a un webhook indirizzabile pubblicamente, ad esempio una richiesta POST HTTPS.

Le sottoscrizioni push riducono al minimo le dipendenze dalle librerie client specifiche di Pub/Sub e dai meccanismi di autenticazione. Funzionano bene anche con le tecnologie di servizi serverless e di scalabilità automatica, come Cloud Run Functions, 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 al client sottoscrittore per consegnare i messaggi.

L'immagine seguente mostra il flusso di lavoro tra un client sottoscrittore e una sottoscrizione 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 a cui fa riferimento la Figura 3:

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

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à degli abbonamenti.

Come gli endpoint push ricevono i messaggi

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

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

I seguenti esempi mostrano un corpo di una richiesta JSON POST 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 richieste POST che Pub/Sub invia all'endpoint push. Per ulteriori informazioni sull'elaborazione di queste richieste POST in App Engine, consulta Scrittura di messaggi Pub/Sub e risposta a tali messaggi.

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

  • 102
  • 200
  • 201
  • 202
  • 204

Per inviare un riconoscimento negativo per il messaggio, restituisci qualsiasi altro codice di stato. Se invii un riconoscimento negativo o la scadenza di riconoscimento scade, Pub/Sub invia nuovamente il messaggio. Non puoi modificare la scadenza di conferma dei singoli messaggi che ricevi dagli abbonamenti 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 saperne di più sulla configurazione dell'autenticazione, consulta Autenticare le richieste push.

Interrompere e riprendere la distribuzione dei messaggi

Per impedire temporaneamente a Pub/Sub di inviare richieste all'endpoint push, modifica l'abbonamento in pull. Il passaggio può richiedere diversi minuti per avere effetto.

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

Backoff push

Se un sottoscrittore push invia troppi riconoscimenti negativi, Pub/Sub potrebbe iniziare a recapitare 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. Trascorso il tempo, Pub/Sub riprende a recapitare 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 risposte negative che gli abbonati push inviano.

Ad esempio, se un sottoscrittore push riceve cinque messaggi al secondo e invia un riconoscimento negativo al secondo, Pub/Sub recapita i messaggi circa ogni 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.
  • I trigger di backoff vengono attivati dalle seguenti azioni:
    • Quando viene ricevuto un riconoscimento negativo.
    • Quando scade la 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 simultanee utilizzando un algoritmo di avvio lento. Il numero massimo consentito di richieste push simultanee è la finestra push. La finestra di push aumenta in caso di consegna riuscita e diminuisce in caso di errore. Il sistema inizia con una piccola dimensione della finestra a una sola cifra.

Quando un abbonato conferma i messaggi, la finestra aumenta in modo esponenziale. Per le sottoscrizioni in cui i sottoscrittori confermano più del 99% dei messaggi e la latenza media delle richieste push è inferiore a un secondo, la finestra push deve espandersi a sufficienza per tenere il passo con qualsiasi velocità effettiva di pubblicazione.

La latenza della richiesta push include quanto segue:

Dopo 3000 messaggi in sospeso per regione, la finestra aumenta linearmente per impedire all'endpoint push di ricevere troppi messaggi. Se la latenza media supera un secondo o l'abbonato riconosce meno del 99% delle richieste, la finestra si riduce al limite inferiore di 3000 messaggi in sospeso.

Per ulteriori informazioni sulle metriche che puoi utilizzare per monitorare la distribuzione push, consulta Monitoraggio delle sottoscrizioni push.

Quote e limiti

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

Passaggi successivi