Pub/Sub: introduzione all'affidabilità

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

• Perché Pub/Sub?
• Failover
• Ottimizzazione dei publisher
• Ottimizzazione degli iscritti
• Utilizzo di snapshot e ricerca di implementazioni sicure

Perché Pub/Sub?

In qualità di paradigma di messaggistica, il modello pub/sub è progettato per disaccoppiare i produttori di messaggi dai consumatori di questi messaggi. Invece di inviare richieste dirette ai consumatori con i dati, i produttori pubblicano i dati in un servizio Pub/Sub come Pub/Sub. Il servizio invia in modo asincrono questi messaggi ai consumatori interessati che si sono iscritti.

Di conseguenza, il servizio assorbe tutte le complessità di trovare consumatori interessati ai dati. Il servizio gestisce anche la velocità 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 un recapito dei messaggi affidabile e altamente scalabile. Sebbene il servizio gestisca gran parte di queste operazioni automaticamente, hai il controllo su diversi aspetti di publisher e abbonati che possono influire sulla disponibilità e sul rendimento. Il resto di questa guida fornisce alcuni dettagli su questi aspetti

Failover

Pub/Sub è un servizio globale: gli argomenti e gli abbonamenti non sono intrinsecamente legati a regioni specifiche e i messaggi fluiscono all'interno del servizio Pub/Sub tra le regioni, se necessario. Quando utilizzi l'endpoint globale, pubsub.googleapis.com, i publisher e gli abbonati si connettono alla regione più vicina alla rete in cui viene eseguito Pub/Sub. Quando utilizzi gli endpoint geografici, come us-central1-pubsub.googleapis.com, i publisher e gli abbonati si connettono a Pub/Sub nella regione specificata. Quando pubblichi publisher o iscritti al di fuori di Google Cloud, è meglio utilizzare endpoint geografici per garantire il flusso dei messaggi tra le regioni previste in modo coerente. Il resto di questa sezione spiega come creare argomenti e iscrizioni. Inoltre, viene descritto come posizionare publisher e sottoscrittori per supportare diversi tipi di failover e ridondanza dei dati.

Semantika del failover predefinita

Prendiamo in considerazione un caso in cui sono presenti un solo argomento e una sola sottoscrizione. I publisher si trovano nelle regioni degli Stati Uniti e dell'Australia, mentre gli abbonati si trovano nelle regioni Google Cloud di Europa e Australia. Se tutti gli abbonati hanno una capacità sufficiente per ricevere i messaggi, il flusso di messaggi è il seguente:

Le P rappresentano i publisher, le S gli abbonati. L'esagono blu rappresenta il servizio Pub/Sub. I cilindri rappresentano i luoghi in cui vengono archiviati i messaggi (i messaggi vengono sempre memorizzati in più zone della regione in cui vengono pubblicati). Pub/Sub preferisce inviare i messaggi all'interno della stessa regione in cui sono stati pubblicati, se sono disponibili gli abbonati. In caso contrario, invia i messaggi alla regione più vicina alla rete con sottoscrittori che dispongono di capacità. Pertanto, come mostrato nella precedente immagine, i messaggi pubblicati negli Stati Uniti vengono inviati ai subscriber in Europa e i messaggi pubblicati in Australia rimangono in Australia.

Le sezioni seguenti descrivono cosa accade in diversi scenari di errore.

Gli abbonati in Europa non sono disponibili

Supponiamo che gli abbonati in Europa siano stati rifiutati o si arrestino in modo anomalo di frequente e non riescano a mantenere una connessione a Pub/Sub. In questo caso, il servizio inizierà a consegnare i messaggi agli abbonati in Australia:

Gli abbonamenti in Europa e Australia non sono disponibili

Se tutti i sottoscrittori non sono disponibili, Pub/Sub immagazzina i messaggi fino alla durata di conservazione dei messaggi configurata.

Una volta che i sottoscrittori si ricollegano, i messaggi vengono recapitati, a meno che l'interruzione non duri più a lungo della durata di conservazione dei messaggi configurata. Per impostazione predefinita, la conservazione dei messaggi delle iscrizioni è impostata su 7 giorni. Puoi anche configurare la conservazione dei messaggi in un argomento per un massimo di 31 giorni. Non scegliere una durata di conservazione dei messaggi inferiore all'interruzione massima prevista o che sei disposto a tollerare.

