Best practice per pubblicare in un argomento Pub/Sub

Durante la pubblicazione, un client publisher invia un messaggio a un argomento Pub/Sub. Di seguito sono riportate alcune best practice per la pubblicazione di messaggi in Pub/Sub.

Questo documento presuppone che tu abbia già dimestichezza con la procedura di pubblicazione di messaggi in un argomento Pub/Sub.

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

Collega una sottoscrizione o attiva la conservazione degli argomenti prima di iniziare a pubblicare

Se inizi a pubblicare in un argomento a cui non è associato alcun sottoscrittore, i messaggi non vengono conservati. Questi messaggi non possono essere recapitati agli abbonamenti aggiunti successivamente. Pertanto, prima di iniziare a pubblicare messaggi, esegui una delle seguenti operazioni:

Configurare la messaggistica batch

In Pub/Sub, i messaggi batch si riferiscono al processo di combinazione di più messaggi in un batch che viene pubblicato in una singola richiesta di pubblicazione. Se utilizzi le librerie client per pubblicare i messaggi, il batching è abilitato per impostazione predefinita. L'aggregazione (o raggruppamento) dei messaggi aiuta il publisher a migliorare l'efficienza e a inviare messaggi con un throughput più elevato. L'aggregazione riduce il costo di pubblicazione dei dati. Tuttavia, l'aggregazione crea anche latenza per i singoli messaggi perché il publisher attende che il batch venga completato prima di pubblicarlo.

La latenza in Pub/Sub può essere di due tipi:

  • La latenza end-to-end è il tempo necessario per la pubblicazione di un messaggio da parte di un editore e la sua consegna ai sottoscrittori corrispondenti per l'elaborazione.

  • La latenza di pubblicazione è il tempo necessario per pubblicare un messaggio.

Quando utilizzi il batching, l'aumento di entrambi i tipi di latenza è un compromesso per migliorare l'efficienza e il throughput.

Puoi raggruppare i messaggi in una libreria client in base alle dimensioni della richiesta di messaggio, al numero di messaggi e al tempo. Quando configuri le impostazioni batch, puoi trovare il giusto equilibrio tra costo, throughput e latenza in base alle tue esigenze.

I valori predefiniti per le variabili di messaggistica batch e i nomi delle variabili possono variare in base alle librerie client. Puoi specificare uno o tutti e tre i valori nella libreria client. Se uno dei valori per le variabili di messaggistica batch viene soddisfatto, la libreria client pubblica il batch successivo di messaggi.

Per configurare la messaggistica batch per un client publisher, consulta Raggruppare i messaggi in una richiesta di pubblicazione.

Configura il controllo del flusso per picchi di messaggi transitori

Se il client publisher deve elaborare un numero elevato di messaggi, le richieste di pubblicazione potrebbero iniziare ad accumularsi in memoria fino a quando la pubblicazione dei messaggi non viene eseguita con un errore Deadline exceeded.

Per gestire gli picchi temporanei nella pubblicazione dei messaggi, puoi utilizzare il controllo del flusso nelle impostazioni del publisher. Il controllo del flusso lato publisher impedisce alle risorse del client del publisher di essere sovraccaricate da troppe richieste in sospeso. Se il client publisher è limitato in termini di memoria, CPU o thread, viene generato un numero elevato di errori Deadline exceeded.

Per configurare il controllo flusso nella libreria client, imposta i valori appropriati per le variabili maximum outstanding messages e maximum outstanding message bytes. Questi valori bilanciano il throughput dei messaggi e la capacità del sistema.

Per verificare se la libreria client supporta il controllo del flusso del publisher e per configurarlo, consulta Controllo del flusso.

Informazioni sulla larghezza di banda e sulla latenza della rete

Il throughput del publisher è limitato dalla larghezza di banda della rete e dal numero di richieste inviate. Se la larghezza di banda è buona, ma la latenza della rete è elevata, non sovraccaricare il sistema con molte piccole richieste. Il controllo del flusso lato publisher può essere utile per risolvere i problemi di rete lato client.

La velocità effettiva del publisher è limitata anche dalla CPU e dalla memoria. Un maggior numero di core della macchina disponibili ti consente di impostare un numero maggiore di thread per una maggiore velocità effettiva di pubblicazione. Per approfondire come massimizzare le prestazioni dello streaming, consulta Testare i client Cloud Pub/Sub per massimizzare le prestazioni dello streaming.

Modificare le variabili di richiesta di ripetizione per le pubblicazioni non riuscite

Quando un messaggio viene pubblicato da un client publisher, potresti notare errori di pubblicazione. Questi errori sono in genere causati da colli di bottiglia lato client, come CPU di servizio insufficienti, stato del thread scadente o congestione della rete. publisher retry policy determina il comportamento in caso di errore di recapito del messaggio. Il criterio di ripetizione definisce il numero di volte che Pub/Sub tenta di consegnare il messaggio e la durata del tempo tra ogni tentativo.

