Durante la pubblicazione, un client publisher invia un messaggio a un argomento Pub/Sub. Ecco 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 mai utilizzato Pub/Sub, consulta una delle guide rapide e scopri come eseguire Pub/Sub utilizzando la console, gcloud CLI o 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. 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 corretta di tutti i messaggi).
- Riprova a pubblicare in caso di un 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, come
Not foundoPermission denied. - Propaga gli errori al servizio upstream che ti ha inviato il messaggio che hai provato a pubblicare.
Se ritieni che Pub/Sub non stia recapitando i messaggi come previsto ai tuoi sottoscrittori, verifica di monitorare i risultati delle pubblicazioni e che queste siano andate a buon fine.
Se la pubblicazione va a buon fine, il risultato della chiamata di pubblicazione è l'ID messaggio del messaggio pubblicato.
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.
Collega una sottoscrizione 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 recapitati alle sottoscrizioni collegate successivamente. Pertanto, prima di iniziare a pubblicare messaggi, esegui una delle seguenti operazioni:
Collega una sottoscrizione a un argomento. Scegli uno dei seguenti metodi:
Crea una sottoscrizione e specifica un argomento durante il processo. Scopri come creare una sottoscrizione pull, una sottoscrizione push, una 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 di un argomento consente a una sottoscrizione di ripetere i messaggi pubblicati prima della creazione di una sottoscrizione. Se la conservazione dei messaggi di un argomento è abilitata, i costi di archiviazione per i messaggi conservati dall'argomento vengono addebitati al progetto in cui si trova l'argomento.
Configura 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 un'unica richiesta di pubblicazione. Se utilizzi le librerie client per pubblicare i messaggi, il raggruppamento in batch è abilitato per impostazione predefinita. Il raggruppamento dei messaggi aiuta il publisher a migliorare la propria efficienza e a inviare messaggi con un throughput più elevato. Il raggruppamento in batch riduce i costi di pubblicazione dei dati. Tuttavia, il raggruppamento in 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 la sua consegna ai sottoscrittori corrispondenti per l'elaborazione.
La latenza di pubblicazione è il tempo necessario per pubblicare un messaggio.
Quando utilizzi il raggruppamento in batch, 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 di raggruppamento in batch, puoi trovare il giusto equilibrio tra costo, velocità effettiva e latenza in base al tuo caso d'uso.
I valori predefiniti per le variabili di messaggistica in 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 batch di messaggi successivo.
Per configurare la messaggistica batch per un client publisher, consulta Messaggi batch in una richiesta di pubblicazione.
Configura il controllo di 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 fino a quando la pubblicazione dei messaggi non riesce con un errore Deadline exceeded.
Per gestire i picchi temporanei nella pubblicazione dei messaggi, puoi utilizzare il controllo di flusso nelle impostazioni del publisher. Il controllo di flusso lato publisher impedisce che le risorse client del publisher vengano sovraccaricate da troppe richieste in attesa.
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 di flusso nella libreria client, imposta i valori appropriati per le variabili numero massimo di messaggi in sospeso e numero massimo di byte di messaggi in sospeso. Questi valori bilanciano la velocità effettiva dei messaggi e la capacità del sistema.
Per verificare se la libreria client supporta il controllo di flusso del publisher e per configurarlo, consulta Controllo di flusso.
Informazioni sulla larghezza di banda e sulla 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 è consigliabile sovraccaricare il sistema con molte richieste di piccole dimensioni. Il controllo di flusso lato publisher può essere utile in caso di problemi di rete lato client.
Anche la portata del publisher è limitata dalla CPU e dalla memoria. Un numero maggiore 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 nuovo tentativo per le pubblicazioni non riuscite
Quando un messaggio viene pubblicato da un client publisher, potresti riscontrare errori di pubblicazione. Questi errori sono in genere causati da colli di bottiglia lato client, come CPU di servizio insufficienti, stato dei thread non ottimale o congestione della rete. publisher retry policy determina il comportamento in caso di errore di recapito dei messaggi. La policy di ripetizione definisce il numero di volte in cui Pub/Sub tenta di recapitare il messaggio e l'intervallo 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 nuovi tentativi. Il valore predefinito è
4. Ciò significa che il ritardo tra i nuovi tentativi è fino a100 milliseconds * 4 = 400 millisecondsper il secondo nuovo tentativo e fino a400 milliseconds * 4 = 1600 millisecondsper il terzo nuovo 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 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. Sono inclusi il tempo di attesa per il completamento della chiamata RPC e il tempo di attesa tra i nuovi 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 numero elevato di messaggi non richiede l'aumento dei valori initialRetryDelay e maxRetryDelay. Tuttavia, in questi casi puoi regolare il controllo di flusso e il raggruppamento in 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 vanno a buon fine con DEADLINE_EXCEEDED.
Utilizza la policy di archiviazione dei messaggi per garantire la località dei dati
La policy 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 regioniGoogle Cloud specificate da te, indipendentemente dall'origine delle richieste di pubblicazione.
Utilizza la policy di archiviazione dei messaggi per specificare un elenco di regioni Google Cloud in cui Pub/Sub è autorizzato ad 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. La policy può essere configurata su un argomento o come policy dell'organizzazione per un progetto, una cartella di progetto o un'intera organizzazione. Quando viene configurata una policy dell'organizzazione, la policy di un singolo argomento può essere modificata solo in modo da non violare la policy dell'organizzazione.
Ad esempio, un'azienda che opera in Europa potrebbe utilizzare la policy di archiviazione dei messaggi per garantire che tutti i dati siano archiviati nelle regioni dell'UE per rispettare le leggi locali.
Per saperne di più, consulta Configura le policy di archiviazione dei messaggi.
Best practice per la messaggistica ordinata nella pubblicazione
Se utilizzi l'ordinamento dei messaggi, assicurati di quanto segue:
Utilizza endpoint di località. L'ordine dei messaggi viene conservato 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 i messaggi vengono pubblicati tutti nella stessa regione, ma i sottoscrittori sono distribuiti in più regioni, i sottoscrittori ricevono tutti i messaggi in ordine. Utilizza un endpoint di località per pubblicare i 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 dei 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 una pubblicazione non riuscita, chiama il metodo
resumePublish.
Riepilogo delle best practice
La seguente tabella riassume le best practice consigliate in questo documento:
| Argomento | Attività |
|---|---|
| Configura la conservazione dei messaggi | Collega una sottoscrizione prima di pubblicare o attivare la conservazione dei messaggi. |
| Raggruppa i messaggi in una richiesta di pubblicazione | Raggruppa i messaggi per aumentare l'efficienza del publisher e invia i messaggi con una velocità effettiva più elevata. |
| Controllo del flusso | Configura il controllo di flusso nelle impostazioni del publisher per gestire i picchi di traffico temporanei. |
| Test dei client Pub/Sub per massimizzare le prestazioni di streaming | Scala la velocità effettiva del publisher con un aumento dei core della macchina e della larghezza di banda di rete disponibili. |
| Riprova le richieste | Apporta modifiche ai valori specificati della policy di ripetizione del publisher solo se ritieni che le impostazioni predefinite non siano sufficienti per il tuo caso d'uso. |
| Configura le policy di archiviazione dei messaggi | Utilizza la policy di archiviazione dei messaggi per archiviare i dati dei messaggi su disco solo in località specifiche. |
| Utilizza un endpoint di località quando utilizzi le chiavi di ordinamento nella pubblicazione | Quando utilizzi la messaggistica ordinata, utilizza un endpoint di località e configura una funzione di ripresa della pubblicazione per gli errori di pubblicazione. |