Questa guida fornisce una comprensione e un quadro generale delle funzionalità di affidabilità di Pub/Sub. Gli argomenti trattati nel presente documento includono:
- Perché Pub/Sub?
- Esegui il failover
- Ottimizzare i publisher
- Ottimizzare gli iscritti
- Utilizzo di snapshot e ricerca per deployment sicuri
Perché Pub/Sub?
Come paradigma di messaggistica, publish-subscribe è progettato per disaccoppiare i produttori dei messaggi dai consumatori di tali messaggi. Invece di inviare richieste dirette ai consumer con i dati, 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 di 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 data producer 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. Anche se il servizio gestisce gran parte di questo automaticamente, hai il controllo su diversi aspetti dei tuoi publisher e abbonati che possono influire sulla disponibilità e sulle prestazioni. Nella parte restante della guida vengono forniti alcuni dettagli su questi aspetti.
Esegui il failover
Pub/Sub è un servizio globale: gli argomenti e le sottoscrizioni non sono intrinsecamente associati a regioni specifiche e i messaggi vengono inviati al servizio Pub/Sub da un'area geografica all'altra quando necessario. Quando utilizzi l'endpoint globale, pubsub.googleapis.com,
publisher e abbonati si connettono alla regione più vicina alla rete in cui
è in esecuzione Pub/Sub. Quando utilizzi endpoint basati sulla località, come us-central1-pubsub.googleapis.com, publisher e sottoscrittori si connettono a Pub/Sub nella regione specificata. Quando si eseguono editori o abbonati al di fuori di Google Cloud,
è preferibile utilizzare endpoint basati sulla località per garantire che i messaggi vengano eseguiti in modo coerente tra
le regioni previste. Il resto di questa sezione spiega come creare argomenti e sottoscrizioni. Viene inoltre descritto come posizionare publisher e sottoscrittori per supportare diversi tipi di failover e ridondanza dei dati.
semantica di failover predefinita
Considera un caso in cui ci siano un unico argomento e una sola sottoscrizione. Gli editori si trovano nelle regioni degli Stati Uniti e in Australia, mentre gli abbonati si trovano nelle regioni di Google Cloud in Europa e Australia. Nel caso in cui tutti i sottoscrittori abbiano capacità sufficiente per ricevere messaggi, il flusso dei messaggi sarà simile al seguente:
Le P rappresentano gli editori, mentre le S rappresentano gli abbonati. L'esagono blu rappresenta il servizio Pub/Sub. I cilindri rappresentano i luoghi in cui sono archiviati i messaggi (i messaggi vengono sempre salvati in modo permanente in più zone dell'area geografica in cui sono 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 più vicina alla rete con sottoscrittori dotati di capacità. Pertanto, come mostrato nell'immagine precedente, i messaggi pubblicati negli Stati Uniti vengono recapitati agli abbonati in Europa, mentre quelli pubblicati in Australia rimangono in Australia.
Le seguenti sezioni descrivono cosa accade nei diversi scenari di errore.
Gli abbonati in Europa non sono disponibili
Supponiamo che gli abbonati in Europa siano stati disattivati o che si arrestano spesso in modo anomalo e non siano in grado di mantenere una connessione a Pub/Sub. In questo caso, il servizio inizierà a consegnare i messaggi agli abbonati in Australia:
Gli abbonati in Europa e Australia non sono disponibili.
Se tutti i sottoscrittori non sono 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 dell'abbonamento è impostata su sette giorni. Puoi anche configurare la conservazione dei messaggi per un argomento fino a 31 giorni. Non scegliere una durata di conservazione dei messaggi inferiore a quella massima che ti aspetti o che sei disposto a tollerare.
Pub/Sub non è disponibile in Europa
Sebbene sia raro, potresti voler gestire anche i casi in cui Pub/Sub stesso non è disponibile. La mancata disponibilità di Pub/Sub si manifesta come lunghi periodi di errori imprevisti nelle richieste di pubblicazione o sottoscrizione oppure come impossibilità di recapitare messaggi pubblicati ai sottoscrittori. Ad esempio, se Pub/Sub non si trovava in una regione europea, lo scenario è simile a 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 utilizzano 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 ne causa l'indisponibilità. Questo problema 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 consentiva il failover in un'altra regione, gli abbonati potrebbero causare l'indisponibilità in quella regione, causando un errore a cascata in tutto il servizio.
Gli editori in Australia non sono disponibili
Se gli editori in una regione 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 di rete. Pertanto, i sottoscrittori nell'area geografica in Australia possono smettere di ricevere 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 un'area geografica. Pertanto, un'interruzione a livello di zona non è sufficiente per impedire la consegna dei messaggi; l'intera regione deve essere non disponibile. Se Cloud Pub/Sub non è disponibile in una regione in cui gli editori inviano messaggi, i messaggi in quella regione potrebbero non essere recapitati fino al ripristino completo del servizio:
Il messaggio è ancora stato recapitato (supponendo che il periodo di conservazione non sia trascorso) in ritardo rispetto 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 quando il servizio non funziona. Questo comportamento aiuta a prevenire la probabilità che si verifichino errori a cascata tra le regioni a causa di un editore o un abbonato difettoso.
Isolamento
La semantica del failover predefinita influisce sull'isolamento dei dati e sul modo in cui l'indisponibilità di publisher, sottoscrittori o 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 all'interno della regione di tutti i messaggi.
Se non vuoi che venga eseguita l'isolamento, la semantica del failover predefinita è sufficiente. Devi creare un singolo argomento, un singolo abbonamento e inserire publisher e abbonati in tutte le regioni selezionate. Se i sottoscrittori non sono più disponibili o Pub/Sub non è attivo nella regione a cui si connettono, la consegna ai sottoscrittori di un'altra regione non riesce.
Per l'isolamento a livello di regione, per il quale è garantito che i dati non lascino una regione, crea un argomento e una sottoscrizione per gestire i messaggi in ogni regione. Individuare editori e abbonati in ciascuna di queste regioni e fare in modo che pubblichino e si abbonino rispettivamente all'argomento regionale e all'abbonamento corrispondenti. Devi inoltre utilizzare endpoint a livello di regione per assicurarti che i dati vengano spostati solo all'interno della regione. In caso di errori dell'editore, del sottoscrittore o di Pub/Sub in una singola regione, la consegna dei messaggi si interrompe in quella regione. La consegna dei messaggi per argomenti e abbonamenti per altre regioni non è interessata.
Infine, in Pub/Sub non è possibile isolare la zona, in cui viene garantita la permanenza dei dati 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 di failover predefinita di Pub/Sub potrebbe non garantire completamente che i messaggi possano sempre passare dai publisher ai sottoscrittori in caso di interruzione del servizio. Le interruzioni possono verificarsi in diversi punti, inclusi i tuoi clienti, nel servizio su cui vengono eseguiti i publisher 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 ciascuna utilizza un endpoint di località diverso.
Potresti volere la resilienza a due diversi ambiti di impatto: a livello di zona o a livello di regione. Di seguito sono riportate le opzioni di configurazione per ciascuna opzione.
Resilienza a livello di zona
Pub/Sub ha la replica tra zone integrata. Non devi seguire alcun passaggio speciale per affrontare le interruzioni in una singola zona che interessano il servizio stesso. Tuttavia, per garantire resilienza alle interruzioni dei servizi dei clienti o della rete, l'esecuzione di publisher e sottoscrittori con capacità sufficiente in più zone all'interno della regione è consigliabile. Se una singola zona non è attiva, i client nell'altra zona sono in grado di recuperare il traffico ed elaborare i messaggi. Come best practice, non pubblicare le modifiche su questi client contemporaneamente in modo che, se viene introdotto un bug, l'altra zona non modificata possa continuare a elaborare i messaggi.
Resilienza a livello di regione
Per garantire resistenza agli errori a livello di regione, configura ridondanze aggiuntive nei publisher e negli abbonati. Puoi gestire editori e abbonati in più regioni per far fronte alla possibilità di interruzioni in questi client o nel networking.
Se vuoi garantire resilienza contro potenziali errori di Pub/Sub in una regione, devi disporre di un meccanismo di failover pronto per affrontare questa interruzione. Gli approcci possibili sono un compromesso tra la latenza di consegna end-to-end dei messaggi e il tuo costo.
Per ridurre al minimo la latenza nel caso in cui il costo non sia un problema, la strategia migliore è pubblicare e sottoscrivere sempre contemporaneamente in diverse regioni. Scegli prima il numero di regioni in cui vuoi la ridondanza. Quindi, anche se non è strettamente necessario, puoi configurare un argomento e un abbonamento per ciascuna di queste aree geografiche.
Ogni editore crea un numero illimitato di client di editore quante sono le regioni (una per ogni regione) e utilizza un endpoint di località diverso per garantire che i messaggi siano indirizzati a regioni distinte. Se utilizzi argomenti separati, ogni editore client deve pubblicare nell'argomento corrispondente per area geografica. Per ogni messaggio, l'editore chiama "Pubblica" su ciascun cliente. Con le pubblicazioni ridondanti, non è necessario riprovare a pubblicarle se una di queste non va a buon fine.
Allo stesso modo, ogni abbonato crea tanti client abbonato, uno per ogni regione, e utilizza un endpoint di località per connettersi a una regione diversa. Se utilizzi abbonamenti diversi per ogni area geografica, ogni client abbonato deve utilizzare l'abbonamento corrispondente. Tieni presente che le regioni utilizzate per gli editori e gli abbonati non devono necessariamente corrispondere. I sottoscrittori ricevono messaggi tra le tre sottoscrizioni e li elaborano.
Questa configurazione ha diversi requisiti e funzionalità principali:
- Qualsiasi interruzione di 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 nel caso in cui una regione non fosse disponibile. Durante l'interruzione, le chiamate di pubblicazione non andranno a buon fine nella regione interessata, ma avranno esito positivo nelle altre.
- La latenza dell'elaborazione dei messaggi non è interessata, purché sia disponibile una delle aree geografiche attraverso le quali sono in transito i messaggi.
- L'elaborazione dei messaggi deve essere idempotente. Poiché ogni messaggio verrà recapitato più volte, l'elaborazione dei messaggi deve essere resiliente in caso di duplicati. In caso di interruzione regionale, alcuni dei duplicati potrebbero arrivare molto più tardi rispetto alla prima consegna del messaggio. Quei duplicati probabilmente provenivano da un'altra regione in cui non c'era un'interruzione.
L'esecuzione con questo tipo di ridondanza fornisce la massima resilienza a qualsiasi tipo di interruzione. Questa configurazione è preferibile per i servizi interni di Google che si basano su Pub/Sub e richiedono la massima disponibilità. Tuttavia, questa configurazione comporta il compromesso ottenuto moltiplicando il costo per la 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 prevede il failover solo quando le richieste non vanno a buon fine o i messaggi non passano dagli editori ai sottoscrittori come previsto. In questo scenario, hai una regione principale a cui indirizzi i tuoi publisher e abbonati tramite endpoint basati sulla località. Come in precedenza, questi elementi non devono necessariamente coincidere con la stessa area geografica. Inoltre, hai a disposizione una regione di riserva per editori e abbonati che viene utilizzata quando la regione principale non è disponibile.
Gli editori pubblicano solo nella regione principale (tramite l'endpoint di località) 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. Esistono due modi per determinare che un'area geografica non è attiva e che l'errore persiste. Può essere eseguita da una procedura manuale e la configurazione viene aggiornata dinamicamente nei publisher. 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 di località. Puoi decidere che l'abbonato possa utilizzare la regione di riserva con uno o più dei seguenti attivatori:
- Abbonati sempre alla regione di riserva. In questo caso, il sottoscrittore mantiene sempre una connessione sia alla regione principale sia alla regione di riserva. Le stesse regioni possono essere utilizzate per la regione principale e di riserva sia per i publisher 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 e imposta manualmente i sottoscrittori alla regione di riserva tramite una configurazione. Se rilevi un'interruzione, puoi eseguire il failover nella regione di riserva per poi tornare alla regione principale una volta che l'interruzione è terminata.
- Fai il failover per gli errori degli iscritti. Se le richieste dell'abbonato restituiscono errori, puoi utilizzarlo come indicazione che devi eseguire il failover nella regione di riserva. Tieni presente che le librerie client di Pub/Sub ritentano l'invio di flussi di richieste di pull internamente in caso di errori temporanei, quindi potresti non essere in grado di rilevare se si verificano lunghi periodi di errori imprevisti. Inoltre, la percentuale di errore di pull dello streaming dovrebbe essere del 100%, anche durante il normale funzionamento.
- Fai il failover se il sottoscrittore attraversa un periodo di tempo inaspettatamente lungo senza ricevere messaggi. Supponendo che la pubblicazione dei messaggi avvenga in modo coerente, i sottoscrittori possono sempre ricevere messaggi. Se passano per un periodo di tempo prolungato senza ricevere alcun messaggio, potrebbe esserci un problema sul lato di sottoscrizione in Pub/Sub nell'area geografica principale. Questo problema viene risolto eseguendo il failover dell'area geografica di riserva.
Tra tutte e quattro le opzioni, la prima è l'ideale. La connessione di un abbonato non prevede alcun costo se non riceve messaggi. L'unico costo è rappresentato dall'impatto dell'istanza aggiuntiva della libreria client del sottoscrittore, che può essere trascurabile. Devi inoltre tenere conto del numero di connessioni pull in modalità flusso aperte per quota regione.
Il vantaggio di questo secondo modello è che non è previsto un moltiplicatore nel costo di Pub/Sub poiché i messaggi vengono pubblicati una sola volta. Tuttavia, il compromesso è che, per alcuni tipi di interruzioni, i messaggi pubblicati prima dell'inizio dell'interruzione potrebbero non essere disponibili fino a dopo la risoluzione dell'interruzione. I messaggi archiviati in un'area geografica non disponibile potrebbero non essere recapitati ai sottoscrittori, indipendentemente da dove sono connessi. Potrebbero essere disponibili i messaggi pubblicati durante l'interruzione nella regione di riserva. Inoltre, potrebbe verificarsi un periodo di indisponibilità con un aumento dei tassi di errore per gli editori o gli abbonati. Ciò dipende dal metodo utilizzato per rilevare un'interruzione e dal tempo di failover nella regione di riserva.
A prescindere dall'opzione che scegli, tieni presente come può interagire con le funzionalità di Pub/Sub. Sia la consegna ordinata sia la consegna "esattamente" offrono le loro garanzia all'interno di una regione. Ad esempio, se utilizzi la tecnica di ridondanza di failover, è garantita la consegna dei messaggi solo per i messaggi pubblicati nella stessa regione. Il sottoscrittore potrebbe ricevere i messaggi pubblicati nell'area geografica di fallback prima di quelli pubblicati nell'area geografica principale, anche se prima erano stati pubblicati nell'area geografica principale.
Ottimizzare i publisher
Indipendentemente dall'opzione di failover che scegli, puoi eseguire alcuni passaggi di ottimizzazione aggiuntivi all'interno dei publisher. L'ottimizzazione del comportamento del publisher garantisce prestazioni ottimali in condizioni di carico elevato. Il raggruppamento dei messaggi in batch è un modo per trovare un compromesso tra la latenza e i costi ridotti, ma non è un problema di affidabilità e, di conseguenza, non è trattato qui. Concentrati invece su alcuni degli altri parametri utili per ottimizzare l'affidabilità, tra cui le impostazioni dei nuovi tentativi e del controllo del flusso.
La pubblicazione potrebbe non riuscire per diversi motivi, inclusi quelli temporanei come l'indisponibilità della rete o quelli che richiedono un intervento dell'utente, come la modifica delle autorizzazioni. La libreria client Pub/Sub esegue un nuovo tentativo per gli errori temporanei utilizzando i parametri specificati nelle impostazioni per il nuovo tentativo. Queste impostazioni controllano il comportamento del backoff esponenziale nei nuovi tentativi di pubblicazione di RPC che non riescono per motivi temporanei. In genere, le impostazioni predefinite funzionano bene nella maggior parte degli scenari, ma ci sono situazioni in cui è consigliabile ottimizzare questi valori.
Le due proprietà che con maggiore probabilità vorrai ottimizzare sono il timeout RPC iniziale e il timeout totale. Il timeout RPC iniziale corrisponde al tempo di completamento della prima RPC di pubblicazione. In caso di errore o timeout di una RPC, un'altra RPC viene tentata 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 è distante dal data center Google Cloud più vicino in cui viene eseguito Pub/Sub. I vincoli di rete potrebbero rappresentare limitazioni sulla velocità effettiva della macchina su cui è in esecuzione il publisher o essere il risultato di altri servizi in esecuzione sulla stessa macchina che utilizzano molta rete. Se il timeout è impostato su un valore troppo breve, le RPC iniziali potrebbero non riuscire più volte, con la conseguente necessità di ulteriori tentativi (con timeout più lunghi) per la pubblicazione corretta. La ripetuta necessità di nuovi tentativi aumenta la latenza di pubblicazione. In questo caso, 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 quello iniziale. Un timeout totale maggiore dà alla RPC di pubblicazione più tempo per il completamento. Se le RPC di pubblicazione continuano a non riuscire con errori di superamento della scadenza, valuta la possibilità di ottimizzare questi valori.
Il superamento di una scadenza continua al momento della pubblicazione potrebbe indicare anche 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 forte aumento delle richieste in uscita potrebbe sovraccaricare la CPU, la memoria o la capacità di rete del publisher. Quando la pubblicazione è sovraccarico, non è in grado di elaborare le richieste o le risposte di pubblicazione prima dei timeout. Questo comporta un numero ancora maggiore di richieste di pubblicazione e, alla fine, 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 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 publisher, puoi consentire alle RPC di pubblicazione successiva di attendere la capacità, consentendo la pubblicazione per bloccare ulteriori richieste. In alternativa, puoi respingere i chiamanti del tuo servizio facendo in modo che il controllo del flusso restituisca un errore quando viene raggiunta la capacità. Puoi configurare il modo in cui la libreria client dell'editore risponde con il comportamento del limite superato.
Ottimizzare gli iscritti
Inoltre, potrebbe essere necessaria l'ottimizzazione degli iscritti per garantirne l'affidabilità. Come per gli editori, puoi ottimizzare le impostazioni di controllo del flusso degli abbonati per evitare di sovraccaricare gli abbonati. La libreria client dell'abbonato utilizza il pull in modalità flusso, 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 potrebbe ricevere più messaggi di quanti ne possa 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 ne viene distribuita l'elaborazione per un periodo di tempo più lungo. La distribuzione del carico consente agli abbonati di rispettare qualsiasi limitazione delle risorse che influisca sull'elaborazione dei messaggi, il che può comportare un effetto a cascata che può portare all'impossibilità di elaborare i messaggi.
Il solo controllo del flusso è sufficiente se ti aspetti solo dei picchi nella quantità di dati da elaborare che alla fine si riducono. Se il traffico solitamente aumenta 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 impedisce la consegna dei messaggi prima che sia trascorsa la durata di conservazione dei messaggi. In questi casi, potresti anche impostare la scalabilità automatica in modo da aumentare il numero di abbonati 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 Compute Engine consente di scalare in base a metriche come il numero di messaggi non consegnati. L'utilizzo sia della scalabilità automatica che del controllo dei flussi ti consente di garantire che i tuoi abbonati siano resilienti ad altri picchi a breve termine nella velocità effettiva dei messaggi e nella crescita a lungo termine che richiedono una maggiore potenza di calcolo.
Usa gli snapshot e cerca per deployment sicuri
La perdita di messaggi è in genere un evento catastrofico. Pub/Sub offre la consegna "at least once" per 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 consegna nuovamente. Di conseguenza, un bug introdotto nel codice del nuovo sottoscrittore di cui esegui il deployment che conferma i messaggi senza averli elaborati correttamente potrebbe causare la perdita di messaggi indotta dal sottoscrittore. Pub/Sub offre la funzionalità snapshot e ricerca, che può aiutarti a elaborare correttamente ogni messaggio, anche di fronte a bug degli abbonati.
Il pattern per il deployment di ogni abbonato deve essere il seguente:
Il tempo di attesa prima di determinare se il nuovo abbonato sta lavorando può variare in base al caso d'uso. L'unico modo per uscire dal flusso dei passaggi è quando un abbonato è considerato in attività, dopodiché lo snapshot può essere eliminato.
L'utilizzo di snapshot e ricerca non è pensato per sostituire 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. Il compromesso è che la ricerca dello snapshot può comportare la consegna duplicata di messaggi che il tuo sottoscrittore ha elaborato con successo. Tuttavia, poiché Pub/Sub ha una semantica di consegna "atleast-once" per impostazione predefinita, i tuoi sottoscrittori sono già resilienti alla riconsegna dei messaggi.