Pub/Sub: introduzione all'affidabilità

Questa guida fornisce una comprensione e un quadro generale delle funzionalità di affidabilità di Pub/Sub.

Perché Pub/Sub?

Come paradigma di messaggistica, la pubblicazione/sottoscrizione è progettata per disaccoppiare i producer dei messaggi dai consumer di questi messaggi. Anziché inviare richieste dirette ai consumatori con i dati, i produttori pubblicano questi dati in 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à della ricerca di consumatori interessati ai dati. Il servizio gestisce anche la velocità con cui i consumer 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 altamente scalabile e affidabile. Sebbene il servizio gestisca gran parte di questo automaticamente, hai il controllo su diversi aspetti dei tuoi editori e abbonati che possono influire sulla disponibilità e sul rendimento. Il resto di questa guida fornisce alcuni dettagli su questi aspetti.

Isolamento

Per impostazione predefinita, Pub/Sub è un servizio globale: gli argomenti e gli abbonamenti non sono intrinsecamente legati a regioni specifiche e i messaggi vengono trasferiti 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 utilizzano gli endpoint regionali, come us-central1-pubsub.googleapis.com, o gli endpoint basati sulla località, come pubsub.us-central1.rep.googleapis.com, gli editori e gli abbonati si connettono a Pub/Sub nella regione specificata. Quando esegui editori o abbonati al di fuori di Google Cloud, è consigliabile utilizzare endpoint regionali o di località per garantire che i messaggi vengano inviati in modo coerente tra le regioni previste.

Isolamento regionale

Per ridurre al minimo l'infrastruttura da cui dipendono le operazioni di pubblicazione e sottoscrizione al di fuori di una singola regione e per garantire che tutti i dati rimangano isolati in quella regione, segui questi passaggi:

1. Crea un argomento per regione.

   Sebbene lo spazio dei nomi di Pub/Sub sia globale e non sia possibile collegare argomenti e sottoscrizioni a una regione specifica, i metadati di tutte le risorse vengono replicati nei datastore locali all'interno della regione. Pertanto, una volta creata una risorsa, la sua configurazione è disponibile anche in caso di problemi in un'altra regione. Tieni presente che gli aggiornamenti alle configurazioni dell'argomento o dell'abbonamento potrebbero non essere propagati immediatamente in caso di interruzione del servizio.

2. Evita di utilizzare endpoint globali.

   Utilizza invece gli endpoint regionali dove disponibili e gli endpoint basati sulla posizione dove gli endpoint regionali non sono disponibili. Gli endpoint regionali offrono un maggiore isolamento regionale, ma non sono ancora disponibili in tutte le regioni.

3. Utilizza una policy di archiviazione messaggi e imposta enforceInTransit su True.

   Se l'opzione Applica in transito è attivata, i dati non escono mai dalla regione e tutti i client che si connettono all'argomento in una regione specifica impostano il criterio di archiviazione dei messaggi su quella regione.

Con gli argomenti configurati in questo modo, puoi essere certo che tutte le operazioni di pubblicazione e sottoscrizione scrivano e leggano i dati esclusivamente all'interno della regione. In caso di errori del publisher, del sottoscrittore o di Pub/Sub in una singola regione, la distribuzione dei messaggi si interrompe in quella regione. La distribuzione dei messaggi su argomenti e abbonamenti per altre regioni non è interessata.

Se hai bisogno che anche le operazioni amministrative e lo spazio dei nomi degli argomenti e degli abbonamenti siano isolati a livello regionale, valuta la possibilità di utilizzare Managed Service per Apache Kafka.

Failover

Se non hai bisogno dell'isolamento regionale, ti consigliamo di sfruttare la capacità di Pub/Sub di distribuire i messaggi in modo efficiente in più regioni per ottenere funzionalità di failover multiregionale. Il resto di questa sezione spiega come creare argomenti e abbonamenti e posizionare publisher e abbonati per supportare diversi tipi di failover e ridondanza dei dati.

Semantica di failover predefinita

Prendiamo in considerazione un caso in cui sono presenti un singolo argomento e una singola sottoscrizione. Gli editori si trovano nelle regioni degli Stati Uniti e dell'Australia, mentre gli abbonati si trovano nelle Google Cloud regioni di Europa e Australia. Nel caso in cui tutti gli abbonati abbiano capacità sufficiente per ricevere messaggi, il flusso di messaggi è il seguente:

