Best practice per la pubblicazione in un argomento Pub/Sub

Durante la pubblicazione, un client editore invia un messaggio a un argomento Pub/Sub. Ecco alcune best practice per pubblicare messaggi in Pub/Sub.

Questo documento presuppone che tu abbia già familiarità con il processo di pubblicazione dei 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, l'interfaccia a riga di comando di gCloud o le librerie client.

Allega una sottoscrizione o abilita la conservazione degli argomenti prima di iniziare la pubblicazione

Se inizi a pubblicare in un argomento a cui non è associato un sottoscrittore, i messaggi non vengono conservati. Non è possibile recapitare questi messaggi alle sottoscrizioni collegate in un secondo momento. Pertanto, prima di iniziare a pubblicare messaggi, esegui una delle seguenti operazioni:

Configura la messaggistica batch

In Pub/Sub, per messaggistica batch si intende il processo di combinazione di più messaggi in un batch che viene pubblicato in un'unica richiesta di pubblicazione. Se utilizzi librerie client per pubblicare i messaggi, il raggruppamento è abilitato per impostazione predefinita. Il raggruppamento (o raggruppamento) dei messaggi consente all'editore di migliorare la sua efficienza e di inviare messaggi a una velocità effettiva superiore. Il raggruppamento riduce il costo di pubblicazione dei dati. Tuttavia, il raggruppamento crea anche latenza per i singoli messaggi, perché l'editore 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 affinché un messaggio venga pubblicato da un editore e consegnato ai sottoscrittori corrispondenti per l'elaborazione.

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

Quando utilizzi il batch, aumentare entrambi i tipi di latenze è un compromesso per migliorare l'efficienza e la velocità effettiva.

Puoi raggruppare i messaggi in una libreria client in base alle dimensioni della richiesta di messaggi, al numero di messaggi e al tempo. Quando configuri le impostazioni batch, puoi trovare il giusto equilibrio tra costo, velocità effettiva e latenza, adatto al tuo caso d'uso.

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

Per configurare la messaggistica batch per un client editore, consulta Messaggi in gruppo in una richiesta di pubblicazione.

Configura il controllo del flusso per i picchi di messaggi temporanei

Se il client publisher deve elaborare un numero elevato di messaggi, le richieste di pubblicazione potrebbero iniziare ad accumularsi in memoria finché i messaggi non vengono pubblicati con un errore Deadline exceeded.

Per risolvere i picchi temporanei nella pubblicazione dei messaggi, puoi utilizzare il controllo del flusso nelle impostazioni del publisher. Il controllo del flusso lato publisher evita che le risorse del client del publisher vengano sovraccaricate con troppe richieste in sospeso. Se il client del publisher viene limitato in termini di memoria, CPU o thread, viene generato un numero elevato di errori Deadline exceeded.

Per configurare il controllo del flusso nella libreria client, imposta i valori appropriati per le variabili Numero massimo di messaggi in sospeso e byte massimi di messaggi in sospeso. Questi valori bilanciano la velocità effettiva dei messaggi e la capacità del sistema.

Per verificare se la tua libreria client supporta il controllo del flusso dell'editore e per configurarla, consulta Controllo del flusso.

Informazioni sulla larghezza di banda e sulla latenza della rete

La velocità effettiva del publisher è vincolata dalla larghezza di banda della rete e dal numero di richieste inviate. Se la larghezza di banda è buona, ma la latenza di rete è elevata, non sovraccaricare il sistema con tante richieste di piccole dimensioni. Il controllo del flusso lato publisher può essere utile in caso di problemi di rete lato client.

Anche la velocità effettiva del publisher è vincolata da CPU e memoria. Più core delle macchine disponibili consentono di impostare un numero di thread più elevato per una velocità effettiva di pubblicazione migliore. Per capire meglio come massimizzare le prestazioni dei flussi di dati, consulta Test dei client Cloud Pub/Sub per massimizzare le prestazioni dei flussi di dati.

Modifica le variabili di richiesta di nuovo tentativo per le pubblicazioni non riuscite

