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 dei messaggi in un argomento Pub/Sub.
Se non hai familiarità con Pub/Sub, consulta una delle guide rapide e scopri come eseguire Pub/Sub utilizzando la console, gcloud CLIo le librerie client.
Passa all'azione in base alla risposta della pubblicazione
Al termine della chiamata di pubblicazione della libreria client di alto livello, viene restituito un oggetto future che contiene il risultato dell'operazione. Per evitare di bloccare le singole richieste di pubblicazione, gestisci il risultato in modo asincrono. Dovresti 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).
- Ritenta la pubblicazione in caso di errore potenzialmente temporaneo, ad esempio un errore
Deadline exceeded. - Rendi persistente 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 foundoPermission 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 ai sottoscrittori come previsto, verifica di monitorare i risultati delle pubblicazioni e che le pubblicazioni siano andate a buon fine.
Allega una sottoscrizione o attiva la conservazione degli argomenti prima di iniziare la pubblicazione
Se inizi a pubblicare in un argomento a cui non è collegato alcun sottoscrittore, i messaggi non vengono conservati. Questi messaggi non possono essere recapitati alle sottoscrizioni collegate successivamente. Pertanto, prima di iniziare a pubblicare i messaggi, esegui una delle seguenti operazioni:
Allega una sottoscrizione a un argomento. Scegli uno dei seguenti metodi:
Crea una sottoscrizione e specifica un argomento durante la procedura. Scopri come creare una sottoscrizione pull, sottoscrizione push, sottoscrizione BigQuery, o una sottoscrizione Cloud Storage.
Seleziona una sottoscrizione predefinita quando crei un argomento.
Attiva la conservazione dei messaggi dell'argomento.
La conservazione dei messaggi dell'argomento consente a una sottoscrizione di riprodurre i messaggi pubblicati prima della creazione di una sottoscrizione. Se la conservazione dei messaggi dell'argomento è abilitata, i costi di archiviazione per i messaggi conservati dall'argomento vengono fatturati al progetto in cui si trova l'argomento.
Configurare la messaggistica batch
In Pub/Sub, la messaggistica batch si riferisce alla procedura 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 è abilitato per impostazione predefinita. Il batch (o il raggruppamento) dei messaggi aiuta il publisher a migliorare la propria efficienza e a inviare messaggi con una velocità effettiva più elevata. Il batch riduce il costo di pubblicazione dei dati. Tuttavia, il batch crea anche latenza per i singoli messaggi perché il publisher 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 per la pubblicazione di un messaggio da parte di un publisher e per la consegna ai sottoscrittori corrispondenti per l'elaborazione.
La latenza di pubblicazione è il tempo necessario per pubblicare un messaggio.
Quando si utilizza il batch, 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 a dimensioni della richiesta di messaggi, numero di messaggi e 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, due 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 di messaggi successivo.
Per configurare la messaggistica batch per un client publisher, consulta Raggruppare i messaggi in batch in una richiesta di pubblicazione.
Configurare 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é la pubblicazione dei messaggi non riesce 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 impedisce che le risorse del client publisher vengano sovraccaricate da un numero eccessivo di richieste in sospeso.
Se il client publisher diventa vincolato 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 libreria client supporta il controllo del flusso del publisher e per configurare lo, consulta Controllo del flusso.
Comprendere la larghezza di banda e la latenza della rete
La velocità effettiva del publisher è limitata 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ò aiutarti a risolvere i problemi di rete lato client.
La velocità effettiva del publisher è anche vincolata 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 il rendimento dello streaming, consulta Testare i client Cloud Pub/Sub per massimizzare il rendimento dello streaming.
Modificare le variabili della richiesta di ripetizione per le pubblicazioni non riuscite
Quando un messaggio viene pubblicato da un client publisher, potresti riscontrare errori di pubblicazione. In genere, questi errori sono causati da colli di bottiglia lato client, ad esempio CPU di servizio insufficienti, thread non integri o congestione della rete. Il publisher retry policy determina il comportamento in caso di errore di consegna dei messaggi. Il criterio di ripetizione definisce il numero di volte in cui 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 a eseguire 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 a100 milliseconds * 4 = 400 millisecondsper il secondo tentativo e fino a400 milliseconds * 4 = 1600 millisecondsper il terzo tentativo.maxRetryDelay. Il ritardo massimo che il publisher attende prima di riprovare a eseguire 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 timeout RPC. Il valore predefinito è
4.0. Ciò significa che il timeout per la chiamata RPC è fino a5 seconds * 4 = 20 secondsper il secondo tentativo e fino a10 seconds * 4 = 40 secondsper 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. Include il tempo trascorso in attesa del completamento della chiamata RPC e il tempo trascorso in attesa tra i tentativi. Il valore predefinito è
600 seconds.
Modifica i 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 numero elevato di messaggi non richiede l'aumento dei valori initialRetryDelay e maxRetryDelay. Tuttavia, in queste circostanze puoi modificare il controllo del flusso e il batch. Se pubblichi 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, consulta
Le operazioni di pubblicazione non riescono con DEADLINE_EXCEEDED.
Utilizzare il criterio 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 resi persistenti al di fuori di un insieme di Google Cloud regioni specificate, indipendentemente dalla provenienza delle richieste di pubblicazione.
Utilizza il criterio di archiviazione dei messaggi per specificare un elenco di Google Cloud regioni in cui Pub/Sub può 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 in 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 dell'argomento individuale 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 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 endpoint regionali. L'ordinamento dei messaggi viene mantenuto lato 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 messaggi vengono pubblicati nella stessa regione, ma i sottoscrittori sono distribuiti in più regioni, i sottoscrittori ricevono tutti i messaggi in ordine. Utilizza un endpoint regionale per pubblicare i messaggi nella stessa regione.
Configura una funzione di ripresa della pubblicazione. Quando una libreria client ritenta una richiesta e il messaggio ha una chiave di ordinamento, la libreria client ritenta ripetutamente la richiesta, indipendentemente dalle impostazioni di ripetizione. Se si verifica un errore non irreversibile, 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 |
| Raggruppa i messaggi in batch in una richiesta di pubblicazione | Raggruppa i messaggi in batch per aumentare l'efficienza del publisher e inviare messaggi con una velocità effettiva più elevata. |
| Controllo del flusso | Configura il controllo del flusso nelle impostazioni del publisher per gestire i picchi di traffico temporanei. |
| Testare i client Pub/Sub per massimizzare il rendimento dello streaming | Aumenta la velocità effettiva del publisher con un aumento dei core della macchina e della larghezza di banda della rete disponibili. |
| Richieste di ripetizione | Modifica i valori specificati del criterio di ripetizione 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 posizioni specifiche. |
| Utilizza un endpoint regionale quando utilizzi le chiavi di ordinamento nella pubblicazione | Quando utilizzi la messaggistica ordinata, utilizza un endpoint regionale e configura una funzione di ripresa della pubblicazione per gli errori di pubblicazione. |