Figura 1. Tutti gli iscritti hanno capacità sufficiente per ricevere messaggi.

La P sta per publisher, la S per iscritti. L'esagono blu rappresenta il servizio Pub/Sub. I cilindri rappresentano i luoghi in cui vengono archiviati i messaggi (i messaggi vengono sempre archiviati in più zone della regione in cui vengono pubblicati). Pub/Sub preferisce inviare i messaggi nella stessa regione in cui sono stati pubblicati quando sono disponibili sottoscrittori. In caso contrario, invia i messaggi alla regione più vicina alla rete con sottoscrittori che hanno capacità. Pertanto, come mostrato nell'immagine precedente, i messaggi pubblicati negli Stati Uniti vengono inviati agli iscritti in Europa e i messaggi pubblicati in Australia rimangono in Australia.

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

Gli iscritti in Europa non sono disponibili

Supponiamo che gli abbonati in Europa siano stati rifiutati o che si verifichino arresti anomali frequenti e non riescano a mantenere una connessione a Pub/Sub. Se ciò si verificasse, il servizio inizierebbe a inviare messaggi agli abbonati in Australia:

Figura 2. Gli abbonati in Europa non sono disponibili.

Gli iscritti in Europa e Australia non sono disponibili

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

Figura 3. Gli abbonati in Europa e Australia non sono disponibili.

Una volta che gli abbonati si riconnettono, i messaggi vengono consegnati, a meno che l'interruzione non duri più a lungo del periodo di conservazione dei messaggi configurato. Per impostazione predefinita, la conservazione dei messaggi della sottoscrizione è 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 che prevedi o sei disposto a tollerare.

Pub/Sub non è disponibile in Europa

Sebbene rari, potresti anche dover gestire casi in cui Pub/Sub stesso non è disponibile. L'indisponibilità di Pub/Sub si manifesta con periodi prolungati di errori imprevisti nelle richieste di pubblicazione o sottoscrizione oppure con l'impossibilità di consegnare i messaggi pubblicati ai sottoscrittori. Ad esempio, se Pub/Sub non è disponibile nella regione in Europa, lo scenario è molto simile a quando gli abbonati non sono disponibili:

Figura 4. Pub/Sub non è disponibile in Europa.

Tieni presente che in questo caso i sottoscrittori in Europa non eseguono il failover in un'altra regione, anche se utilizzano l'endpoint globale. Pub/Sub non esegue il failover automaticamente. Immagina che siano gli stessi abbonati a causare un problema imprevisto in Pub/Sub che comporta l'indisponibilità. Un problema di questo tipo viene trattato come un'interruzione importante. Tuttavia, l'ambito dell'impatto dell'interruzione può essere limitato alla regione a cui si sono connessi gli abbonati. Se il servizio consentisse il failover in un'altra regione, i sottoscrittori potrebbero causare l'indisponibilità anche 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 più disponibili, i messaggi già pubblicati vengono comunque inviati ai sottoscrittori più vicini:

Figura 5. I publisher in Australia non sono disponibili.

Alla fine, tutti i messaggi vengono utilizzati e confermati dagli abbonati. Quando invii messaggi, Pub/Sub tenta di ridurre al minimo la distanza di rete. Pertanto, gli abbonati nella regione dell'Australia possono smettere di ricevere messaggi se gli abbonati in Europa hanno 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 a livello di zona non è sufficiente a 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 consegnati finché il servizio non viene completamente ripristinato:

Figura 6. Pub/Sub non è disponibile negli Stati Uniti.

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

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 in caso di interruzione ovunque nel mezzo. Le interruzioni possono verificarsi in diversi punti, inclusi i client, il 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 publisher e abbonati, ognuna delle quali utilizza un endpoint di localizzazione diverso.