Quando un messaggio viene pubblicato da un client editore, potresti notare errori di pubblicazione. Questi errori sono in genere causati da colli di bottiglia lato client, come CPU di servizio insufficienti, integrità dei thread non valida o congestione della rete. publisher retry policy determina il comportamento in caso di errore di recapito dei messaggi. Il criterio per i nuovi tentativi definisce il numero di volte in cui Pub/Sub tenta di recapitare il messaggio e il periodo di tempo tra un tentativo e l'altro.

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

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

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

  • maxRiprovaDelay. Il ritardo massimo che l'editore attende prima di riprovare un'operazione di pubblicazione. Il valore predefinito è 60 seconds.

  • inizialeRpcTimeout. Il timeout iniziale che l'editore attende il completamento della chiamata RPC. Il valore predefinito è 5 seconds.

  • rpcTimeoutMultiplier. Il fattore di moltiplicazione usato per calcolare il timeout RPC. Il valore predefinito è 4.0. Ciò significa che il timeout per la chiamata RPC è pari 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 l'editore attende il completamento della chiamata RPC. Il valore predefinito è 600 seconds.

  • Timeout totale. Il timeout totale per l'operazione di pubblicazione. Ciò include il tempo di attesa per il completamento della chiamata RPC e il tempo di attesa tra un nuovo tentativo e l'altro. Il valore predefinito è 600 seconds.

Apporta modifiche ai valori specificati solo se ritieni che le impostazioni predefinite per i nuovi tentativi non siano sufficienti per il tuo caso d'uso. Ad esempio, la pubblicazione di un numero elevato di messaggi non richiede di aumentare i valori initialRetryDelay e maxRetryDelay. Tuttavia, in queste circostanze, puoi regolare il controllo del flusso e il batch. Se pubblichi da una connessione a internet instabile o con una connessione con larghezza di banda limitata, puoi sperimentare con i valori delle variabili initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Per i valori consigliati, consulta Operazioni di pubblicazione non riuscite con DEADLINE_EXCEEDED.

Usa i criteri di archiviazione dei messaggi per garantire la località dei dati

I criteri di archiviazione dei messaggi degli argomenti di Pub/Sub consentono di assicurare che i messaggi pubblicati in un argomento non siano mai resi persistenti al di fuori di un insieme di regioni di Google Cloud specificato, indipendentemente dall'origine delle richieste di pubblicazione.

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

Ad esempio, una società che opera in Europa potrebbe utilizzare le norme relative all'archiviazione dei messaggi per assicurarsi 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 di messaggi, assicurati di quanto segue:

  • Utilizza endpoint basati sulla località. 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 ordine coerente. Se i messaggi sono tutti pubblicati nella stessa regione, ma i tuoi abbonati sono distribuiti in più regioni, i sottoscrittori ricevono tutti i messaggi in ordine. Utilizza un endpoint di località per pubblicare messaggi nella stessa regione.

  • Configura una funzione per riprendere la pubblicazione. Quando una libreria client riprova una richiesta e il messaggio contiene una chiave di ordinamento, la libreria client riprova ripetutamente la richiesta, indipendentemente dalle impostazioni per i nuovi tentativi. 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 vuoi continuare a pubblicare su una chiave di ordinamento con 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 abilitare la conservazione dei messaggi.
Messaggi in gruppo in una richiesta di pubblicazione Raggruppa i messaggi in gruppo per aumentare l'efficienza del publisher e invia messaggi a una velocità effettiva superiore.
Controllo del flusso Configura il controllo del flusso nelle impostazioni del publisher per gestire picchi di traffico temporanei.
Test dei client Pub/Sub per massimizzare le prestazioni dei flussi di dati Scala la velocità effettiva del publisher con un aumento dei core delle macchine disponibili e della larghezza di banda di rete.
Riprovare le richieste Apporta modifiche ai valori specificati del criterio di nuovo tentativo del publisher solo se ritieni che le impostazioni predefinite non siano sufficienti per il tuo caso d'uso.
Configura i criteri di archiviazione dei messaggi Utilizza il criterio di archiviazione dei messaggi per archiviare i dati dei messaggi su disco solo in località specifiche.
Utilizza un endpoint località quando usi le chiavi di ordinamento nella pubblicazione Quando utilizzi la messaggistica ordinata, utilizza un endpoint località e configura una funzione di ripresa della pubblicazione per gli errori di pubblicazione.

Passaggi successivi