Pub/Sub non è disponibile in Europa

Anche se è raro, potresti anche dover gestire i casi in cui Pub/Sub non è disponibile. La mancata disponibilità di Pub/Sub si manifesta come periodi prolungati di errori imprevisti nelle richieste di pubblicazione o sottoscrizione o come impossibilità di consegnare i messaggi pubblicati agli iscritti. Ad esempio, se Pub/Sub non fosse disponibile nella regione europea, lo scenario sarebbe molto simile a quello in cui non sono disponibili gli iscritti:

Tieni presente che in questo caso gli abbonati in Europa non eseguono il failover in un'altra regione, anche se utilizzano l'endpoint globale. Pub/Sub non esegue intenzionalmente il failover automaticamente. Immagina che siano gli stessi sottoscrittori a causare un problema imprevisto in Pub/Sub che comporta la mancata disponibilità. Questo tipo di problema viene considerato un'interruzione grave. Tuttavia, l'impatto della interruzione può essere limitato alla regione a cui si sono collegati gli abbonati. Se il servizio consentisse il failover in un'altra regione, gli abbonati potrebbero causare anche la mancata disponibilità in quella regione, con conseguente errore a cascata nel servizio.

I publisher in Australia non sono disponibili

Se i publisher di una regione non sono disponibili, i messaggi già pubblicati vengono comunque recapitati ai sottoscrittori più vicini:

Alla fine, tutti i messaggi vengono consumati e confermati dagli iscritti. Quando invia messaggi, Pub/Sub cerca di ridurre al minimo la distanza di rete. Pertanto, gli abbonati nella regione australiana possono smettere di ricevere messaggi se gli abbonati in Europa hanno una capacità sufficiente per gestire tutti i messaggi pubblicati negli Stati Uniti.

Pub/Sub non è disponibile negli Stati Uniti

Pub/Sub scrive in modo sincrono i messaggi in più zone all'interno di una regione. Pertanto, un'interruzione zonale non è sufficiente per impedire il recapito dei messaggi; l'intera regione deve essere non disponibile. Se Cloud Pub/Sub diventa non disponibile in una regione in cui i publisher stanno inviando messaggi, questi messaggi potrebbero non essere recapitati finché il servizio non viene completamente ripristinato:

Il messaggio viene comunque recapitato (sempre che il periodo di conservazione del messaggio non sia terminato), con un ritardo pari alla durata dell'interruzione. Tieni presente che, come per gli abbonati, anche i publisher negli Stati Uniti non eseguono il failover in un'altra regione in caso di errore del servizio. Questo comportamento contribuisce a ridurre la probabilità di errori a cascata nelle regioni a causa di un editore o un abbonato con problemi.

Isolamento

La semantica di failover predefinita descritta influisce sull'isolamento dei dati e sul modo in cui la mancata disponibilità di publisher, abbonati o del servizio Pub/Sub stesso può influire sul flusso dei messaggi. Il tuo caso d'uso potrebbe richiedere diversi livelli di isolamento. Ad esempio, potresti richiedere la consegna di tutti i messaggi all'interno della regione.

Se non vuoi l'isolamento, le semantiche di failover predefinite descritte sono sufficienti. Devi creare un singolo argomento, una singola sottoscrizione e inserire editori e abbonati in tutte le regioni selezionate. Se i sottoscrittori diventano non disponibili o Pub/Sub non è attivo nella regione a cui si connettono, la consegna viene eseguita in modo alternativo per i sottoscrittori di un'altra regione.

Per l'isolamento regionale, 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 publisher e sottoscrittori in ciascuna di queste regioni e chiedi loro di pubblicare e iscriversi rispettivamente all'argomento e alla sottoscrizione regionale corrispondente. Devi anche utilizzare endpoint regionali per assicurarti che i dati vengano spostati solo all'interno della regione. In caso di errori di publisher, abbonati o Pub/Sub in una singola regione, l'invio dei messaggi si interrompe in quella regione. Il recapito dei messaggi per argomenti e iscrizioni per altre regioni non è interessato.

Infine, in Pub/Sub non è possibile l'isolamento zonale, in cui è garantito che i dati rimangano all'interno di un'unica zona. Se vuoi che le singole zone siano indipendenti, utilizza Pub/Sub Lite.

