In genere, gli errori di pubblicazione sono causati da colli di bottiglia lato client, ad esempio CPU di servizio insufficienti, thread non integri o congestione della rete. Il criterio di ripetizione del publisher definisce il numero di volte in cui Pub/Sub tenta di recapitare un messaggio e la durata tra un tentativo e l'altro.
Questo documento fornisce informazioni sull'utilizzo delle richieste di ripetizione con i messaggi pubblicati in un argomento.
Prima di iniziare
Prima di configurare il flusso di lavoro di pubblicazione, assicurati di aver completato le seguenti attività:
Ruoli obbligatori
Per ottenere le autorizzazioni necessarie per riprovare a inviare richieste di messaggi a un argomento, chiedi all'amministratore di concederti il ruolo IAM Pub/Sub Publisher (roles/pubsub.publisher) sull'argomento.
Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.
Per creare o aggiornare argomenti e sottoscrizioni, sono necessarie autorizzazioni aggiuntive.
Informazioni sulle richieste di ripetizione
Le impostazioni di ripetizione controllano il modo in cui le librerie client Pub/Sub riprovano a inviare le richieste di pubblicazione. Le librerie client hanno una delle seguenti impostazioni di ripetizione:
- Timeout della richiesta iniziale: il periodo di tempo prima che una libreria client smetta di attendere il completamento della richiesta di pubblicazione iniziale.
- Ritardo di ripetizione: il periodo di tempo dopo il timeout di una richiesta che una libreria client attende per riprovare a inviare la richiesta.
- Timeout totale: il periodo di tempo dopo il quale una libreria client smette di riprovare a inviare le richieste di pubblicazione.
Per riprovare a inviare le richieste di pubblicazione, il timeout della richiesta iniziale deve essere inferiore al timeout totale. Ad esempio, se utilizzi il backoff esponenziale, le librerie client calcolano il timeout della richiesta e il ritardo di ripetizione nel seguente modo:
- Dopo ogni richiesta di pubblicazione, il timeout della richiesta aumenta in base al moltiplicatore del timeout della richiesta, fino al timeout massimo della richiesta.
- Dopo ogni tentativo, il ritardo di ripetizione aumenta in base al moltiplicatore del ritardo di ripetizione, fino al ritardo massimo di ripetizione.
Riprovare a inviare una richiesta di messaggio
Durante la procedura di pubblicazione, potresti riscontrare errori di pubblicazione temporanei o permanenti. In genere, per gli errori temporanei non è necessario intraprendere alcuna azione speciale, poiché Pub/Sub riprova automaticamente a inviare i messaggi.
Può verificarsi un errore anche quando un'operazione di pubblicazione va a buon fine, ma il client del publisher non riceve la risposta di pubblicazione in tempo. Anche in questo caso, l'operazione di pubblicazione viene ritentata. Di conseguenza, puoi avere due messaggi identici con ID messaggio diversi.
In caso di errori persistenti, valuta la possibilità di implementare azioni appropriate al di fuori della procedura di pubblicazione per evitare di sovraccaricare Pub/Sub.
Viene eseguito automaticamente un nuovo tentativo di pubblicazione, ad eccezione degli errori che non giustificano i tentativi. Questo codice campione mostra come creare un publisher con impostazioni di ripetizione personalizzate (tieni presente che non tutte le librerie client supportano le impostazioni di ripetizione personalizzate); consulta la documentazione di riferimento dell'API per la lingua scelta):
C++
Prima di provare questo esempio, segui le istruzioni di configurazione di C++ in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub C++ .
C#
Prima di provare questo esempio, segui le istruzioni di configurazione di C# in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub C# .
Go
L'esempio seguente utilizza la versione principale della libreria client Go Pub/Sub (v2). Se utilizzi ancora la libreria v1, consulta la guida alla migrazione alla v2. Per visualizzare un elenco di esempi di codice della versione 1, consulta gli esempi di codice deprecati.
Prima di provare questo esempio, segui le istruzioni di configurazione di Go in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Go.
Java
Prima di provare questo esempio, segui le istruzioni di configurazione di Java in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Java.
Node.js
Prima di provare questo esempio, segui le istruzioni di configurazione di Node.js in guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Node.js.
Node.js
Prima di provare questo esempio, segui le istruzioni di configurazione di Node.js in guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Node.js.
Python
Prima di provare questo esempio, segui le istruzioni di configurazione di Python in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Python.
Riprovare a inviare richieste con chiavi di ordinamento
Supponiamo di avere un singolo client publisher. Utilizzi le librerie client Pub/Sub per pubblicare i messaggi 1, 2 e 3 per la stessa chiave di ordinamento A. Ora, supponiamo che il client del publisher non riceva la risposta pubblicata per il messaggio 1 prima della scadenza dell'RPC. Il messaggio 1 deve essere ripubblicato. La sequenza di messaggi ricevuti dal client del sottoscrittore diventa 1, 1, 2 e 3, se si presuppone che il messaggio 2 venga pubblicato solo dopo il completamento del messaggio 1. Ogni messaggio pubblicato ha il proprio ID messaggio. Dal punto di vista del client del sottoscrittore, sono stati pubblicati quattro messaggi, i primi due con contenuti identici.
Il nuovo tentativo di invio delle richieste di pubblicazione con chiavi di ordinamento può essere complicato anche dalle impostazioni batch. La libreria client raggruppa i messaggi per una pubblicazione più efficiente. Continua con l'esempio precedente e supponi che i messaggi 1 e 2 siano raggruppati. Questo batch viene inviato al server come singola richiesta. Se il server non restituisce una risposta in tempo, il client del publisher riprova a inviare questo batch di due messaggi. Pertanto, è possibile che il client del sottoscrittore riceva i messaggi 1, 2, 1, 2 e 3. Se utilizzi una libreria client Pub/Sub per pubblicare i messaggi in ordine e un'operazione di pubblicazione non va a buon fine, il servizio non riesce a eseguire le operazioni di pubblicazione per tutti i messaggi rimanenti con la stessa chiave di ordinamento. Un client del publisher può quindi decidere di eseguire una delle seguenti operazioni:
Ripubblicare tutti i messaggi non riusciti in ordine
Ripubblicare un sottoinsieme dei messaggi non riusciti in ordine
Pubblicare un nuovo insieme di messaggi
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. Ad esempio, quando un publisher invia un messaggio a un argomento inesistente, si verifica un errore non irreversibile. Per continuare a pubblicare messaggi con la stessa chiave di ordinamento, chiama un metodo per riprendere la pubblicazione e poi ricomincia a pubblicare.
L'esempio seguente mostra come riprendere la pubblicazione di messaggi con la stessa chiave di ordinamento.
C++
Prima di provare questo esempio, segui le istruzioni di configurazione di C++ in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub C++ .
C#
Prima di provare questo esempio, segui le istruzioni di configurazione di C# in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub C# .
Go
L'esempio seguente utilizza la versione principale della libreria client Go Pub/Sub (v2). Se utilizzi ancora la libreria v1, consulta la guida alla migrazione alla v2. Per visualizzare un elenco di esempi di codice della versione 1, consulta gli esempi di codice deprecati.
Prima di provare questo esempio, segui le istruzioni di configurazione di Go in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Go.
Java
Prima di provare questo esempio, segui le istruzioni di configurazione di Java in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Java.
Node.js
Prima di provare questo esempio, segui le istruzioni di configurazione di Node.js in guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Node.js.
Python
Prima di provare questo esempio, segui le istruzioni di configurazione di Python in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Python.
Ruby
L'esempio seguente utilizza la libreria client Ruby Pub/Sub v3. Se utilizzi ancora la libreria v2, consulta la guida alla migrazione alla v3. Per visualizzare un elenco di esempi di codice Ruby v2, consulta gli esempi di codice deprecati.
Prima di provare questo esempio, segui le istruzioni di configurazione di Ruby in Guida rapida all'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Pub/Sub Ruby.
Passaggi successivi
Per scoprire come configurare le opzioni di pubblicazione avanzate, consulta quanto segue: