Pub/Sub: introduzione all'affidabilità

Questa guida fornisce una comprensione e una panoramica delle funzionalità di affidabilità di Pub/Sub. Gli argomenti trattati in questo documento includono i seguenti:

• Perché Pub/Sub?
• Failover
• Ottimizzare gli editori
• Ottimizzare gli abbonati
• Usa lo snapshot e la ricerca di deployment sicuri

Perché Pub/Sub?

Come paradigma di messaggistica, publish-subscribe è progettato per disaccoppiare i producer dei messaggi dai rispettivi consumer. Anziché inviare richieste dirette ai consumatori con i dati, i producer li pubblicano in un servizio Pub/Sub come Pub/Sub. Il servizio invia i messaggi in modo asincrono ai consumatori interessati che si sono abbonati.

Il risultato è che il servizio assorbe tutte le complessità legate alla ricerca dei consumatori interessati ai dati. Il servizio gestisce anche la frequenza con cui i consumatori ricevono i dati, in base alla loro capacità. Il disaccoppiamento consente ai produttori di dati di scrivere messaggi su larga scala con bassa latenza, indipendentemente dal comportamento dei consumatori.

Pub/Sub offre una distribuzione dei messaggi estremamente scalabile e affidabile. Sebbene il servizio gestisca automaticamente gran parte di questo processo, hai il controllo su diversi aspetti dei tuoi publisher e sottoscrittori che possono influire sulla disponibilità e sulle prestazioni. Il resto della guida fornisce alcuni dettagli su questi aspetti

Failover

Pub/Sub è un servizio globale: argomenti e abbonamenti non sono intrinsecamente legati a regioni specifiche e i messaggi passano da una regione all'altra all'interno del servizio Pub/Sub quando necessario. Quando si utilizza l'endpoint globale, pubsub.googleapis.com, publisher e abbonati si connettono alla regione più vicina alla rete in cui viene eseguito Pub/Sub. Quando si utilizzano gli endpoint di località, come us-central1-pubsub.googleapis.com, i publisher e i sottoscrittori si connettono a Pub/Sub nella regione specificata. Quando esegui publisher o sottoscrittori al di fuori di Google Cloud, è preferibile utilizzare endpoint di località per garantire che i messaggi passino in modo coerente tra le regioni previste. Il resto di questa sezione illustra come creare argomenti e sottoscrizioni. Inoltre, viene illustrato come posizionare publisher e sottoscrittori in modo da supportare diversi tipi di failover e ridondanza dei dati.

Semantica di failover predefinita

Considera un caso in cui sono presenti un solo argomento e una sola sottoscrizione. Gli editori si trovano nelle regioni degli Stati Uniti e in Australia, mentre gli abbonati si trovano nelle Google Cloud regioni dell'Europa e dell'Australia. Nel caso in cui tutti i sottoscrittori abbiano una capacità sufficiente per ricevere messaggi, il flusso di messaggi sarà simile al seguente:

Le P rappresentano i publisher, mentre le S rappresentano gli abbonati. L'esagono blu rappresenta il servizio Pub/Sub. I cilindri rappresentano le posizioni in cui vengono archiviati i messaggi (i messaggi sono sempre resi persistenti in più zone della regione in cui vengono pubblicati). Pub/Sub preferisce inviare messaggi all'interno della stessa regione in cui sono stati pubblicati quando i sottoscrittori sono disponibili. Altrimenti, invia i messaggi alla regione più vicina alla rete con sottoscrittori con capacità massima. Pertanto, come mostrato nell'immagine precedente, i messaggi pubblicati negli Stati Uniti vengono recapitati ai sottoscrittori in Europa, mentre quelli pubblicati in Australia rimangono in Australia.

Le sezioni seguenti illustrano cosa succede nei diversi scenari di errore.

Gli abbonati in Europa non sono disponibili

Supponiamo che gli abbonati in Europa siano stati disattivati, che si arrestino frequentemente e che non siano in grado di mantenere una connessione a Pub/Sub. In questo caso, il servizio inizierà a consegnare messaggi ai sottoscrittori in Australia:

Gli abbonati in Europa e Australia non sono disponibili

Nel caso in cui tutti i sottoscrittori non siano disponibili, Pub/Sub archivia i messaggi fino alla durata di conservazione dei messaggi configurata.

Una volta che i sottoscrittori si riconnettono, i messaggi vengono recapitati, a meno che l'interruzione non duri più della durata di conservazione dei messaggi configurata. Per impostazione predefinita, la conservazione dei messaggi di abbonamento è impostata su 7 giorni. Puoi anche configurare la conservazione dei messaggi per un argomento per un massimo di 31 giorni. Non scegliere una durata di conservazione dei messaggi più breve dell'interruzione massima che prevedi o che vuoi tollerare.

Pub/Sub non è disponibile in Europa

Sebbene sia raro, potresti anche voler affrontare i casi in cui Pub/Sub non è disponibile. L'indisponibilità di Pub/Sub si manifesta come periodi prolungati di errori imprevisti nelle richieste di pubblicazione o sottoscrizione o come incapacità di recapitare i messaggi pubblicati ai sottoscrittori. Ad esempio, se Pub/Sub era disponibile nella regione europea, lo scenario è più o meno lo stesso di quando gli abbonati non sono attivi:

Tieni presente che in questo caso, gli abbonati in Europa non eseguono il failover in un'altra regione, anche se viene utilizzato l'endpoint globale. Pub/Sub non esegue intenzionalmente il failover automatico. Immagina che siano gli abbonati stessi a causare un problema imprevisto in Pub/Sub che comporta l'indisponibilità. Un problema di questo tipo viene considerato come una grave interruzione. Tuttavia, l'ambito dell'impatto dell'interruzione può essere limitato alla regione a cui si sono connessi gli abbonati. Se il servizio consente il failover in un'altra regione, gli abbonati potrebbero anche causare l'indisponibilità nella regione, con un errore a cascata in tutto il servizio.

I publisher in Australia non sono disponibili

Se i publisher in un'area geografica non sono più disponibili, i messaggi già pubblicati vengono comunque recapitati ai sottoscrittori più vicini:

Alla fine, tutti i messaggi vengono consumati e confermati dai sottoscrittori. Durante l'invio di messaggi, Pub/Sub cerca di ridurre al minimo la distanza della rete. Di conseguenza, i sottoscrittori nella regione in Australia possono interrompere la ricezione di messaggi se i sottoscrittori in Europa dispongono di una capacità sufficiente per gestire tutti i messaggi pubblicati negli Stati Uniti.

Pub/Sub non è disponibile negli Stati Uniti

Pub/Sub scrive i messaggi in modo sincrono in più zone all'interno di una regione. Di conseguenza, un'interruzione a livello di zona non è sufficiente per impedire la consegna dei messaggi: l'intera regione deve essere non disponibile. Se Pub/Sub non è più disponibile in una regione in cui i publisher inviano messaggi, i messaggi in quella regione potrebbero non essere recapitati finché il servizio non sarà completamente ripristinato:

Il messaggio è ancora stato recapitato (supponendo che il periodo di conservazione dei messaggi non sia trascorso) e viene ritardato dalla durata dell'interruzione. Tieni presente che, come per gli abbonati, anche i publisher negli Stati Uniti non eseguono il failover in un'altra regione quando il servizio non funziona. Questo comportamento previene la probabilità di errori a cascata tra le regioni a causa di un editore o un abbonato difettoso.

Isolamento

I dettagli semantici di failover predefiniti influiscono sull'isolamento dei dati e sul modo in cui l'indisponibilità di publisher, sottoscrittori o dello stesso Pub/Sub può influire sul flusso dei messaggi. Il tuo caso d'uso potrebbe richiedere livelli di isolamento diversi. Ad esempio, potresti richiedere la consegna all'interno di una regione di tutti i messaggi.

Se non vuoi alcun isolamento, i dettagli predefiniti della semantica di failover predefinita sono sufficienti. Devi creare un singolo argomento, una singola sottoscrizione e posizionare publisher e sottoscrittori in tutte le regioni selezionate. Se i sottoscrittori non sono più disponibili o Pub/Sub non è disponibile nella regione a cui si collegano, la distribuzione viene sottoposta a failover ai sottoscrittori in un'altra regione.

Per l'isolamento a livello di regione, in cui è garantito che i dati non escano da una regione, crea un argomento e una sottoscrizione per gestire i messaggi in ogni regione. Individua editori e sottoscrittori in ciascuna di queste regioni e chiedi loro di pubblicare e sottoscrivere rispettivamente l'argomento e la sottoscrizione corrispondenti. Devi inoltre utilizzare endpoint regionali per garantire che i dati si spostino solo all'interno della regione. In caso di errori del publisher, del sottoscrittore o di Pub/Sub in una singola regione, la consegna dei messaggi viene interrotta in quella regione. La consegna di messaggi su argomenti e abbonamenti per altre regioni non è interessata.

Infine, in Pub/Sub non è possibile l'isolamento a livello di zona, per cui i dati rimangono all'interno di una singola zona. Se hai bisogno che le singole zone siano indipendenti, utilizza Pub/Sub Lite.

Failover e ridondanza controllati dal cliente

La semantica del failover predefinita di Pub/Sub potrebbe non garantire completamente che i messaggi possano sempre passare dai publisher ai sottoscrittori in caso di interruzione. Le interruzioni possono verificarsi in diverse posizioni, inclusi i client, nel servizio su cui vengono eseguiti i publisher o gli abbonati, nella rete o persino raramente nello stesso Pub/Sub. Se è necessario che i servizi siano resilienti a queste interruzioni, devi implementare le tue ridondanze. In genere, queste ridondanze includono l'utilizzo di più istanze di client publisher e sottoscrittori, ciascuna delle quali utilizza un endpoint di località diverso.

Potresti volere la resilienza a due diversi ambiti di impatto: a livello di zona o di regione. Di seguito sono riportate le opzioni di configurazione per ciascuno.

Resilienza a livello di zona

Pub/Sub dispone di una replica integrata tra zone diverse. Non è necessario intraprendere alcuna azione speciale per gestire interruzioni di una singola zona che interessano il servizio stesso. Tuttavia, per garantire la resilienza alle interruzioni dei clienti o della rete, è preferibile eseguire editori e abbonati con capacità sufficiente in più zone all'interno della regione. Se una singola zona non è attiva, i client nell'altra zona sono in grado di rilevare il traffico ed elaborare i messaggi. Una best practice consiste nel non pubblicare le modifiche in questi client contemporaneamente in modo che, se viene introdotto un bug, le altre zone non interessate possono continuare a elaborare i messaggi.

Resilienza regionale

Per garantire la resilienza agli errori regionali, configura ulteriori ridondanze nei tuoi publisher e sottoscrittori. Puoi eseguire publisher e sottoscrittori in più regioni per gestire la possibilità di interruzioni in quei client o nel networking.

Per garantire la resilienza contro potenziali errori di Pub/Sub in una regione, è necessario disporre di un meccanismo di failover pronto per gestire l'interruzione del servizio. I possibili approcci rappresentano un compromesso tra la latenza di consegna dei messaggi end-to-end e i costi.

Per ridurre al minimo la latenza nel caso in cui i costi non siano un problema, la migliore strategia è quella di pubblicare e sottoscrivere sempre contemporaneamente la pubblicazione in regioni diverse. Prima di tutto, scegli il numero di regioni in cui vuoi la ridondanza. Poi, anche se non è strettamente necessario, puoi configurare un argomento e un abbonamento per ognuna di queste regioni.

Ogni editore crea tanti client publisher quanti sono le regioni (uno per ogni regione) e utilizza un endpoint di località diverso per garantire che i messaggi vengano indirizzati a regioni distinte. Se utilizzi argomenti separati, ogni cliente del publisher deve pubblicare nell'argomento corrispondente per regione. Per ogni messaggio, l'editore chiama la pubblicazione su ogni client. Con le pubblicazioni ridondanti, non è necessario ritentare le pubblicazioni se una sola non funziona.

Allo stesso modo, ciascun sottoscrittore crea un certo numero di client sottoscrittori, uno per ogni regione, e utilizza un endpoint di località per connettersi a una regione diversa. Se utilizzi abbonamenti diversi per ogni regione, ogni client abbonato deve utilizzare l'abbonamento corrispondente. Tieni presente che le regioni utilizzate per gli editori e per i sottoscrittori non devono necessariamente essere le stesse. I sottoscrittori ricevono i messaggi nelle tre sottoscrizioni e li elaborano.

Questa configurazione ha diversi requisiti e funzionalità principali:

1. Qualsiasi interruzione in una singola regione non influisce sull'elaborazione dei messaggi già pubblicati né di quelli pubblicati durante l'interruzione. Poiché i messaggi sono stati pubblicati in più regioni, sono ancora disponibili in altre regioni se una regione non era disponibile. Durante l'interruzione, le chiamate di pubblicazione non vanno a buon fine nella regione interessata, mentre le chiamate di pubblicazione hanno esito positivo nelle altre.
2. La latenza dell'elaborazione dei messaggi non è interessata, purché sia disponibile una qualsiasi delle regioni attraverso le quali passano il flusso dei messaggi.
3. L'elaborazione dei messaggi deve essere idempotente. Poiché ogni messaggio verrà recapitato più volte, l'elaborazione del messaggio deve essere resiliente ai duplicati. In caso di interruzione a livello di regione, alcuni di questi duplicati potrebbero arrivare molto più tardi rispetto alla prima consegna del messaggio. Questi duplicati probabilmente provenivano da un'altra regione in cui non si è verificata un'interruzione.

L'esecuzione di questo tipo di ridondanza offre la massima resilienza a qualsiasi tipo di interruzione. Per i servizi interni di Google che si basano su Pub/Sub e richiedono la massima disponibilità, è preferibile questa configurazione. Tuttavia, questa configurazione prevede il compromesso di moltiplicare il costo di consegna dei messaggi per il numero di regioni utilizzate. È previsto anche il costo aggiuntivo dell'utilizzo della rete tra regioni per i messaggi che devono essere spostati tra regioni.

Un altro approccio alla ridondanza è il failover solo quando le richieste non vanno a buon fine o i messaggi non passano dai publisher ai sottoscrittori come previsto. In questo scenario, disponi di una regione principale a cui indirizzi i tuoi publisher e abbonati tramite endpoint di località. Come prima, non è necessario corrispondere alla stessa regione. Hai anche una regione di riserva per editori e abbonati, utilizzata quando la regione principale non è disponibile.

I publisher pubblicano solo nella regione principale (tramite l'endpoint della località) quando le richieste vengono inviate correttamente. Ogni volta che viene stabilito che la regione non è disponibile, gli editori iniziano a pubblicare nell'area di riserva. Puoi stabilire che la regione non è attiva e il failover si può fare in due modi. Può essere eseguito manualmente e la configurazione viene aggiornata dinamicamente negli editori. Gli editori possono anche aggiornare la configurazione autonomamente se la percentuale di errori nelle richieste di pubblicazione è sufficientemente elevata.

I sottoscrittori devono sempre connettersi alla regione principale tramite l'endpoint della località. Puoi decidere che l'abbonato può utilizzare la regione di riserva con uno o più dei seguenti attivatori:

1. Abbonati sempre alla regione di riserva. In questo caso, l'abbonato mantiene sempre una connessione sia alla regione principale sia alla regione di riserva. Le stesse regioni possono essere utilizzate come area geografica principale e di riserva sia per gli editori che per gli abbonati. In questo caso, il sottoscrittore deve ricevere messaggi tramite la regione di backup solo in caso di errore dell'editore.
2. Rileva e sposta manualmente gli abbonati alla regione di riserva tramite una configurazione. Se rilevi un'interruzione, puoi eseguire il failover nella regione di riserva e poi tornare alla regione principale quando l'interruzione è scomparsa.
3. Esegui il failover in caso di errori relativi al sottoscrittore. Se le richieste dell'abbonato restituiscono errori, puoi utilizzarlo per indicare che devi eseguire il failover dell'area geografica di riserva. Tieni presente che le librerie client di Pub/Sub ritentano il flusso di richieste di pull internamente in caso di errori temporanei, per cui potresti non essere in grado di rilevare la presenza di lunghi periodi di errori imprevisti. Inoltre, la percentuale di errori di pull dei flussi di dati dovrebbe essere del 100%, anche durante il normale funzionamento.
4. Esegui il failover se il sottoscrittore passa inaspettatamente per un lungo periodo di tempo senza ricevere messaggi. Presupponendo che i messaggi vengano pubblicati in modo costante, i sottoscrittori possono sempre riceverli. Se passano un periodo di tempo prolungato senza ricevere messaggi, potrebbe esserci un problema di sottoscrizione in Pub/Sub nella regione principale. Il problema viene risolto eseguendo il failover nell'area geografica di riserva.

Di tutte e quattro le opzioni, la prima è quella ideale. Una connessione del sottoscrittore non comporta alcun costo se non vi sono flussi di messaggi. L'unico costo riguarda l'ingombro dell'istanza aggiuntiva della libreria client del sottoscrittore, che può essere trascurabile. Devi inoltre tenere presente il numero di connessioni pull in modalità flusso aperte per quota per regione.

Il vantaggio di questo secondo modello è che non è previsto un moltiplicatore nel costo Pub/Sub poiché i messaggi vengono pubblicati una sola volta. Tuttavia, per alcuni tipi di interruzioni, i messaggi pubblicati prima dell'inizio dell'interruzione potrebbero non essere disponibili fino alla risoluzione dell'interruzione. I messaggi archiviati in una regione non disponibile potrebbero non essere recapitati ai sottoscrittori, indipendentemente da dove sono connessi. I messaggi pubblicati durante l'interruzione nella regione di fallback possono essere disponibili. Inoltre, potrebbe verificarsi un periodo di indisponibilità con maggiori tassi di errore per gli editori o gli abbonati. Dipende dal metodo utilizzato per rilevare un'interruzione e dal tempo per il failover nell'area geografica di riserva.

Indipendentemente dall'opzione scelta, tieni presente come questa potrebbe interagire con le funzionalità di Pub/Sub. Sia la consegna ordinata sia la consegna "exactly-once" offrono le loro garanzie all'interno di una regione. Ad esempio, se utilizzi la tecnica di ridondanza del failover, la consegna dei messaggi è garantita solo per i messaggi pubblicati nella stessa regione. Il sottoscrittore potrebbe ricevere i messaggi pubblicati nella regione di riserva prima che vengano pubblicati nella regione principale, anche se questi ultimi sono stati pubblicati prima nella regione principale.

Ottimizzare gli editori

Indipendentemente dalle opzioni di failover scelte, ci sono alcuni passaggi di ottimizzazione aggiuntivi che vuoi eseguire all'interno degli editori stessi. L'ottimizzazione del comportamento del publisher garantisce prestazioni ottimali in condizioni di carico elevato. Il raggruppamento dei messaggi in batch è un modo per compromesso la latenza per i costi ridotti, ma non è un problema di affidabilità e pertanto non è trattato qui. Concentrati invece su alcuni degli altri parametri utili per ottimizzare l'affidabilità, tra cui le impostazioni per i nuovi tentativi e le impostazioni di controllo del flusso.

Le pubblicazioni potrebbero non riuscire per diversi motivi, inclusi quelli temporanei come l'indisponibilità della rete o quelli che richiedono l'intervento dell'utente, ad esempio le modifiche alle autorizzazioni. La libreria client di Pub/Sub tenta di nuovo gli errori temporanei utilizzando i parametri specificati nelle impostazioni per i nuovi tentativi. Queste impostazioni controllano il comportamento del backoff esponenziale nei nuovi tentativi di pubblicazione di RPC che non riescono per motivi temporanei. Sebbene le impostazioni predefinite possano in genere funzionare bene nella maggior parte degli scenari, in alcune situazioni potrebbe essere necessario ottimizzare questi valori.

Le due proprietà che probabilmente utilizzerai più spesso sono il timeout RPC iniziale e il timeout totale. Il timeout RPC iniziale indica per quanto tempo deve essere completata la prima RPC di pubblicazione. Se una RPC non funziona o si verifica il timeout, viene tentato un'altra RPC con un timeout più lungo fino al superamento del numero totale di richieste o del timeout totale.

Il timeout iniziale può essere ottimizzato se il publisher è vincolato alla rete o è lontano dal data center Google Cloud più vicino che esegue Pub/Sub. I vincoli di rete potrebbero essere limitazioni della velocità effettiva della macchina su cui l'editore è in esecuzione o potrebbero derivare dall'esecuzione di altri servizi sulla stessa macchina a uso intensivo della rete. Se il timeout è impostato su un valore troppo breve, gli RPC iniziali potrebbero non riuscire ripetutamente e, di conseguenza, sono necessari più tentativi (con timeout più lunghi) per la pubblicazione corretta. La necessità ripetuta di nuovi tentativi aumenta la latenza di pubblicazione. In questa situazione, l'aumento del timeout iniziale potrebbe accelerare le pubblicazioni.

Se la connessione di rete non è affidabile, aumentare il timeout totale e il timeout iniziale potrebbe essere utile. Un timeout totale aumentato dà più tempo alla RPC di pubblicazione. Se le RPC di pubblicazione hanno esito negativo costante con errori di scadenza superata, valuta la possibilità di ottimizzare questi valori.

Gli errori di superamento continuo della scadenza al momento della pubblicazione possono anche indicare la necessità di ottimizzare il controllo del flusso del publisher. Queste impostazioni consentono di garantire che i publisher siano resilienti ai picchi di traffico in entrata che generano più messaggi da inviare a Pub/Sub. Un aumento significativo delle richieste in uscita potrebbe sovraccaricare la CPU, la memoria o la capacità di rete dell'editore. Quando la pubblicazione è sovraccarica, non è in grado di elaborare richieste o risposte di pubblicazione prima dei timeout. Ciò si traduce in un numero ancora maggiore di richieste di pubblicazione e, in ultima analisi, nel raggiungimento del timeout totale. Il controllo del flusso dell'editore limita il numero di messaggi o byte che possono essere in sospeso senza una risposta dalla richiesta di pubblicazione. Limitare il numero di richieste in questo modo mantiene l'utilizzo delle risorse a un livello gestibile, anche durante i picchi. A seconda di come funziona il tuo editore, puoi consentire alle successive RPC di pubblicazione di attendere la capacità, consentendo alla pubblicazione di bloccare ulteriori richieste. In alternativa, puoi eseguire il push ai chiamanti del tuo servizio facendo in modo che il controllo del flusso restituisca un errore quando viene raggiunta la capacità. Configuri il modo in cui la libreria client dell'editore risponde con il comportamento del limite superato.

Ottimizzare gli abbonati

Potrebbe essere necessaria anche l'ottimizzazione dei sottoscrittori per garantire che operino in modo affidabile. Come per gli editori, puoi ottimizzare le impostazioni di controllo del flusso dei sottoscrittori per assicurarti che non vengano sopraffatti. La libreria client del sottoscrittore utilizza il pull dei flussi di dati, in cui il client apre un flusso permanente al server e il server invia i messaggi non appena diventano disponibili. In caso di un aumento significativo dei messaggi pubblicati, il sottoscrittore può ricevere più messaggi di quelli che può elaborare. Con il controllo del flusso attivo, il numero di messaggi non confermati in sospeso per il client in un determinato momento è limitato. In questo modo, si riduce il numero di messaggi gestiti contemporaneamente e la loro elaborazione viene estesa per un periodo di tempo più lungo. La distribuzione del carico consente ai sottoscrittori di rimanere sotto eventuali limitazioni delle risorse che influiscono sull'elaborazione dei messaggi, il che può comportare un effetto a cascata che si trasforma nell'incapacità di elaborare i messaggi.

Il controllo del flusso da solo è sufficiente se ci si aspetta solo picchi nella quantità di dati da elaborare che alla fine si riducono. Se il traffico aumenta generalmente nel tempo a causa di un maggiore utilizzo, il controllo del flusso protegge gli abbonati. Tuttavia, può portare a un backlog che continua ad accumularsi e a impedire il recapito dei messaggi prima della scadenza della durata di conservazione. In questi casi, puoi anche impostare la scalabilità automatica in modo da aumentare il numero di sottoscrittori in risposta a un numero crescente di messaggi non confermati. Il modo in cui lo configuri dipende dalla piattaforma di computing che utilizzi per i tuoi abbonati. Ad esempio, il gestore della scalabilità automatica di Compute Engine consente di scalare in base a metriche come il numero di messaggi non consegnati. L'uso sia della scalabilità automatica che del controllo del flusso consente di garantire che i tuoi abbonati siano resilienti ad altri picchi a breve termine nella velocità effettiva dei messaggi e a una crescita a lungo termine che richiede più potenza di calcolo. Assicurati di seguire le best practice per l'utilizzo delle metriche Pub/Sub come indicatori di scalabilità.

Usa lo snapshot e cerca deployment sicuri

La perdita di messaggi è in genere un evento catastrofico. Pub/Sub offre la consegna "at-least-once" di tutti i messaggi pubblicati. Tuttavia, la corretta elaborazione di questi messaggi dipende dal comportamento del sottoscrittore. Se i messaggi vengono confermati correttamente, Pub/Sub non li recapita. Di conseguenza, un bug introdotto nel nuovo codice sottoscrittore di cui esegui il deployment che riconosce i messaggi senza essere stati elaborati correttamente potrebbe causare la perdita dei messaggi indotta dal sottoscrittore. Pub/Sub offre la funzionalità di snapshot e ricerca, che può aiutarti a garantire che ogni messaggio venga elaborato correttamente, anche in presenza di bug relativi ai sottoscrittori.

Il pattern per il deployment di ogni sottoscrittore deve essere il seguente:

Il tempo di attesa prima di determinare se il nuovo abbonato funziona può variare in base al caso d'uso. L'unico modo per uscire dal flusso dei passaggi è quando un abbonato viene ritenuto funzionante, dopodiché lo snapshot può essere eliminato.

L'utilizzo di snapshot e ricerca non sostituisce le best practice relative alla prima esecuzione del software in un ambiente non di produzione e al deployment graduale in produzione. Forniscono un ulteriore livello di protezione per garantire un trattamento affidabile dei dati. Lo svantaggio è che la ricerca dello snapshot potrebbe causare la doppia consegna dei messaggi che il sottoscrittore ha elaborato correttamente. Tuttavia, poiché Pub/Sub ha una semantica di consegna "at-least-once" per impostazione predefinita, i sottoscrittori sono già resilienti alla riconsegna dei messaggi.