Potresti volere la resilienza a due diversi ambiti di impatto: zonale o regionale. 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 eseguire passaggi speciali per gestire le interruzioni di una singola zona che interessano il servizio stesso. Tuttavia, per garantire la resilienza alle interruzioni per i tuoi client o la tua rete, è consigliabile eseguire publisher e subscriber con capacità sufficiente in più zone all'interno della regione. Se una singola zona non è disponibile, i client nell'altra zona sono in grado di raccogliere il traffico ed elaborare i messaggi. È una best practice non pubblicare contemporaneamente le modifiche a questi client, in modo che, se viene introdotto un bug, le altre zone non modificate possano continuare a elaborare i messaggi.

Nota: per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.

Resilienza regionale

Per garantire la resilienza ai guasti a livello regionale, configura ulteriori ridondanze nei publisher e negli abbonati. Puoi eseguire publisher e sottoscrittori in più regioni per far fronte alla possibilità di interruzioni in questi client o nel networking.

Se vuoi essere resiliente a potenziali errori di Pub/Sub in una regione, devi disporre di un meccanismo di failover pronto a gestire un'interruzione di questo tipo. Gli approcci possibili 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 il costo non sia un problema, la strategia migliore è pubblicare e sottoscrivere 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 localizzazione diverso per garantire che i messaggi vengano indirizzati a regioni distinte. Se utilizzi argomenti separati, ogni client publisher deve pubblicare nell'argomento corrispondente per regione. Per ogni messaggio, l'editore chiama publish su ogni client. Con le pubblicazioni ridondanti, non è necessario riprovare a pubblicare se una singola pubblicazione non va a buon fine.

Allo stesso modo, ogni abbonato crea altrettanti client abbonati, uno per ogni regione, e utilizza un endpoint basato sulla posizione 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 i publisher e gli abbonati non devono necessariamente essere le stesse. I sottoscrittori ricevono i messaggi nelle tre sottoscrizioni e li elaborano.

Questa configurazione presenta diverse funzionalità e requisiti chiave:

1. Un'interruzione a livello di 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 vanno a buon fine nella regione interessata, ma riescono nelle altre.
2. La latenza di elaborazione dei messaggi non è interessata finché è disponibile una delle regioni attraverso cui scorrono i messaggi.
3. L'elaborazione dei messaggi deve essere idempotente. Poiché ogni messaggio verrà recapitato più volte, l'elaborazione dei messaggi deve essere resiliente ai duplicati. In caso di interruzione a livello regionale, alcuni di questi duplicati potrebbero arrivare molto più tardi rispetto alla prima volta che il messaggio è stato recapitato. Questi duplicati probabilmente provengono da una regione diversa che non ha subito un'interruzione.

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 è preferibile. Tuttavia, questa configurazione comporta il compromesso di moltiplicare il costo per la distribuzione dei messaggi per il numero di regioni utilizzate. Esiste anche il costo aggiuntivo dell'utilizzo della rete interregionale per i messaggi che devono spostarsi tra le regioni.

Un altro approccio alla ridondanza consiste nel eseguire il failover solo quando le richieste non vanno a buon fine o i messaggi non vengono inviati dagli editori agli abbonati come previsto. In questo scenario, hai una regione primaria a cui indirizzi i tuoi publisher e abbonati tramite endpoint basati sulla posizione. Come in precedenza, non devono necessariamente trovarsi nella stessa regione. In questo modo, avrai 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 localizzazione) quando le richieste vengono inviate correttamente. Quando viene stabilito che la regione non è disponibile, i publisher iniziano a pubblicare nella regione di fallback. La determinazione che la regione è inattiva e il failover può essere eseguito in due modi. Può essere eseguito tramite una procedura manuale e la configurazione viene aggiornata dinamicamente negli editori. Gli editori possono anche aggiornare autonomamente la configurazione se il tasso di errori nelle richieste di pubblicazione è sufficientemente elevato.

Gli abbonati devono sempre connettersi alla regione principale tramite l'endpoint di localizzazione. Puoi decidere che l'abbonato possa utilizzare la regione di riserva con uno o più dei seguenti attivatori:

