Best practice per abbonarsi a un argomento Pub/Sub

Con la sottoscrizione, un client sottoscrittore riceve messaggi da un argomento Pub/Sub. Ecco alcune best practice per la sottoscrizione a Pub/Sub.

Questo documento presuppone che tu abbia già familiarità con la procedura di sottoscrizione a un argomento Pub/Sub e di ricezione dei messaggi nel tuo client sottoscrittore.

Se non hai mai utilizzato Pub/Sub, consulta una delle guide rapide e scopri come eseguire Pub/Sub utilizzando la console, Google Cloud CLI o le librerie client.

Scegli l'abbonamento giusto

Pub/Sub offre sottoscrizioni standard come le sottoscrizioni push e pull. Oltre alle sottoscrizioni standard, Pub/Sub offre anche sottoscrizioni di esportazione che ti consentono di archiviare i messaggi direttamente in una risorsaGoogle Cloud , senza richiedere Dataflow come intermediario. Ad esempio, le sottoscrizioni BigQuery archiviano i messaggi in una tabella BigQuery.

Le sottoscrizioni push sono consigliate per i seguenti scenari:

  • Non puoi includere nell'applicazione subscriber codice che importa la libreria client come dipendenza.

  • Il client del sottoscrittore non può effettuare richieste in uscita.

  • Vuoi utilizzare la stessa istanza per elaborare i messaggi di argomenti e sottoscrizioni diversi in cui il client del sottoscrittore non conosce l'elenco delle sottoscrizioni.

Per i casi generali, ti consigliamo di utilizzare la libreria client di alto livello. Se invece utilizzi il pull unario, non impostare returnImmediately su true. Se imposti questo parametro su true, le prestazioni di pull ne risentono negativamente. Il campo returnImmediately è ora deprecato.

Elabora i messaggi prima di confermarli

Per impostazione predefinita, Pub/Sub elimina un messaggio da una sottoscrizione dopo che è stato confermato. Se non elabori un messaggio prima di inviare una conferma e l'elaborazione non va a buon fine, il servizio non invia nuovamente il messaggio. L'eccezione si verifica quando hai configurato la conservazione dei messaggi confermati o la conservazione degli argomenti ed esegui un'operazione di ricerca.

Se hai sottoscrittori con latenza elevata, potresti dover impostare valori personalizzati per il controllo di flusso e la gestione dei lease.

Conserva gli ID messaggio

Per semplificare la risoluzione dei problemi, i publisher e i sottoscrittori devono conservare gli ID messaggio dei messaggi pubblicati. Puoi archiviare l'ID di ogni messaggio pubblicato o attivare il logging degli ID messaggio in base alle tue esigenze. La conservazione degli ID messaggio semplifica la risoluzione dei problemi relativi a messaggi duplicati, nuovi invii, perdita di dati e altri problemi comuni. Per saperne di più, consulta Gestione dei duplicati.

Configura il controllo di flusso dei sottoscrittori per i picchi di traffico temporanei

Il controllo di flusso sul lato del sottoscrittore consente di evitare che i sottoscrittori vengano sovraccaricati da picchi di traffico. Può dare ai meccanismi di scalabilità automatica il tempo di rispondere a un carico maggiore o può distribuire l'elaborazione del carico su un periodo di tempo più lungo. Il primo metodo riduce la latenza, mentre il secondo riduce i costi.

Per configurare il controllo di flusso, devi impostare i valori appropriati per maximum outstanding messages e total outstanding message bytes. I valori predefiniti di queste variabili di controllo di flusso e i nomi delle variabili potrebbero variare a seconda delle librerie client.

  • Numero massimo di messaggi in sospeso definisce il numero massimo di messaggi recapitati al client per i quali Pub/Sub non ha ricevuto conferme o conferme negative.

  • Byte totali dei messaggi in sospeso definisce la dimensione totale massima dei messaggi recapitati al client per i quali Pub/Sub non ha ricevuto conferme o conferme negative.

Se il limite per una di queste opzioni viene superato, il client sottoscrittore non esegue il pull di altri messaggi. Questo comportamento continua finché i messaggi già estratti non vengono confermati o confermati negativamente. In questo modo, puoi trovare un compromesso tra la velocità effettiva e il costo associato all'esecuzione di più sottoscrittori.

Gestisci i recapiti duplicati

Per impostazione predefinita, Pub/Sub fornisce la consegna "at-least-once" dei messaggi ai sottoscrittori. Ciò significa che i messaggi possono essere recapitati più volte, anche se sono stati confermati. Le sezioni seguenti descrivono come gestire gli scenari di nuovo invio più comuni.

Nuovo invio coerente di molti messaggi

Se riscontri casi in cui molti messaggi vengono sempre inviati di nuovo, significa che i tuoi iscritti sono sovraccarichi o non confermano la ricezione dei messaggi prima della scadenza.

Se utilizzi una sottoscrizione pull, potrebbe essere necessario impostare valori personalizzati per i valori di controllo di flusso o aumentare i periodi di estensione del lease utilizzando la gestione dei lease.

