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 su Pub/Sub.

Questo documento presuppone che tu abbia già familiarità 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, interfaccia a riga di comando gcloud o le librerie client.

Intervenire in base alla risposta alla pubblicazione

Al termine della chiamata di pubblicazione della libreria client di alto livello, viene restituito un oggetto futuro che contiene il risultato dell'operazione. Per evitare di bloccare le singole richieste di pubblicazione, gestisci il risultato in modo asincrono. Devi decidere il modo migliore per gestire l'errore per il tuo caso d'uso. Di·seguito·riportiamo alcune·delle·opzioni:

  • Registra l'errore e non fare altro (se il tuo caso d'uso non richiede la pubblicazione riuscita di tutti i messaggi).
  • Riprova a pubblicare in caso di errore potenzialmente temporaneo, ad esempio un errore Deadline exceeded.
  • Salva il messaggio in un file o in uno spazio di archiviazione per riprovare a pubblicarlo in un secondo momento, soprattutto in caso di errore che richiede l'intervento dell'utente, ad esempio Not found o Permission denied.
  • Propaga gli errori al servizio upstream che ti ha inviato il messaggio che hai tentato di pubblicare.

Se ritieni che Pub/Sub non recapiti i messaggi come previsto ai tuoi iscritti, verifica di monitorare i risultati delle pubblicazioni e che le pubblicazioni siano andate a buon fine.

Collega un abbonamento o attiva la conservazione degli argomenti prima di iniziare la pubblicazione

Se inizi a pubblicare in un argomento a cui non è collegato un sottoscrittore, i messaggi non vengono conservati. Questi messaggi non possono essere consegnati alle sottoscrizioni allegate successivamente. Pertanto, prima di iniziare a pubblicare messaggi, esegui una delle seguenti operazioni:

Configurare la messaggistica batch

In Pub/Sub, la messaggistica batch si riferisce al processo di combinazione di più messaggi in un unico batch che viene pubblicato in una singola richiesta di pubblicazione. Se utilizzi le librerie client per pubblicare i messaggi, il batch è attivato per impostazione predefinita. Il raggruppamento dei messaggi aiuta l'editore a migliorare l'efficienza e a inviare messaggi con un throughput più elevato. Il batch riduce il costo di pubblicazione dei dati. Tuttavia, il batching crea anche latenza per i singoli messaggi perché l'editore attende che il batch venga riempito prima di pubblicarlo.

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

  • La latenza end-to-end è il tempo necessario a un messaggio per essere pubblicato da un editore e consegnato ai sottoscrittori corrispondenti per l'elaborazione.

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

Quando si utilizza il batching, l'aumento di entrambi i tipi di latenza è un compromesso per migliorare l'efficienza e la velocità effettiva.

Puoi raggruppare i messaggi in batch 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 costi, velocità effettiva e latenza in base 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 per le variabili di messaggistica batch, la libreria client pubblica il batch successivo di messaggi.

Per configurare la messaggistica batch per un client publisher, consulta Messaggi batch 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 gestire i picchi transitori nella pubblicazione dei messaggi, puoi utilizzare il controllo del flusso nelle impostazioni del publisher. Il controllo del flusso lato publisher impedisce che le risorse client del publisher vengano sovraccaricate da un numero eccessivo di richieste in sospeso. Se il client publisher diventa 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 valori appropriati per le variabili maximum outstanding messages e maximum outstanding message bytes. 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 configurarlo, consulta Controllo del flusso.

Comprendere la larghezza di banda e la 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 di rete è elevata, non devi sovraccaricare il sistema con molte piccole richieste. Il controllo del flusso lato publisher può aiutare a risolvere i problemi di rete lato client.

Anche il throughput del publisher è vincolato dalla CPU e dalla memoria. Un maggior numero di core della macchina disponibili consente di impostare un numero di thread più elevato per una migliore velocità effettiva di pubblicazione. Per comprendere meglio come massimizzare le prestazioni di streaming, consulta Test dei client Cloud Pub/Sub per massimizzare le prestazioni di streaming.

Modifica le variabili della richiesta di ripetizione per le pubblicazioni non riuscite

Quando un messaggio viene pubblicato da un client publisher, potresti visualizzare errori di pubblicazione. Questi errori sono in genere causati da colli di bottiglia lato client, ad esempio CPU di servizio insufficienti, integrità dei thread non ottimale 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 in cui Pub/Sub tenta di inviare il messaggio e la durata di tempo tra un tentativo e l'altro.

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 i tentativi è 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 l'editore attende prima di riprovare un'operazione di pubblicazione. Il valore predefinito è 60 seconds.

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

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

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

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

Utilizzare le norme di archiviazione dei messaggi per garantire la località dei dati

Il criterio di archiviazione dei messaggi dell'argomento di Pub/Sub offre un modo per garantire che i messaggi pubblicati in un argomento non vengano mai archiviati al di fuori di un insieme di regioniTrusted Cloud by S3NS che specifichi, indipendentemente dalla provenienza delle richieste di pubblicazione.

Utilizza il criterio di archiviazione dei messaggi per specificare un elenco di regioni Trusted Cloud in cui Pub/Sub può archiviare i dati dei messaggi su disco. Quando un messaggio viene pubblicato in una regione non presente in questo elenco, la richiesta viene inoltrata alla regione consentita più vicina per l'elaborazione. 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 viene configurato un criterio dell'organizzazione, il criterio del singolo argomento può essere modificato solo in modi che non violano 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 saperne di più, consulta Configurare le norme di archiviazione dei messaggi.

Best practice per la messaggistica ordinata nella pubblicazione

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

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

  • Configura una funzione di pubblicazione del curriculum. Quando una libreria client riprova a inviare una richiesta e il messaggio ha una chiave di ordinamento, la libreria client riprova ripetutamente a inviare la richiesta, indipendentemente dalle impostazioni di riprova. Se si verifica un errore non ripristinabile, 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 con una chiave di ordinamento per cui la pubblicazione non è riuscita, chiama il metodo resumePublish.

Riepilogo delle best practice

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

Argomento Attività
Configurare la conservazione dei messaggi Allega un abbonamento prima di pubblicare o attivare la conservazione dei messaggi.
Raggruppare i messaggi in una richiesta di pubblicazione Raggruppa i messaggi per aumentare l'efficienza dell'editore e inviarli con una velocità effettiva superiore.
Controllo del flusso Configura il controllo del flusso nelle impostazioni del publisher per gestire i picchi di traffico temporanei.
Test Client Pub/Sub per massimizzare le prestazioni di streaming Aumenta la velocità effettiva dei publisher con un incremento dei core della macchina e della larghezza di banda di rete disponibili.
Richieste di riprova Modifica i valori specificati del criterio di nuovi tentativi 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 localizzazione quando si utilizzano le chiavi di ordinamento nella pubblicazione Quando utilizzi la messaggistica ordinata, utilizza un endpoint di localizzazione e configura una funzione di ripresa della pubblicazione per gli errori di pubblicazione.

Passaggi successivi