1. Esegui sempre la sottoscrizione alla regione di riserva. In questo caso, l'abbonato mantiene una connessione sia alla regione principale sia alla regione di failover in qualsiasi momento. Le stesse regioni possono essere utilizzate per la primary e il fallback sia per gli editori sia per gli abbonati. In questo caso, il sottoscrittore deve ricevere messaggi tramite la regione di backup solo se il publisher ha eseguito il failover.
2. Rileva e passa manualmente gli abbonati alla regione di fallback 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 del sottoscrittore. Se le richieste degli abbonati restituiscono errori, puoi utilizzarli come indicazione che devi eseguire il failover nella regione di fallback. Tieni presente che le librerie client Pub/Sub riprovano internamente le richieste pull di streaming in caso di errori temporanei, pertanto potresti non essere in grado di rilevare lunghi periodi di errori imprevisti. Inoltre, il tasso di errori di pull dello streaming dovrebbe essere del 100%, anche durante il normale funzionamento.
4. Esegui il failover se il sottoscrittore rimane per un periodo di tempo inaspettatamente lungo senza ricevere messaggi. Supponendo che i messaggi vengano pubblicati in modo coerente, gli abbonati possono sempre ricevere messaggi. Se trascorrono un periodo di tempo prolungato senza ricevere messaggi, potrebbe esserci un problema lato sottoscrizione in Pub/Sub nella regione principale. Questo problema viene risolto eseguendo il failover alla regione di failover.

Delle quattro opzioni, la prima è quella ideale. Una connessione di abbonato non costa nulla se non vengono scambiati messaggi. L'unico costo è l'ingombro dell'istanza aggiuntiva della libreria client del sottoscrittore, che può essere trascurabile. Devi anche tenere presente la quota del numero di connessioni StreamingPull aperte per regione.

Il vantaggio di questo secondo modello è che non esiste 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' interruzione potrebbero non essere disponibili fino a quando l'interruzione non viene risolta. I messaggi memorizzati nella regione non disponibile potrebbero non essere recapitati agli iscritti, indipendentemente da dove si connettono. I messaggi pubblicati durante l'interruzione nella regione di failover potrebbero essere disponibili. Inoltre, potrebbe verificarsi un periodo di indisponibilità con tassi di errore maggiori per i publisher o gli abbonati. Dipende dal metodo utilizzato per rilevare un'interruzione e dal tempo necessario per eseguire il failover nella regione di fallback.

Indipendentemente dall'opzione scelta, tieni presente come 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 fallback prima di quelli pubblicati nella regione principale, anche se i messaggi sono stati pubblicati prima nella regione principale.

Ottimizzazione dei publisher

Indipendentemente dall'opzione di failover scelta, ci sono alcuni passaggi di ottimizzazione aggiuntivi che devi eseguire all'interno dei publisher stessi. La regolazione del comportamento del publisher garantisce prestazioni ottimali in condizioni di carico elevato. L'invio in batch dei messaggi è un modo per bilanciare la latenza con la riduzione dei costi, ma non è un problema di affidabilità e pertanto non è trattato qui. Concentrati invece su altri parametri utili per migliorare l'affidabilità, tra cui le impostazioni di nuovi tentativi e 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, come le modifiche alle autorizzazioni. La libreria client Pub/Sub riprova a eseguire le operazioni in caso di errori temporanei utilizzando i parametri specificati nelle impostazioni di ripetizione. Queste impostazioni controllano il comportamento del backoff esponenziale nei nuovi tentativi di RPC di pubblicazione che non vanno a buon fine per motivi temporanei. Sebbene le impostazioni predefinite in genere funzionino bene nella maggior parte degli scenari, ci sono situazioni in cui potresti voler ottimizzare questi valori.

Le due proprietà che probabilmente vorrai 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 va a buon fine o scade il timeout, viene riprovata con un timeout più lungo finché non viene superato il numero totale di richieste o il timeout totale.

Il timeout iniziale può essere modificato se l'editore è vincolato dalla rete o si trova lontano dal data center Google Cloud più vicino che esegue Pub/Sub. I vincoli di rete potrebbero essere limitazioni alla velocità effettiva della macchina su cui viene eseguito il publisher o potrebbero essere il risultato di altri servizi in esecuzione sulla stessa macchina che richiedono un utilizzo intensivo della 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 riprovare aumenta la latenza di pubblicazione. In questa situazione, aumentare il timeout iniziale potrebbe comportare pubblicazioni più rapide.