Ad esempio, nella libreria client Java per Pub/Sub, il client publisher contiene i seguenti valori:

  • initialRetryDelay. Il ritardo iniziale che il publisher attende prima di riprovare un'operazione di pubblicazione. Il valore predefinito è 100 milliseconds.

  • retryDelayMultiplier. Il fattore di moltiplicazione utilizzato per calcolare il ritardo tra i tentativi. Il valore predefinito è 4. Ciò significa che il ritardo tra un tentativo e l'altro può essere fino a 100 milliseconds * 4 = 400 milliseconds per il secondo tentativo e fino a 400 milliseconds * 4 = 1600 milliseconds per il terzo tentativo.

  • maxRetryDelay. Il ritardo massimo che il publisher attende prima di riprovare un'operazione di pubblicazione. Il valore predefinito è 60 seconds.

  • initialRpcTimeout. Il timeout iniziale che il publisher attende per il completamento della chiamata RPC. Il valore predefinito è 5 seconds.

  • rpcTimeoutMultiplier. Il fattore di moltiplicazione utilizzato per calcolare il tempo di attesa RPC. Il valore predefinito è 4.0. Ciò significa che il tempo di attesa per la chiamata RPC può essere fino a 5 seconds * 4 = 20 seconds per il secondo tentativo e fino a 10 seconds * 4 = 40 seconds per il terzo tentativo.

  • maxRpcTimeout. Il timeout massimo che il publisher attende per il completamento della chiamata RPC. Il valore predefinito è 600 seconds.

  • totalTimeout. Il timeout totale per l'operazione di pubblicazione. Sono inclusi il tempo trascorso in attesa del completamento della chiamata RPC e il tempo trascorso in attesa tra i tentativi. Il valore predefinito è 600 seconds.

Apporta modifiche ai valori specificati solo se ritieni che le impostazioni di ripetizione predefinite non siano sufficienti per il tuo caso d'uso. Ad esempio, la pubblicazione di un gran numero di messaggi non richiede l'aumento dei valori initialRetryDelay e maxRetryDelay. Tuttavia, in queste circostanze puoi regolare il controllo flussi e il raggruppamento. Se pubblichi da una connessione a internet instabile o con una larghezza di banda limitata, puoi fare esperimenti con i valori delle variabili initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Per i valori consigliati, consulta Le operazioni di pubblicazione non riescono con DEADLINE_EXCEEDED.

Utilizza i criteri di archiviazione dei messaggi per garantire la localizzazione dei dati

Il criterio di archiviazione dei messaggi degli argomenti di Pub/Sub offre un modo per garantire che i messaggi pubblicati in un argomento non vengano mai conservati al di fuori di un insieme di regioni Google Cloud specificate, indipendentemente dall'origine delle richieste di pubblicazione.

Utilizza il criterio di archiviazione dei messaggi per specificare un elenco di regioni Google Cloud in cui Pub/Sub è autorizzato a archiviare i dati dei messaggi su disco. Quando un messaggio viene pubblicato in una regione non inclusa in questo elenco, la richiesta viene inoltrata alla regione consentita più vicina per l'elaborazione. Il criterio può essere configurato su un argomento o come criterio dell'organizzazione per un progetto, una cartella di progetti o un'intera organizzazione. Quando è configurato un criterio dell'organizzazione, il criterio di un singolo argomento puoi essere modificato solo in modi che non violino il criterio dell'organizzazione.

Ad esempio, un'azienda che opera in Europa potrebbe utilizzare il criterio di archiviazione dei messaggi per garantire che tutti i dati vengano archiviati nelle regioni dell'UE in conformità con le leggi locali.

Per ulteriori informazioni, consulta Configurare i criteri di archiviazione dei messaggi.

Best practice per la messaggistica ordinata nella pubblicazione

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

  • Utilizza gli endpoint relativi alla posizione. L'ordine dei messaggi viene mantenuto sul lato di pubblicazione e all'interno di una regione. In altre parole, se pubblichi messaggi in più regioni, solo i messaggi all'interno della stessa regione vengono recapitati in un ordine coerente. Se tutti i tuoi messaggi vengono pubblicati nella stessa regione, ma i tuoi iscritti si trovano in regioni diverse, i messaggi vengono ricevuti in ordine. Utilizza un endpoint geografico per pubblicare messaggi nella stessa regione.

  • Configura una funzione di ripresa della pubblicazione. Quando una libreria client riprova una richiesta e il messaggio ha una chiave di ordinamento, la libreria client riprova ripetutamente la richiesta, indipendentemente dalle impostazioni di ripetizione. Se si verifica un errore non ripetibile, la libreria client non pubblica il messaggio e interrompe la pubblicazione di altri messaggi con la stessa chiave di ordinamento. Quando è tutto pronto per continuare la pubblicazione su una chiave di ordinamento con una pubblicazione non riuscita, chiama il metodo resumePublish.

Riepilogo delle best practice

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

Argomento Attività
Configura la conservazione dei messaggi Allega una sottoscrizione prima di pubblicare o attivare la conservazione dei messaggi.
Raggruppare i messaggi in una richiesta di pubblicazione Raggruppa i messaggi per aumentare l'efficienza del publisher e inviali con una maggiore velocità in uscita.
Controllo del flusso Configura il controllo del flusso nelle impostazioni del publisher per gestire i picchi di traffico temporanei.
Test dei clienti Pub/Sub per massimizzare il rendimento dello streaming Scala la velocità effettiva del publisher con un aumento del numero di core e della larghezza di banda di rete disponibili.
Richieste di nuovo tentativo Modifica i valori specificati del criterio di ripetizione dell'editore solo se ritieni che le impostazioni predefinite non siano sufficienti per il tuo caso d'uso.
Configurare i criteri di archiviazione dei messaggi Utilizza il criterio di archiviazione dei messaggi per archiviare i dati dei messaggi su disco solo in posizioni specifiche.
Utilizzare un endpoint di località quando si utilizzano le chiavi di ordinamento nella pubblicazione Quando utilizzi la messaggistica ordinata, utilizza un endpoint geografico e configura una funzione di ripresa della pubblicazione per gli errori di pubblicazione.

Passaggi successivi