Iscrizioni push

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

Nella consegna push, Pub/Sub avvia le richieste all'applicazione del tuo sottoscrittore di recapitare i messaggi. I messaggi vengono recapitati a un server indirizzabile pubblicamente o a un webhook, come una richiesta POST HTTPS.

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

Prima di iniziare

Prima di leggere questo documento, assicurati di avere familiarità con quanto segue:

• Come funziona Pub/Sub e i diversi termini di Pub/Sub.

• I diversi tipi di sottoscrizioni supportati da Pub/Sub e i motivi per cui potresti utilizzare una sottoscrizione push.

Flusso di lavoro delle sottoscrizioni push

In una sottoscrizione push, un server Pub/Sub avvia una richiesta al client del tuo sottoscrittore di recapitare i messaggi.

La seguente immagine mostra il flusso di lavoro tra un client abbonato e una sottoscrizione push.

Figura 3. Flusso di lavoro per una sottoscrizione push

Di seguito è riportata 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 del sottoscrittore in un endpoint preconfigurato. Questa richiesta viene mostrata come PushRequest nell'immagine.
2. L'endpoint riconosce il messaggio restituendo un codice di stato HTTP di esito positivo. 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 riuscite.

Proprietà di una sottoscrizione push

Le proprietà configurate per una sottoscrizione push determinano il modo in cui scrivi i messaggi nella sottoscrizione. Per ulteriori informazioni, consulta le proprietà dell'abbonamento.

Modalità di ricezione dei messaggi per gli endpoint push

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

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

I seguenti esempi 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 vari 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 e risposta ai messaggi Pub/Sub.

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 una conferma negativa per il messaggio, restituisci qualsiasi altro codice di stato. Se invii una conferma negativa o se la scadenza della conferma scade, Pub/Sub invia nuovamente il messaggio. Non puoi modificare la scadenza della conferma dei singoli messaggi ricevuti dalle sottoscrizioni push.

Autenticazione per le sottoscrizioni 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, vedi Autenticare le richieste push.

Interrompere e riprendere la consegna dei messaggi

Per interrompere temporaneamente a Pub/Sub l'invio di richieste all'endpoint push, modifica la sottoscrizione 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 interrompere definitivamente la consegna, elimina l'abbonamento.

Respingi

Se un sottoscrittore push invia troppi conferme negative, Pub/Sub potrebbe iniziare a consegnare i messaggi utilizzando un push backoff. Quando Pub/Sub utilizza un backoff push, interrompe la consegna dei messaggi per un periodo di tempo prestabilito. Questo intervallo di tempo può essere compreso tra 100 millisecondi e 60 secondi. Una volta trascorso questo tempo, Pub/Sub ricomincia a consegnare i messaggi.

Nota: questa funzionalità è indipendente dal criterio relativo ai nuovi tentativi dell'abbonamento. Puoi utilizzare queste due funzionalità insieme per controllare meglio il flusso dei messaggi. In questo caso, Il ritardo totale è il valore combinato massimo del valore del pushbackoff e del valore del criterio per i nuovi tentativi. Se noti problemi di recapito dei messaggi, verifica in che modo il criterio per i nuovi tentativi interagisce con il push backoff.

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

Ad esempio, se un sottoscrittore push riceve cinque messaggi al secondo e invia un riconoscimento negativo al secondo, Pub/Sub recapita i messaggi ogni 500 millisecondi circa. Oppure, se il sottoscrittore push invia cinque conferme negative al secondo, Pub/Sub consegna i messaggi ogni 30-60 secondi.

Tieni presente le seguenti considerazioni sul push backoff:

• La funzionalità Push backoff non può essere attivata o disattivata. Non puoi modificare i valori utilizzati per calcolare il ritardo.
• Esegui il push dei trigger di backoff nelle seguenti azioni:
  • Quando viene ricevuta una conferma negativa.
  • Quando scade la scadenza per la conferma di un messaggio.
• Il push-off si applica a tutti i messaggi in una sottoscrizione (globale).

Percentuale di pubblicazione

Pub/Sub regola il numero di richieste push in parallelo utilizzando un algoritmo ad avvio lento. Il numero massimo consentito di richieste push in parallelo è la finestra push. La finestra per le notifiche push aumenta a ogni caricamento andato a buon fine e diminuisce in caso di errori. Il sistema inizia con una piccola dimensione della finestra di una sola cifra.

Quando un sottoscrittore conferma i messaggi, la finestra aumenta in modo esponenziale. Per le sottoscrizioni in cui gli abbonati riconoscono più del 99% dei messaggi e registrano in media meno di un secondo di latenza delle richieste push, la finestra push dovrebbe espandersi abbastanza da stare al passo con la velocità effettiva di pubblicazione.

La latenza della richiesta push include quanto segue:

• La latenza di rete di round trip tra i server Pub/Sub e l'endpoint push

• Il tempo di elaborazione dell'abbonato

Dopo 3000 messaggi in sospeso 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 il sottoscrittore conferma meno del 99% delle richieste, la finestra diminuisce fino al limite inferiore di 3000 messaggi in sospeso.

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

Quote e limiti

Le sottoscrizioni push sono soggette a un insieme di quotas e limiti di risorse.

Passaggi successivi

• Crea una sottoscrizione push per il tuo argomento.

• Crea o modifica una sottoscrizione con gcloud CLI.

• Creare o modificare una sottoscrizione con le API REST.

• Crea o modifica una sottoscrizione con le API RPC.