Se la connessione di rete non è affidabile, aumentare il timeout totale e il timeout iniziale potrebbe essere utile. Un timeout totale maggiore offre alla RPC di pubblicazione più tempo per essere completata correttamente. Quando le RPC di pubblicazione non riescono costantemente a causa di errori di scadenza superata, valuta la possibilità di modificare questi valori.

Gli errori di superamento continuo della scadenza durante la pubblicazione possono anche indicare la necessità di ottimizzare il controllo del flusso dell'editore. Queste impostazioni ti consentono di assicurarti che i tuoi 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 è sovraccarica, non è in grado di elaborare richieste o risposte di pubblicazione prima dei timeout. Ciò comporta un numero ancora maggiore di richieste di pubblicazione e, in definitiva, 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 mantiene 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 capacità consentendo alla pubblicazione di bloccare ulteriori richieste. In alternativa, puoi rimandare la richiesta ai chiamanti del tuo servizio facendo in modo che il controllo del flusso restituisca un errore quando viene raggiunta la capacità. Configura il modo in cui la libreria client publisher risponde con il comportamento di superamento del limite.

Ottimizzazione degli iscritti

Potrebbe essere necessario anche l'aggiustamento dell'abbonato per garantire un funzionamento affidabile. Come i publisher, puoi modificare le impostazioni di controllo del flusso degli iscritti per assicurarti che non siano sopraffatti. La libreria client sottoscrittore utilizza il pull in streaming, in cui il client apre un flusso persistente al server e il server invia i messaggi non appena diventano disponibili. In caso di un forte aumento dei messaggi pubblicati, l'abbonato potrebbe ricevere più messaggi di quanti ne possa elaborare. Con il controllo del flusso in atto, il numero di messaggi non confermati in attesa di essere inviati al client in un determinato momento è limitato. In questo modo si riduce il numero di messaggi gestiti contemporaneamente e la loro elaborazione viene distribuita su un periodo di tempo più lungo. La distribuzione del carico consente ai sottoscrittori di rimanere al di sotto di eventuali limitazioni delle risorse che influiscono sull'elaborazione dei messaggi, il che può comportare un effetto a cascata che si sviluppa nell'impossibilità di elaborare qualsiasi messaggio.

Il controllo del flusso è sufficiente se prevedi solo 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, potrebbe verificarsi un arretrato che continua ad accumularsi e impedisce la consegna dei messaggi prima del termine del periodo di conservazione. 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 configurazione dipende dalla piattaforma di calcolo che utilizzi per i tuoi abbonati. Ad esempio, lo scalatore automatico di Compute Engine consente di scalare in base a metriche come il numero di messaggi non recapitati. L'utilizzo sia dello scalabilità automatica sia del controllo del flusso ti consente di garantire che i tuoi abbonati siano resilienti ad altri picchi a breve termine nella velocità effettiva dei messaggi e alla crescita a lungo termine che richiede maggiore potenza di calcolo. Assicurati di seguire le best practice per l'utilizzo delle metriche Pub/Sub come segnale di scalabilità.

Utilizza snapshot e cerca deployment sicuri

La perdita di messaggi è solitamente un evento catastrofico. Pub/Sub offre la consegna at-least-once 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 invia nuovamente. Pertanto, un bug introdotto nel nuovo codice di abbonato che implementi e che conferma i messaggi senza averli elaborati correttamente potrebbe comportare la perdita di messaggi indotta dall'abbonato. Pub/Sub offre la funzionalità snapshot e ricerca, che può aiutarti a garantire l'elaborazione corretta di ogni messaggio, anche in presenza di bug del sottoscrittore.

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

Figura 7. Pattern per il deployment degli abbonati.

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

L'utilizzo di snapshot e ricerca non ha lo scopo di sostituire le best practice relative all'esecuzione iniziale del software in un ambiente non di produzione e al deployment graduale in produzione. forniscono un ulteriore livello di protezione per garantire l'elaborazione affidabile dei dati. Il compromesso è che la ricerca dello snapshot potrebbe comportare la consegna duplicata dei messaggi che l'abbonato ha elaborato correttamente. Tuttavia, dato che Pub/Sub ha una semantica di distribuzione "at-least-once" per impostazione predefinita, i tuoi abbonati sono già resilienti alla nuova distribuzione dei messaggi.