Failover e ridondanza controllati dal cliente

La semantica di failover predefinita di Pub/Sub potrebbe non garantire completamente che i messaggi possano sempre fluire dai publisher agli abbonati se si verifica un'interruzione ovunque nel mezzo. Le interruzioni potrebbero verificarsi in diversi punti, tra cui i tuoi client, nel servizio su cui vengono eseguiti i tuoi publisher o subscriber, nella rete o, raramente, nella stessa Pub/Sub. Se vuoi che i tuoi 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 subscriber, ognuno dei 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 ciascuna.

Resilienza a livello di zona

Pub/Sub ha una replica tra zone integrata. Non devi intraprendere alcuna azione speciale per gestire le interruzioni in una singola zona che interessano il servizio stesso. Tuttavia, per garantire la resilienza alle interruzioni per i tuoi clienti o la tua rete, è meglio pubblicare publisher e abbonati con una capacità sufficiente in più zone all'interno della regione. Se una singola zona non è disponibile, i client nell'altra zona sono in grado di acquisire il traffico e elaborare i messaggi. È buona norma non pubblicare contemporaneamente le modifiche a questi client in modo che, se viene introdotto un bug, le altre zone non toccate possano continuare a elaborare i messaggi.

Resilienza regionale

Per essere resilienti ai guasti a livello regionale, configura ridondanze aggiuntive nei publisher e negli abbonati. Puoi eseguire editori e sottoscrittori in più regioni per far fronte alla possibilità di interruzioni in questi client o nella rete.

Se vuoi essere resiliente ai potenziali guasti di Pub/Sub in una regione, devi avere un meccanismo di failover pronto a gestire un'interruzione di questo tipo. I possibili approcci sono un compromesso tra la latenza di invio dei messaggi end-to-end e il costo.

Per ridurre al minimo la latenza nel caso in cui il costo non sia un problema, la strategia migliore è pubblicare e iscriversi sempre contemporaneamente in regioni diverse. Innanzitutto, scegli il numero di regioni in cui vuoi la ridondanza. Successivamente, anche se non strettamente necessario, puoi configurare un argomento e una sottoscrizione per ciascuna di queste regioni.

Ogni publisher crea tanti client publisher quante 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 client editore deve pubblicare nell'argomento corrispondente per regione. Per ogni messaggio, il publisher chiama publish su ogni client. Con le pubblicazioni ridondanti, non è necessario riprovare se una singola pubblicazione non va a buon fine.

Analogamente, ogni sottoscrittore crea lo stesso numero di client sottoscrittore, uno per ogni regione, e utilizza un endpoint geografico per connettersi a una regione diversa. Se utilizzi diversi abbonamenti per ogni regione, ogni cliente abbonato deve utilizzare l'abbonamento corrispondente. Tieni presente che le regioni utilizzate per i publisher e gli abbonati non devono necessariamente essere le stesse. I sottoscrittori ricevono i messaggi tra le tre iscrizioni ed li elaborano.

Questa configurazione presenta diversi requisiti e funzionalità chiave:

1. Eventuali interruzioni in una singola regione non influiscono sull'elaborazione dei messaggi già pubblicati né su quelli pubblicati durante l'interruzione. Poiché i messaggi sono stati pubblicati in più regioni, sono ancora disponibili in altre regioni nel caso in cui una regione non fosse disponibile. Durante l'interruzione, le chiamate di pubblicazione non vanno a buon fine nella regione interessata, ma vanno a buon fine nelle altre.
2. La latenza di elaborazione dei messaggi non è interessata, a condizione che una delle regioni tramite cui passano i messaggi sia disponibile.
3. L'elaborazione dei messaggi deve essere idempotente. Poiché ogni messaggio verrà visualizzato più volte, l'elaborazione dei messaggi deve essere resistente ai duplicati. In caso di interruzione del servizio a livello regionale, alcuni di questi duplicati potrebbero arrivare molto più tardi della prima volta che il messaggio è stato recapitato. Probabilmente questi duplicati provenivano da una regione diversa in cui non si è verificata un'interruzione del servizio.