Se utilizzi le sottoscrizioni push, potrebbe essere necessario aumentare l'impostazione della scadenza della conferma. Puoi anche seguire le best practice su come mantenere un abbonamento integro.

Nuovo invio occasionale dei messaggi

Se vedi che i messaggi vengono inviati nuovamente prima della scadenza della conferma di ricezione o dopo che sono stati confermati entro pochi secondi, Pub/Sub si comporta come previsto. Non dovresti vedere spesso questi picchi di nuovi invii, ma quando si verificano, è probabile che interessino più messaggi contemporaneamente. Il tuo sistema deve essere progettato per tollerare questi duplicati occasionali.

Nuovo invio ripetuto di alcuni messaggi

Se vedi che un numero ridotto di messaggi viene consegnato più volte, verifica innanzitutto di averli confermati. In caso contrario, scopri perché il tuo sottoscrittore non gestisce i messaggi correttamente. Ti consigliamo di configurare un argomento messaggi non recapitabili per evitare ulteriori nuovi invii. Se confermi il messaggio, Pub/Sub potrebbe comunque funzionare come previsto. Sebbene sia molto raro, è comunque possibile che un numero ridotto di messaggi venga recapitato più volte in caso di interruzioni della rete o dell'hardware interne. In questi casi, il servizio tenta di eseguire la riparazione automatica, ma l'attivazione delle correzioni può richiedere diversi minuti.

Il tuo sistema deve essere tollerante ai nuovi invii. Puoi ridurre la probabilità che si verifichino assicurandoti di elaborare e confermare i messaggi il più rapidamente possibile.

Se la tua applicazione non può tollerare duplicati, puoi attivare la consegna exactly-once. Ricorda che questa funzionalità è disponibile solo per le sottoscrizioni pull e che comporta anche una latenza di pubblicazione-sottoscrizione più elevata. Prima di attivare questa funzionalità, valuta se il compromesso di una latenza più elevata è accettabile per il tuo caso d'uso.

Best practice per l'ordinamento dei messaggi nella sottoscrizione

Se utilizzi l'ordinamento dei messaggi, assicurati di quanto segue:

  • Scegli tra sottoscrizioni StreamingPull o Pull. Per una sottoscrizione push, Pub/Sub supporta un solo messaggio in sospeso alla volta per ogni chiave di ordinamento. L'invio di richieste push parallele in uno scenario di questo tipo sarebbe simile all'invio simultaneo di più batch di messaggi per la stessa chiave di ordinamento ai sottoscrittori pull. Pertanto, le sottoscrizioni push non sono consigliate per gli argomenti in cui vengono pubblicati frequentemente più messaggi con la stessa chiave di ordinamento o in cui la latenza è estremamente importante.

  • Abilita l'ordinamento dei messaggi nella sottoscrizione. Sul lato publisher, se invii messaggi con una chiave di ordinamento e nella stessa regione, puoi configurare i sottoscrittori in modo che ricevano i messaggi in ordine. Sul lato sottoscrittore, attiva la proprietà di ordinamento dei messaggi solo per le sottoscrizioni per le quali vuoi ricevere messaggi ordinati. A seconda dello stato della proprietà, ogni sottoscrizione collegata all'argomento può determinare se ha bisogno della distribuzione in ordine senza influire sulle altre.

  • Conferma i messaggi in ordine. Quando utilizzi la distribuzione ordinata, le conferme di ricezione dei messaggi successivi non vengono elaborate finché non vengono elaborate le conferme di ricezione dei messaggi precedenti per chiave di ordinamento. Ad esempio, se hai i messaggi 1, 2 e 3 con la stessa chiave di ordinamento e li ricevi tutti, ma confermi solo il messaggio 3, il servizio non considera il messaggio 3 come confermato finché non vengono confermati anche i messaggi 1 e 2. Se le conferme per i messaggi 1 e 2 non vengono mai ricevute, i messaggi 1, 2 e 3 vengono tutti inviati di nuovo.

Riepilogo delle best practice

La seguente tabella riassume le best practice consigliate in questo documento:

Argomento Attività
Scegli un tipo di sottoscrizione Scegli il tipo di abbonamento più adatto alle esigenze della tua attività. Se supportata dalla tua sottoscrizione, utilizza anche la libreria client di alto livello.
Riproduci di nuovo un messaggio confermato Elabora un messaggio prima di confermarlo. In alternativa, configura un'operazione di ricerca in modo da non perdere i messaggi confermati.
Controllo del flusso Configura il controllo di flusso nelle impostazioni del sottoscrittore per assicurarti che i sottoscrittori non vengano sovraccaricati fino all'attivazione della scalabilità automatica o al trascorrere del tempo.
Gestisci le consegne duplicate e conserva gli ID messaggio Conserva o attiva il logging dei messageId ricevuti per semplificare la risoluzione dei problemi relativi a duplicati, nuovi invii e messaggi mancanti.
Ordinamento dei messaggi Quando utilizzi la messaggistica ordinata, scegli StreamingPull o Pull, attiva l'ordinamento dei messaggi nella sottoscrizione e conferma i messaggi in ordine.

Passaggi successivi