Questa guida fornisce una panoramica e una panoramica delle funzionalità di affidabilità di Pub/Sub. Gli argomenti trattati in questo documento includono quanto segue:
- Perché Pub/Sub?
- Esegui il failover
- Ottimizzare i publisher
- Perfezionamento degli iscritti
- Utilizzo di snapshot e ricerca di deployment sicuri
Perché Pub/Sub?
Come paradigma di messaggistica, l'opzione Publish-subscribe è progettata per disaccoppiare i produttori di messaggi dai consumatori di tali messaggi. Invece di produttori che inviano richieste dirette ai consumatori con i dati, li pubblicano invece su un servizio Pub/Sub come Pub/Sub. Il servizio invia in modo asincrono questi messaggi ai consumatori interessati che si sono abbonati.
Il risultato è che il servizio assorbe tutte le complessità nel trovare i 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 producer di dati di scrivere messaggi su larga scala con bassa latenza, indipendentemente dal comportamento dei consumatori.
Pub/Sub offre una distribuzione di messaggi altamente scalabile e affidabile. Il servizio gestisce molto di questo aspetto automaticamente, ma tu hai il controllo su diversi aspetti dei tuoi publisher e abbonati che possono influire sulla disponibilità e le prestazioni. Nel resto della guida vengono forniti alcuni dettagli in merito.
Esegui il failover
Pub/Sub è un servizio globale: gli argomenti e le sottoscrizioni non sono intrinsecamente legati a regioni specifiche e, se necessario, i messaggi vengono trasmessi all'interno del servizio Pub/Sub tra regioni. 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 utilizzi gli endpoint a livello di regione, ad esempio
us-central1-pubsub.googleapis.com, i publisher e i sottoscrittori si connettono a Pub/Sub nella regione specificata. Quando esegui publisher o abbonati al di fuori di Google Cloud,
ti consigliamo di utilizzare gli endpoint a livello di area geografica per garantire la coerenza del flusso dei messaggi
tra le aree geografiche previste. Il resto di questa sezione spiega come creare argomenti e iscrizioni. Inoltre, vengono illustrati come posizionare publisher e abbonati per supportare diversi tipi di failover e ridondanza dei dati.
Semantica di failover predefinita
Considera un caso in cui esiste un unico argomento e una sola iscrizione. Gli editori si trovano nelle aree geografiche di Stati Uniti e Australia, mentre gli abbonati si trovano nelle aree geografiche Google Cloud di Europa e Australia. Nel caso in cui tutti i sottoscrittori dispongano di capacità sufficiente per ricevere messaggi, il flusso di messaggi sarà simile al seguente:
Le P rappresentano gli editori, le S rappresentano gli abbonati. L'esagono blu rappresenta il servizio Pub/Sub. Le bombole rappresentano i punti in cui sono archiviati i messaggi (i messaggi vengono sempre conservati in più zone nell'area geografica in cui vengono pubblicati). Pub/Sub preferisce inviare messaggi all'interno della stessa regione in cui sono stati pubblicati quando sono disponibili i sottoscrittori. In caso contrario, invia i messaggi all'area geografica della rete più vicina con i sottoscrittori che hanno capacità disponibile. Pertanto, come illustrato in precedenza, i messaggi pubblicati negli Stati Uniti vengono recapitati agli abbonati in Europa e i messaggi pubblicati in Australia rimangono in Australia.
Esaminiamo cosa accade in diversi scenari di errore.
Gli abbonati in Europa non sono disponibili
Supponiamo che gli abbonati in Europa siano stati disattivati o che si arrestano di frequente e che non riescono a mantenere una connessione a Pub/Sub. In questo caso, il servizio inizierà a recapitare i messaggi agli abbonati 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 ricollegano, i messaggi vengono recapitati, a meno che l'interruzione non superi la 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 su un argomento per un massimo di 31 giorni. Non scegliere una durata di conservazione dei messaggi inferiore al periodo di interruzione massima che ti aspetti o che sei disposto a tollerare.
Pub/Sub non è disponibile in Europa
Sebbene sia raro, potresti anche dover gestire casi in cui Pub/Sub stesso non è disponibile. L'indisponibilità di Pub/Sub si manifesta come periodi estesi di errori imprevisti di richieste di pubblicazione o di sottoscrizione oppure l'impossibilità di consegnare i messaggi pubblicati ai sottoscrittori. Ad esempio, se Pub/Sub era inattivo nella regione europea, lo scenario sembra più o meno uguale a quando gli abbonati sono inattivi:
Tieni presente che, in questo caso, gli abbonati in Europa non eseguono il failover a un'altra area geografica, anche se utilizzano l'endpoint globale. Pub/Sub non esegue il failover automatico intenzionalmente. Immaginate che siano gli abbonati stessi a causare un problema imprevisto in Pub/Sub che non sia disponibile. Un problema di questo tipo viene considerato come una grave interruzione. Tuttavia, l'ambito di applicazione dell'interruzione può essere contenuti nella regione a cui si sono connessi gli abbonati. Se il servizio ha consentito il failover in un'altra area geografica, gli abbonati potrebbero causare anche la mancata disponibilità, con un conseguente errore a cascata nell'intero servizio.
I publisher in Australia non sono disponibili
Se gli editori di una regione non sono più disponibili, i messaggi già pubblicati vengono comunque recapitati agli abbonati più vicini:
Alla fine, tutti i messaggi vengono consumati e riconosciuti dagli iscritti. Quando si inviano i messaggi, Pub/Sub cerca di ridurre al minimo la distanza di rete. Pertanto, i sottoscrittori nella regione in Australia possono interrompere la ricezione dei messaggi se i sottoscrittori 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 del servizio a livello di zona non è sufficiente per impedire il recapito dei messaggi; l'intera area geografica deve essere non disponibile. Se Cloud Pub/Sub non è più disponibile in una regione in cui i publisher stanno inviando messaggi, è possibile che i messaggi in quella regione non vengano recapitati fino al ripristino completo del servizio:
Il messaggio viene comunque consegnato (supponendo che il periodo di conservazione dei messaggi non sia trascorso), ritardato della durata dell'interruzione. Tieni presente che, come per gli abbonati, anche gli editori negli Stati Uniti non eseguono il failover in un'altra area geografica quando il servizio non funziona. Questo comportamento aiuta a evitare la probabilità di errori a cascata tra le aree geografiche a causa di un editore o di un sottoscrittore difettosi.
Isolamento
La semantica del failover predefinito influisce sull'isolamento dei dati e sull'indisponibilità di publisher, sottoscrittori o Pub/Sub stessi sul flusso dei messaggi. Il tuo caso d'uso può richiedere livelli di isolamento diversi, ad esempio potresti voler garantire il recapito all'interno della regione di tutti i messaggi.
Se non vuoi nessun isolamento, la semantica di failover predefinita dettagliata è sufficiente. Devi creare un singolo argomento, un solo abbonamento e posizionare gli editori e gli abbonati in tutte le aree geografiche desiderate. Se gli abbonati diventano non disponibili o Pub/Sub non è disponibile nell'area geografica a cui si connettono, la distribuzione non riesce per gli abbonati di un'altra area geografica.
Per l'isolamento regionale, dove è garantito che i dati non lascino una regione, crea un argomento e una sottoscrizione per gestire i messaggi in ogni regione. Individua gli editori e gli abbonati in ciascuna di queste aree geografiche e richiedi la pubblicazione e la sottoscrizione all'argomento e all'abbonamento corrispondenti, rispettivamente. Devi inoltre utilizzare gli endpoint a livello di regione per garantire che i dati si spostino solo all'interno della regione. In caso di errori di publisher, sottoscrittore o Pub/Sub in una singola regione, il recapito dei messaggi viene interrotto in tale regione. Il recapito dei messaggi per argomenti e sottoscrizioni per altre aree geografiche non è interessato.
Infine, in Pub/Sub non è possibile eseguire l'isolamento delle zone in cui i dati sono garantiti per rientrare in un'unica zona. Se hai bisogno 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 essere sempre inviati da publisher a sottoscrittori in caso di interruzione del servizio. Le interruzioni potrebbero verificarsi in diversi punti, tra cui i client, nel servizio in cui vengono eseguiti gli editori o gli abbonati, nella rete o anche raramente in Pub/Sub stesso. 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 di editori e abbonati, in cui ognuna utilizza un endpoint a livello di area geografica diverso.
Potresti voler resilire a due diversi ambiti di impatto: a livello di zona o di area geografica. Di seguito sono riportate le opzioni di configurazione per ciascun tipo.
Resilienza a livello di zona
Pub/Sub include la replica tra zone. Non devi intraprendere alcuna azione speciale per gestire le interruzioni a zona singola che interessano il servizio stesso. Tuttavia, per garantire resilienza alle interruzioni per i tuoi clienti o per la tua rete, è preferibile eseguire publisher e abbonati con capacità sufficiente in più zone all'interno dell'area geografica. Se una zona non è attiva, i client nell'altra zona sono in grado di rilevare il traffico e di elaborare i messaggi. Ti consigliamo di non implementare le modifiche a questi client contemporaneamente, in modo che, se viene introdotto un bug, le altre zone non modificate possano continuare a elaborare i messaggi.
Resilienza a livello di area geografica
Per assicurare resilienza agli errori regionali, configura ulteriori ridondanze nei tuoi editori e abbonati. Puoi eseguire publisher e abbonati in più aree geografiche per gestire la possibilità di interruzioni nei clienti o nel networking.
Se vuoi essere resiliente contro i potenziali errori di Pub/Sub in un'area geografica, devi avere un meccanismo di failover pronto per gestire tali interruzioni. I possibili approcci sono un compromesso tra la latenza di recapito dei messaggi end-to-end e il costo.
Per ridurre al minimo la latenza nel caso in cui il costo non costituisca un problema, la strategia migliore è pubblicare sempre e abbonarsi contemporaneamente in aree geografiche diverse. Per prima cosa, scegli il numero di regioni in cui vuoi la ridondanza. A questo punto, sebbene non sia strettamente necessario, puoi impostare un argomento e una sottoscrizione per ciascuna di queste aree geografiche.
Ogni editore crea tutti i client publisher esistenti (uno per ogni regione) e utilizza un endpoint a livello di area geografica diverso per garantire che i messaggi vengano indirizzati ad aree geografiche diverse. Se utilizzi argomenti separati, ogni client di pubblicazione deve pubblicare nell'argomento corrispondente per area geografica. Per ogni messaggio, le chiamate dell'editore vengono pubblicate su ciascun client. Con le pubblicazioni ridondanti, non è necessario riprovare a pubblicare se una singola non riesce.
Analogamente, ogni abbonato crea molti client di abbonato, uno per ogni regione, e utilizza un endpoint a livello di regione per connettersi a una regione diversa. Se si utilizzano abbonamenti diversi per ogni regione, ogni client abbonato deve utilizzare l'abbonamento corrispondente. Tieni presente che le regioni utilizzate per gli editori e per gli abbonati non devono necessariamente corrispondere. I sottoscrittori ricevono i messaggi delle tre sottoscrizioni e li elaborano.
Questa configurazione include diversi requisiti e funzionalità chiave:
- Qualsiasi interruzione in una singola area geografica non influisce sull'elaborazione dei messaggi già pubblicati né su quelli pubblicati durante l'interruzione. Dato che i messaggi sono stati pubblicati in più aree geografiche, saranno comunque disponibili in altre aree geografiche se questa non era attiva. Durante l'interruzione, le chiamate pubblicate non vanno a buon fine nell'area geografica interessata, ma hanno successo negli altri.
- La latenza di elaborazione dei messaggi non è interessata, a condizione che sia disponibile una qualsiasi delle aree geografiche in cui vengono inviati i messaggi.
- L'elaborazione dei messaggi deve essere idempotente. Poiché ogni messaggio verrà recapitato più volte, l'elaborazione deve essere resiliente ai duplicati. In caso di interruzione del servizio a livello di area geografica, alcuni di questi duplicati potrebbero arrivare molto più tardi della prima consegna del messaggio. È probabile che questi duplicati provengano da un'altra area geografica per 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 Google interni che si basano su Pub/Sub e richiedono la massima disponibilità, questa configurazione è quella preferita. Tuttavia, questa configurazione comporta il compromesso della moltiplicazione dei costi per la consegna dei messaggi per il numero di regioni utilizzate. È previsto anche il costo aggiuntivo dell'utilizzo della rete tra aree geografiche per i messaggi che devono essere spostati tra diverse aree geografiche.
Un altro approccio alla ridondanza consiste nel failover solo quando le richieste non vanno a buon fine o i messaggi non vengono inviati dai publisher ai sottoscrittori come previsto. In questo scenario, hai una regione principale a cui indirizzare gli editori e gli abbonati attraverso gli endpoint a livello di area geografica. Come in precedenza, non è necessario che la regione sia identica. È disponibile anche una regione di riserva per gli editori e gli abbonati utilizzata quando l'area geografica principale non è disponibile.
Gli editori pubblicano gli elementi solo nella regione principale (tramite l'endpoint a livello di regione) quando le richieste vengono inviate correttamente. Quando viene determinata che la regione non è attiva, gli editori iniziano a pubblicare nella regione di riserva. Esistono due modi per determinare se l'area geografica non è attiva e il failover può essere eseguito. Questa operazione può essere eseguita manualmente e la configurazione viene aggiornata dinamicamente negli editori. Gli editori possono anche aggiornare la configurazione autonomamente se il tasso di errore nelle richieste di pubblicazione è sufficientemente elevato.
Gli abbonati devono sempre connettersi alla regione principale tramite l'endpoint a livello di regione. Puoi decidere che l'abbonato può utilizzare l'area geografica di riserva con uno o più dei seguenti trigger:
- Iscriviti sempre alla regione di riserva. In questo caso, il sottoscrittore mantiene in ogni momento una connessione sia alla regione principale sia alla regione di riserva. Le stesse aree geografiche possono essere utilizzate per l'istanza principale e quella di riserva sia per gli editori sia per gli abbonati. In questo caso, il sottoscrittore deve ricevere i messaggi tramite l'area geografica di backup solo se l'editore ha eseguito il failover.
- Rileva manualmente e passa gli abbonati all'area geografica di riserva mediante una configurazione. Se rilevi un'interruzione, puoi eseguire il failover all'area geografica di riserva e poi tornare all'area geografica principale quando l'interruzione si è interrotta.
- Fai lo failover degli errori di iscrizione. Se le richieste dell'abbonato restituiscono errori, puoi utilizzarlo per indicare che devi eseguire il failover all'area geografica di riserva. Tieni presente che le librerie client di Pub/Sub provano a inviare internamente le richieste di pull in caso di errori temporanei, per cui potresti non riuscire a rilevare lunghi periodi inattesi. Inoltre, la percentuale di errori di pull in streaming dovrebbe essere pari al 100%, anche durante il normale funzionamento.
- Faillover se il sottoscrittore passa molto tempo senza ricevere i messaggi. Supponendo che la pubblicazione dei messaggi sia coerente, i sottoscrittori possono sempre ricevere messaggi. Se passano attraverso un periodo di tempo prolungato senza ricevere messaggi, potrebbe esserci un problema lato sottoscrizione in Pub/Sub nella regione principale. Questo problema è stato risolto eseguendo il failover all'area geografica di riserva.
Tra tutte e quattro le opzioni, la prima è ideale. La connessione all'abbonato non ha alcun costo, se non ha messaggi attivi. L'unico costo è la presenza dell'istanza aggiuntiva della libreria client dell'abbonato, che può essere trascurabile. Devi inoltre tenere presente il numero di connessioni pull di flussi di dati aperte per ogni quota della regione.
Il vantaggio di questo secondo modello è che non c'è 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 alla risoluzione dell'interruzione. I messaggi archiviati nell'area geografica che non è disponibile potrebbero non essere recapitati agli abbonati, indipendentemente da dove sono collegati. Sono disponibili messaggi pubblicati durante l'interruzione nella regione di riserva. Inoltre, potrebbe verificarsi un periodo di indisponibilità con tassi di errore maggiori per gli editori o per gli abbonati. Questo dipende dal metodo utilizzato per rilevare un'interruzione e dal tempo per il failover dell'area geografica di riserva.
Indipendentemente dall'opzione che scegli, tieni presente come questo potrebbe interagire con le funzionalità di Pub/Sub. Sia la consegna ordinata sia la consegna esatta una volta offrono le relative garanzie in un'area geografica. Ad esempio, se utilizzi la tecnica della ridondanza di failover, il recapito dei messaggi è garantito solo per i messaggi pubblicati nella stessa area geografica. Il sottoscrittore potrebbe ricevere i messaggi pubblicati nella regione di riserva prima che vengano pubblicati nella regione principale, anche se si tratta di messaggi pubblicati inizialmente nella regione principale.
Ottimizzare i publisher
Indipendentemente dalle opzioni di failover scelte, devi seguire alcuni passaggi di ottimizzazione aggiuntivi. Il miglioramento del comportamento dei publisher garantisce prestazioni ottimali in condizioni di carico elevato. I messaggi batch sono un modo per compensare la latenza a costi ridotti, ma non rappresentano un problema di affidabilità e pertanto non sono interessati. Concentrati invece su alcuni degli altri parametri utili per perfezionare l'affidabilità, incluse le impostazioni dei nuovi tentativi e quelle del controllo del flusso.
Le pubblicazioni potrebbero non riuscire per vari motivi, incluse quelle temporanee come l'indisponibilità della rete o quelle che richiedono un intervento da parte dell'utente, come le modifiche alle autorizzazioni. La libreria client Pub/Sub prova a ripetere gli errori temporanei utilizzando i parametri specificati nelle impostazioni di ripetizione. Queste impostazioni controllano il comportamento del backoff esponenziale sui nuovi tentativi di pubblicazione di RPC che non vanno a buon fine per motivi temporanei. Anche se le impostazioni predefinite possono in genere funzionare bene nella maggior parte degli scenari, ci sono situazioni in cui potresti voler ottimizzare questi valori.
Le due proprietà che più probabilmente vorrai ottimizzare sono il timeout RPC iniziale e il timeout totale. Il timeout RPC iniziale indica per quanto tempo deve essere completato il primo RPC di pubblicazione. In caso di errore o timeout di una RPC, si tenta un altro timeout 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 di Google Cloud più vicino che esegue Pub/Sub. I vincoli di rete potrebbero essere limitazioni della velocità effettiva della macchina su cui è in esecuzione l'editore oppure potrebbero essere il risultato di altri servizi in esecuzione sulla stessa macchina ad alta intensità di rete. Se il timeout è troppo breve, le RPC iniziali potrebbero non riuscire più volte e, di conseguenza, sarà necessario un maggior numero di tentativi (con timeout più lunghi) per la pubblicazione. La necessità ripetuta di nuovi tentativi aumenta la latenza di pubblicazione. In questa situazione, l'aumento del timeout iniziale potrebbe comportare una pubblicazione più rapida.
Se la connessione di rete non è affidabile, potrebbe essere utile aumentare il timeout totale e il timeout iniziale. Se il timeout totale aumenta, la pubblicazione dell'RPC ha più tempo per essere completata correttamente. Quando le RPC pubblicate superano regolarmente gli errori di scadenza, valuta la possibilità di modificare questi valori.
Gli errori di superamento continuo della data di pubblicazione possono anche indicare la necessità di regolare il controllo di flusso dell'editore. 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 capacità di CPU, memoria o rete del publisher. In caso di sovraccarico, la pubblicazione non può elaborare richieste di risposta o risposte prima del timeout. Questo si traduce in un numero ancora maggiore di richieste di pubblicazione e, in definitiva, nel timeout totale. Il controllo del flusso dell'editore limita il numero di messaggi o byte 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 opera il tuo editore, potresti consentire alle successive RPC di attendere di attendere per capacità consentendo la pubblicazione di ulteriori richieste di blocco. In alternativa, puoi respingere i chiamanti del servizio grazie al controllo del flusso che restituisce un errore quando viene raggiunta la capacità. Puoi configurare la modalità in cui la libreria client dell'editore risponde con il comportamento che supera il limite.
Perfezionamento degli iscritti
Potrebbe essere necessaria anche la sintonizzazione degli iscritti per assicurarsi che funzionino in modo affidabile. Come per gli editori, puoi regolare le impostazioni di controllo del flusso degli abbonati per assicurarti di non confondersi. La libreria client dell'abbonato utilizza il flusso pull, in cui il client apre uno stream permanente sul server e quest'ultimo invia i messaggi non appena diventano disponibili. In caso di un aumento significativo dei messaggi pubblicati, il sottoscrittore potrebbe ricevere più messaggi di quelli elaborati. Una volta impostato il controllo del flusso, il numero di messaggi non confermati in sospeso per il client in un dato momento è limitato. In questo modo ridurrai il numero di messaggi gestiti contemporaneamente e sarà possibile continuare l'elaborazione in un periodo di tempo più lungo. La distribuzione del carico consente ai sottoscrittori di rispettare eventuali limitazioni delle risorse che influiscono sull'elaborazione dei messaggi, il che potrebbe comportare un effetto a cascata che diventa incapace di elaborare i messaggi.
il solo controllo del flusso è sufficiente se prevedi dei picchi nella quantità di dati da elaborare che alla fine si ritirano. Se il traffico aumenta generalmente nel tempo a causa di un maggiore utilizzo, il controllo del flusso protegge gli abbonati. Tuttavia, questo potrebbe causare l'accumulo di un backlog che continua a verificarsi e i messaggi potrebbero non essere recapitati prima del termine della durata di conservazione dei messaggi. 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. La modalità di configurazione dipende dalla piattaforma di computing che utilizzi per i tuoi abbonati. Ad esempio, il gestore della scalabilità automatica di Google Compute Engine ti consente di scalare in base a metriche come il numero di messaggi non recapitati. L'utilizzo della scalabilità automatica e del controllo del flusso ti consente di assicurare che i tuoi abbonati siano resilienti ad altri picchi a breve termine della velocità effettiva del messaggio e di crescita a lungo termine che richiedono più potenza di calcolo.
Utilizza gli snapshot e cerca deployment sicuri
La perdita di messaggi è in genere un evento catastrofico. La pubblicazione Pub/Sub garantisce 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 consegna di nuovo. Pertanto, un bug introdotto nel nuovo codice del sottoscrittore di cui esegui il deployment che riconosce i messaggi senza averli elaborati correttamente potrebbe causare la perdita di messaggi indotti dal sottoscrittore. Pub/Sub offre la funzionalità di istantanea e ricerca, che può aiutarti a elaborare correttamente ogni messaggio, anche di fronte ai bug degli iscritti.
Il pattern di ogni deployment dell'abbonato 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 di passaggi è quando un abbonato è considerato funzionante, a quel punto è possibile eliminare lo snapshot.
L'utilizzo di snapshot e ricerca non intende sostituire le best practice relative al software per la prima esecuzione in un ambiente non di produzione e il deployment graduale in produzione. ma forniscono un ulteriore livello di protezione per garantire un trattamento affidabile dei dati. Il compromesso è che la ricerca dello snapshot può causare una doppia consegna dei messaggi che il tuo sottoscrittore ha elaborato. Tuttavia, dato che per impostazione predefinita Pub/Sub ha una semantica della consegna "una tantum", i tuoi sottoscrittori sono già resilienti alla riconsegna dei messaggi.