L'esecuzione con questo tipo di ridondanza offre la massima resilienza a qualsiasi tipo di interruzione. Per i servizi Google interni che si basano su Pub/Sub e richiedono la massima disponibilità, questa configurazione è preferita. Tuttavia, questa configurazione comporta il compromesso di moltiplicare il costo di invio dei messaggi per il numero di regioni utilizzate. Inoltre, è previsto un costo aggiuntivo per l'utilizzo della rete tra regioni per i messaggi che devono spostarsi tra regioni.

Un altro approccio alla ridondanza è eseguire il failover solo quando le richieste non vanno a buon fine o i messaggi non vengono inviati dai publisher agli abbonati come previsto. In questo scenario, hai una regione principale a cui indirizzi i tuoi editori e abbonati tramite endpoint geografici. Come prima, non devono necessariamente appartenere alla stessa regione. Hai anche una regione di riserva per editori e abbonati che viene utilizzata quando la regione principale non è disponibile.

I publisher pubblicano solo nella regione principale (tramite l'endpoint di geolocalizzazione) quando le relative richieste vengono inviate correttamente. Ogni volta che viene stabilito che la regione non è disponibile, i publisher iniziano a pubblicare nella regione di riserva. È possibile determinare se la regione è inattiva e se è in corso il failover in due modi. Può essere eseguita tramite una procedura manuale e la configurazione viene aggiornata dinamicamente nei publisher. I publisher possono anche aggiornare autonomamente la configurazione se il tasso di errore nelle richieste di pubblicazione è sufficientemente elevato.

Gli abbonati devono sempre connettersi alla regione principale tramite l'endpoint geografico. Puoi decidere che l'abbonato possa 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 a quella di riserva. È possibile utilizzare le stesse regioni per i valori principali e di riserva sia per i publisher sia per gli abbonati. In questo caso, il sottoscrittore deve ricevere i messaggi solo tramite la regione di backup se il publisher ha eseguito il failover.
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 è terminata.
3. Failover in caso di errori degli abbonati. Se le richieste degli abbonati restituiscono errori, puoi utilizzarle come indicazione del fatto che devi eseguire il failover nella regione di riserva. Tieni presente che le librerie client Pub/Sub riprovano a eseguire lo streaming delle richieste pull internamente in caso di errori temporanei, pertanto potresti non essere in grado di rilevare la presenza di periodi prolungati di errori imprevisti. Inoltre, il tasso di errore del pull dello streaming dovrebbe essere del 100%, anche durante il normale funzionamento.
4. Failover se l'abbonato rimane inattivo per un periodo di tempo inaspettatamente lungo senza ricevere messaggi. Se la pubblicazione dei messaggi è coerente, gli iscritti possono sempre ricevere messaggi. Se passano un periodo di tempo prolungato senza ricevere messaggi, potrebbe esserci un problema lato sottoscrittore in Pub/Sub nella regione principale. Il problema viene risolto eseguendo il failover alla regione di riserva.

Tra tutte e quattro le opzioni, la prima è l'ideale. La connessione di un abbonato non comporta alcun costo se non vengono inviati messaggi. L'unico costo è costituito dall'impronta dell'istanza aggiuntiva della libreria client dell'abbonato, che può essere trascurabile. Inoltre, devi tenere conto della quota del numero di connessioni StreamingPull aperte per regione.

Il vantaggio di questo secondo modello è che non è presente un moltiplicatore nel costo di Pub/Sub poiché i messaggi vengono pubblicati una sola volta. Tuttavia, il compromesso è che per determinati tipi di interruzioni, i messaggi pubblicati prima dell'inizio dell'interruzione potrebbero non essere disponibili fino a quando l'interruzione non sarà stata risolta. I messaggi memorizzati nella regione non disponibile potrebbero non essere recapitati agli abbonati, indipendentemente da dove sono connessi. I messaggi pubblicati durante la interruzione nella regione di riserva possono essere disponibili. Inoltre, potrebbe verificarsi un periodo di non disponibilità con un aumento dei tassi di errore per i publisher o gli abbonati. Ciò dipende dal metodo utilizzato per rilevare un'interruzione e dal tempo necessario per il passaggio alla regione di riserva.

Indipendentemente dall'opzione scelta, tieni presente in che modo questa potrebbe interagire con le funzionalità di Pub/Sub. Sia la consegna ordinata sia la consegna exactly-once offrono le proprie garanzie all'interno di una regione. Ad esempio, se utilizzi la tecnica di ridondanza di failover, l'invio dei messaggi è garantito solo per i messaggi pubblicati nella stessa regione. L'abbonato potrebbe ricevere i messaggi pubblicati nella regione di riserva prima di quelli pubblicati nella regione principale, anche se questi ultimi sono stati pubblicati per primi nella regione principale.

Ottimizzazione dei publisher

Indipendentemente dall'opzione di failover scelta, esistono alcuni passaggi di ottimizzazione aggiuntivi da eseguire all'interno dei publisher stessi. L'ottimizzazione del comportamento del publisher garantisce prestazioni ottimali in caso di carico elevato. L'invio collettivo dei messaggi è un modo per ridurre la latenza a fronte di un costo ridotto, ma non è un problema di affidabilità e pertanto non è trattato in questo articolo. Concentrati invece su alcuni degli altri parametri utili per la messa a punto in termini di affidabilità, tra cui le impostazioni di ripetizione e di controllo del flusso.

Le pubblicazioni potrebbero non riuscire per diversi motivi, inclusi quelli temporanei come la mancata disponibilità della rete o quelli che richiedono l'intervento dell'utente, come le modifiche alle autorizzazioni. La libreria client Pub/Sub riprova in caso di errori temporanei utilizzando i parametri specificati nelle impostazioni di ripetizione. Queste impostazioni controllano il comportamento del backoff esponenziale sui nuovi tentativi di RPC di pubblicazione che non vanno a buon fine per motivi temporanei. Sebbene le impostazioni predefinite possano solitamente funzionare bene nella maggior parte degli scenari, in alcuni casi potresti voler ottimizzare questi valori.

Le due proprietà che è più probabile che tu voglia ottimizzare sono il timeout RPC iniziale e il timeout totale. Il timeout RPC iniziale è il tempo concesso per il completamento della prima RPC di pubblicazione. Se una RPC non riesce o scade, ne viene tentata un'altra con un timeout più lungo finché non viene superato il numero totale di richieste o il timeout totale.

Il timeout iniziale può essere regolato se il publisher è soggetto a limitazioni di rete o è lontano dal data center Google Cloud più vicino che esegue Pub/Sub. I vincoli di rete potrebbero essere limitazioni della velocità in bit della macchina su cui è in esecuzione il publisher o potrebbero essere il risultato di altri servizi in esecuzione sulla stessa macchina che richiedono un'intensa attività di rete. Se il timeout è impostato su un valore troppo breve, le RPC iniziali potrebbero non riuscire ripetutamente, il che comporta la necessità di più tentativi (con timeout più lunghi) per la pubblicazione. La necessità ripetuta di ripetizioni aumenta la latenza di pubblicazione. In questa situazione, l'aumento del timeout iniziale potrebbe comportare pubblicazioni più rapide.

Se la connessione di rete non è affidabile, potrebbe essere utile aumentare il timeout totale e il timeout iniziale. Un timeout totale aumentato offre all'RPC di pubblicazione più tempo per completare l'operazione. Quando le RPC di pubblicazione non vanno a buon fine con errori di superamento del termine, valuta la possibilità di ottimizzare questi valori.

Gli errori relativi alla scadenza superata continua durante la pubblicazione possono anche indicare la necessità di ottimizzare il controllo del flusso del publisher. Queste impostazioni ti consentono di assicurarti che i tuoi publisher siano resilienti agli picchi di traffico in entrata che generano più messaggi da inviare a Pub/Sub. Un notevole aumento delle richieste in uscita potrebbe sovraccaricare la CPU, la memoria o la capacità di rete del publisher. Quando la pubblicazione è sovraccaricata, non è in grado di elaborare richieste o risposte di pubblicazione prima dei timeout. Ciò comporta un aumento delle richieste di pubblicazione e, in ultima analisi, il raggiungimento del timeout totale. Il controllo del flusso del publisher limita il numero di messaggi o byte che possono essere in sospeso senza una risposta alla richiesta di pubblicazione. Limitare il numero di richieste in questo modo consente di mantenere l'utilizzo delle risorse a un livello gestibile, anche durante i picchi. A seconda del funzionamento del publisher, puoi consentire alle RPC di pubblicazione successive di attendere la disponibilità consentendo alla pubblicazione di bloccare ulteriori richieste. In alternativa, puoi spingere gli utenti che chiamano il tuo servizio facendo in modo che il controllo del flusso restituisca un errore quando viene raggiunta la capacità. Configura la modalità di risposta della libreria client del publisher con il comportamento superato il limite.

Ottimizzazione degli iscritti

Potrebbe essere necessaria anche la regolazione degli abbonati per garantire un funzionamento affidabile. Come i publisher, puoi ottimizzare le impostazioni di controllo del flusso dei sottoscrittori per assicurarti che non si sentano sopraffatti. La libreria client sottoscrittore utilizza il pull in streaming, in cui il client apre uno stream persistente sul server e il server invia i messaggi man mano che diventano disponibili. In caso di un forte aumento dei messaggi pubblicati, l'abbonato potrebbe ricevere più messaggi di quanti possa elaborare. Con il controllo del flusso attivo, il numero di messaggi non confermati in attesa per il cliente in un determinato momento è limitato. In questo modo si riduce il numero di messaggi gestiti contemporaneamente e si suddivide la loro elaborazione su un periodo di tempo più lungo. La distribuzione del carico consente agli abbonati di rispettare le limitazioni delle risorse che influiscono sull'elaborazione dei messaggi, il che può comportare un effetto a cascata che si traduce nell'impossibilità di elaborare i messaggi.

Il controllo del flusso da solo è sufficiente se prevedi solo picchi nella quantità di dati da elaborare che alla fine si riducono. Se il traffico aumenta in genere nel tempo a causa di un maggiore utilizzo, il controllo del flusso protegge gli abbonati. Tuttavia, potrebbe verificarsi un backlog che continua ad accumularsi e che impedisce il recapito dei messaggi prima della scadenza della durata di conservazione dei messaggi. In questi casi, ti consigliamo anche di impostare l'autoscaling per aumentare il numero di iscritti in risposta a un numero crescente di messaggi non confermati. La configurazione dipende dalla piattaforma di calcolo che utilizzi per gli abbonati. Ad esempio, il ridimensionamento automatico di Compute Engine ti consente di eseguire il ridimensionamento in base a metriche come il numero di messaggi non recapitati. L'utilizzo sia della scalabilità automatica sia del controllo del flusso ti consente di garantire che i tuoi abbonati siano resilienti ad altri picchi a breve termine della velocità effettiva dei messaggi e alla crescita a lungo termine che richiede una maggiore potenza di calcolo.

Utilizza gli snapshot e cerca implementazioni sicure

La perdita di messaggi è in genere un evento catastrofico. Pub/Sub offre la consegna "almeno una volta" per tutti i messaggi pubblicati. Tuttavia, l'elaborazione corretta di questi messaggi dipende dal comportamento degli iscritti. Se i messaggi vengono confermati correttamente, Pub/Sub non li riconsegna. Pertanto, un bug introdotto nel nuovo codice dell'abbonato di cui esegui il deployment che conferma i messaggi senza averli elaborati correttamente potrebbe comportare la perdita di messaggi causata dall'abbonato. Pub/Sub offre la funzionalità di snapshot e ricerca, che può aiutarti a garantire l'elaborazione corretta di ogni messaggio, anche in caso di bug degli abbonati.

Il pattern per ogni deployment dell'abbonato deve essere il seguente:

Il tempo di attesa prima di determinare se il nuovo abbonato funziona potrebbe variare in base al caso d'uso. L'unico modo per uscire dal flusso di passaggi è quando un abbonato è considerato funzionante, a quel punto lo snapshot può essere eliminato.

L'utilizzo di snapshot e ricerca non è inteso a sostituire le best practice relative all'esecuzione iniziale del software in un ambiente non di produzione e al deployment graduale in produzione. Forniscono un livello aggiuntivo di protezione per garantire l'elaborazione affidabile dei dati. Il compromesso è che la ricerca dello snapshot potrebbe comportare l'invio duplicato di messaggi che l'abbonato ha elaborato correttamente. Tuttavia, poiché Pub/Sub ha la semantica di recapito "almeno una volta" per impostazione predefinita, i tuoi sottoscrittori sono già resilienti alla nuova consegna dei messaggi.