Messaggistica Pub/Sub nella cache: una panoramica

Questo paradigma di messaggistica Publish/Subscribe (Pub/Sub) fornisce un canale intermedio (chiamato Topic) per lo scambio di messaggi tra più applicazioni senza accoppiamento diretto tra mittente (publisher) e destinatario (subscriber). Un'applicazione publisher invia messaggi a un'applicazione subscriber tramite Topic. Poiché tutti i modelli Pub/Sub richiedono un canale di comunicazione, NCache funge da mezzo per gli argomenti in modo che l'editore pubblichi il messaggio nell'argomento. Gli abbonati ricevono il messaggio tramite l'argomento come notifica. Utilizzando NCache Come bus di messaggi, le applicazioni raggiungono elevata disponibilità e scalabilità senza accoppiamento diretto, consentendo agli editori di trasmettere eventi a migliaia di abbonati in tempo reale. Oltre a una cache distribuita, NCache fornisce anche un dedicato Cache di messaggistica Pub/Sub.

Consigli

Consigliamo una cache Pub/Sub dedicata per i seguenti motivi:

  • espulsione: se la cache contiene messaggi ed elementi della cache, l'eliminazione frequente per gli elementi della cache può anche rimuovere i messaggi prima di inoltrarli all'abbonato.

  • Trasferimento di Stato: Il trasferimento di stato aggiunge un costo a ciascuna operazione di elemento della cache. Poiché i messaggi vengono spesso pubblicati, inoltrati e scaduti, questa attività ricorrente può rivelarsi costosa perché attiva il trasferimento di stato.

Perché utilizzare la messaggistica Pub/Sub nelle architetture distribuite

Gli eventi in tempo reale richiedono la condivisione delle notifiche tra diverse applicazioni in architetture distribuite guidate dagli eventi. I modelli Pub/Sub consentono agli editori di condividere gli eventi con gli abbonati in modo che qualsiasi elaborazione desiderata avvenga al verificarsi di un evento di interesse.

Ad esempio, un gruppo di iscritti potrebbe essere interessato a informazioni sui dettagli di spedizione di un ordine, in modo da poterle elaborare per tracciarne la consegna. Pertanto, si iscriveranno a un argomento che inoltra messaggi con i dettagli dell'ordine. Una volta che l'editore pubblica un messaggio sull'argomento, gli iscritti verranno avvisati e riceveranno il messaggio contenente i dettagli dell'ordine, che potranno elaborare ulteriormente.

Componenti principali di NCache Modello Pub/Sub

I componenti di base di NCache Il modello Abbonato editore (Pub/Sub) è elencato di seguito e discusso in dettaglio in seguito:

  • Argomento: Un luogo dove vengono pubblicati i messaggi.

  • Editore: Un'applicazione (applicazione web, applicazione desktop, microservizi) che pubblica messaggi su Topic/Topics.

  • Subscriber: Un'applicazione interessata a ricevere messaggi da Topic/Topics.

  • Sottoscrizione: Un'entità di interesse creata per consentire a un abbonato di ricevere i messaggi previsti.

  • Messaggio: L'oggetto dati effettivo che l'editore invia e che gli abbonati ricevono tramite l'argomento.

Pubblica Iscriviti NCache

Argomenti in NCache

L'editore pubblica messaggi sull'argomento. Gli abbonati si iscrivono all'argomento per ricevere il messaggio. Questo argomento esiste in forma distribuita in NCachePertanto, la sua creazione avviene su tutti i nodi del cluster. Contiene l'archivio dei messaggi, che memorizza gli oggetti dati effettivi che il publisher pubblica in una coda. Mantiene inoltre internamente un elenco di tutti i sottoscrittori che vi aderiscono e un elenco dei publisher. ITopic/Topic interfaccia facilita Creazione dell'argomento, Argomento in fase di acquisizionee Eliminazione argomento. È anche possibile eliminare un argomento in modo asincrono per evitare di dover attendere l'eliminazione di un argomento.

Note:

La natura distribuita degli argomenti e dei messaggi sottostanti migliora la scalabilità.

Una volta che un messaggio viene pubblicato sull'argomento, viene attivato un evento che l'argomento inoltra agli abbonati in base alle preferenze di opzione di consegna del messaggio in modo che possano ricevere il messaggio quando necessario. La figura seguente illustra il ruolo di un Argomento come canale intermediario per editori e abbonati:

Argomenti PubSub in NCache

Note:

In caso di disconnessione temporanea dell'abbonato e successiva riconnessione automatica, tutte le informazioni relative a un argomento, come gli abbonamenti e le notifiche di eventi di errore, vengono nuovamente registrate nell'argomento senza alcuna interruzione da parte dell'abbonato.

Priorità dell'argomento

NCache Introduce la priorità a livello di argomento, che consente di assegnare livelli di priorità relativi agli argomenti in base alla loro importanza. È possibile creare argomenti con priorità più alta se devono pubblicare messaggi critici. In questo modo, tali messaggi vengono recapitati per primi. Allo stesso modo, è possibile creare argomenti con priorità inferiore se pubblicano messaggi meno critici. La cache eliminerà prima questi messaggi. È possibile semplicemente impostare Priorità a livello di argomento al momento della creazione dell'argomento per dare priorità alla consegna dei messaggi critici.

Consigli

La priorità di un argomento può essere specificata solo al momento della creazione dell'argomento e non può essere modificata in seguito.

Notifica di eliminazione dell'argomento

Per ricevere la notifica di eliminazione dell'argomento, la tua applicazione si registra per Evento OnTopicDeletedTutti i messaggi e le relative meta-informazioni presenti nella cache vengono eliminati al momento dell'eliminazione dell'argomento. Pertanto, l'abbonato e l'editore ricevono notifiche di questa eliminazione per i seguenti motivi:

  • Gli abbonati potrebbero essere in attesa di messaggi in arrivo dal Topic registrato. Una volta eliminato il Topic, gli abbonati possono quindi gestire la loro esecuzione di conseguenza tramite notifica evento ed evitare uno stato di attesa infinito.
  • L'editore può evitare di inviare messaggi a un argomento inesistente e gestire di conseguenza eventuali messaggi in sospeso e le future esecuzioni.

Pubblica messaggi su un argomento

Un editore può pubblicare messaggi in un argomento specificando un nome di argomento. I messaggi possono essere pubblicati in modo asincrono e in massa per migliorare le prestazioni dell'applicazione. Una cache partizionata distribuisce i messaggi nel cluster. Per il routing dei messaggi, ogni messaggio ha un ID univoco chiamato MessageID alla fine dell'editore e il codice hash di MessageID determina il nodo del cluster in cui archiviare il messaggio. NCache consente a un editore di utilizzare le seguenti proprietà durante la pubblicazione dei messaggi.

Note:

NCache consente di pubblicare una grande quantità di messaggi in una singola chiamata per migliorare le prestazioni e l'utilizzo della memoria.

Consigli

La notifica di mancata consegna dei messaggi è valida solo per i messaggi con scadenza.

  • Notifica di eliminazione dell'argomento: Un editore può registrarsi Notifica di eliminazione dell'argomento per impedire la pubblicazione indebita dei messaggi corrispondenti una volta eliminato l'argomento.

Iscriviti a un argomento

Una domanda di abbonato può iscriviti ai messaggi dell'argomento registrandosi a un argomento di interesse tramite un abbonamento. In Pub/Sub, un abbonamento rappresenta l'interesse di un abbonato per un argomento specifico.

Note:

Nel caso in cui un nuovo nodo venga aggiunto al cluster di cache e venga attivato il trasferimento dello stato, tutte le sottoscrizioni insieme ai messaggi e ai dati della cache vengono replicati nel nuovo nodo.

NCache consente di iscriversi a un argomento specificando un nome argomento o un pattern. Per ulteriori dettagli, fare riferimento a Modalità di abbonamento. Inoltre, puoi anche impostare modalità di consegna dei messaggi come sincrono o asincrono durante la creazione di una sottoscrizione. NCache fornisce più tipi di abbonamenti Pub/Sub che vengono discussi come segue.

Abbonamento e sue tipologie

Abbonamenti in NCache possono essere classificati nelle seguenti tipologie:

Abbonamenti durevoli e non durevoli in NCache

Durevole

Note:

Un abbonamento durevole è un abbonamento nominativo.

In un Abbonamento durevole, la cache garantisce che l'abbonato non perda alcun messaggio in caso di disconnessione dovuta all'arresto dell'applicazione/macchina, al riavvio dell'applicazione o a un guasto di rete. Pertanto, gli abbonamenti durevoli non subiscono interruzioni dovute alla disconnessione e alla riconnessione dell'abbonato.

Note:

Gli abbonamenti durevoli non vengono eliminati a meno che l'abbonato non annulli correttamente l'iscrizione.

Se un abbonato viene disconnesso, i messaggi a lui destinati vengono memorizzati su un server fino al suo rientro o alla scadenza dei messaggi. Gli abbonamenti permanenti non vengono eliminati automaticamente alla disconnessione dell'abbonato, a meno che l'abbonato non abbia correttamente annullato l'iscrizione. Un abbonamento permanente è ulteriormente classificato come:

  • Condivisa: Una Shared, Durable Subscription significa che più abbonati condividono una sottoscrizione denominata. I messaggi assegnati a una Shared Subscription vengono quindi bilanciati tra gli abbonati in modalità round-robin. Anche se un abbonato abbandona la rete, i messaggi continuano a essere recapitati agli abbonati attivi. Quindi, se un abbonato abbandona con garbo o bruscamente dopo un'assegnazione, i suoi messaggi assegnati vengono riassegnati ad altri abbonati attivi.

    Consigli

    Un abbonamento condiviso è supportato solo da un abbonamento durevole.

    In una sottoscrizione condivisa, la sottoscrizione rimarrà sull'argomento e non potrà essere annullata finché tutti gli abbonati non si saranno annullati. Ciò significa che finché ci sarà anche un solo abbonato attivo, la sottoscrizione rimarrà attiva.

  • Esclusivo: Un abbonamento esclusivo durevole significa che c'è un solo abbonato attivo registrato per un abbonamento alla volta. Se un abbonato si cancella con garbo, l'abbonamento esclusivo può essere assegnato a un nuovo abbonato. Se un abbonato se ne va all'improvviso, la nuova richiesta di abbonamento viene accettata dopo aver atteso un periodo di inattività. I ​​messaggi assegnati rimangono sempre lì anche se non c'è alcun abbonato.

Non durevole

In un Abbonamento non durevole, gli abbonati ricevono solo i messaggi a loro destinati finché rimangono connessi. Se l'abbonato abbandona la rete, non riceverà alcun messaggio pubblicato durante il periodo di disconnessione. Un abbonamento non durevole è esclusivo per impostazione predefinita.

Consigli

Gli abbonati perderanno i messaggi se l'applicazione dell'abbonato viene riavviata.

Inoltre, gli abbonamenti non durevoli vengono automaticamente eliminati quando l'abbonato abbandona la rete. Ciò significa che se quell'abbonato si riconnette o stabilisce di nuovo la connessione, verrà considerato un nuovo abbonamento.

Scadenza dell'abbonamento durevole

Puoi osservare le imposta la scadenza per un abbonamento durevole dopo un periodo di inattività, ad esempio quando non c'è un abbonato attivo per un periodo di tempo prolungato. Una volta scaduta la sottoscrizione, i messaggi assegnati a questa sottoscrizione vengono riassegnati in base al DeliveryOption di questi messaggi.

Note:

Ogni volta che l'abbonato esegue un sondaggio o esegue qualsiasi altra attività, la scadenza dell'abbonamento viene reimpostata.

Gestione degli abbonamenti inattivi

Note:

Solo gli abbonamenti non durevoli sono contrassegnati come inattivi e questo non si applica agli abbonamenti durevoli.

Nel caso in cui non vi sia un abbonato attivo rispetto a un abbonamento dopo aver atteso un determinato periodo di inattività, l'abbonamento è considerato scaduto. Se un abbonato rientra dopo la disconnessione durante il periodo di inattività, sarà in grado di ricevere i messaggi assegnati.

Consigli

Gli abbonamenti inattivi devono essere gestiti per evitare un sovraccarico di memoria sul lato server.

Dopo aver atteso il periodo di inattività, l'abbonamento è scaduto ei messaggi assegnati verranno riassegnati ad altri abbonamenti. La riassegnazione dei messaggi dipende dall'opzione di consegna dei messaggi.

  • Se il messaggio assegnato all'abbonamento A aveva l'opzione di consegna impostata su TUTTI ed è già assegnato a un altro abbonamento B prima della scadenza dell'abbonamento A, la riassegnazione non sarà necessaria.

  • Se per il messaggio assegnato a un abbonamento è stata impostata un'opzione di consegna su QUALSIASI e l'abbonamento scade, i messaggi assegnati verranno sempre riassegnati a qualsiasi altro abbonamento.

Messaggio

Un messaggio contiene l'oggetto dati effettivo che viene inviato dall'editore e recapitato agli abbonati tramite l'argomento. Una volta che l'editore pubblica il messaggio sull'argomento, gli abbonati registrati vengono avvisati che è stato pubblicato un messaggio di loro interesse. In caso di più messaggi, questi vengono memorizzati in sequenza all'interno della coda di un argomento specifico. In questo articolo, analizzeremo più approfonditamente l'assegnazione dei messaggi all'abbonamento, la consegna dei messaggi e il meccanismo di conferma.

Note:

Lo stesso messaggio può essere assegnato a più Argomenti. Questo viene identificato in modo univoco tramite un ID generato automaticamente.

Assegnazione del messaggio e consegna all'abbonamento

Inizialmente, i messaggi non sono assegnati sul lato server. Tutte le sottoscrizioni ricevono messaggi in base a DeliveryOptionUna volta assegnata una sottoscrizione, l'abbonato riceve una notifica. Quindi, l'abbonato implementa un meccanismo di polling per recuperare in blocco più messaggi, riducendo il sovraccarico lato server. Dopo aver ricevuto i messaggi, l'abbonato invia la conferma di ricezione e i messaggi vengono considerati consegnati.

Note:

I messaggi vengono archiviati nell'argomento, se non c'è un abbonato che li riceve. I messaggi vengono assegnati e consegnati al primo abbonato non appena si iscrive all'argomento.

Opzione di consegna del messaggio

Un editore deve specificare l'opzione di consegna del messaggio per decidere se il messaggio verrà recapitato a un singolo abbonato o trasmesso a tutti gli abbonati al momento della pubblicazione. È importante notare che la definizione di consegna avvenuta con successo dipende dall'opzione di consegna specificata. Le due opzioni di consegna e i corrispondenti criteri di consegna avvenuta con successo sono descritti di seguito:

  • Tutti: Tutti gli abbonati registrati ricevono i messaggi. Un messaggio viene eliminato quando tutti gli abbonati ne confermano la ricezione.

  • anno: Ogni singolo abbonato registrato riceve i messaggi. Se l'abbonato assegnato non invia la conferma, i messaggi vengono riassegnati all'abbonato successivo. Se inviano una conferma, i messaggi vengono considerati consegnati con successo.

Note:

Se un messaggio viene recapitato correttamente in base all'opzione di recapito specificata, viene rimosso dalla cache.

Archiviazione e distribuzione dei messaggi

Di seguito sono riportati gli aspetti importanti dell'archiviazione e della distribuzione dei messaggi nella cache:

  • I messaggi vengono distribuiti tra i nodi in base alle topologie.

  • Per le topologie Partition-Replica e Partitioned viene utilizzata la distribuzione basata su hash.

  • Per la topologia replicata, i messaggi vengono replicati su tutti i nodi della cache del cluster. Tuttavia, il nodo coordinatore è responsabile della manipolazione dei messaggi.

  • Per la topologia Mirror, i messaggi vengono pubblicati sul nodo attivo e quindi replicati di conseguenza sul nodo passivo.

  • Se l'archivio dei messaggi sta per essere rimosso, viene registrato un evento che indica un archivio dei messaggi completo e l'inizio dell'eliminazione.

  • I messaggi hanno un sovraccarico sulla memoria cache. Pertanto, la dimensione del messaggio deve essere presa in considerazione durante il calcolo della dimensione della cache.

Comportamento del messaggio

Qui discutiamo il comportamento previsto dei messaggi nei seguenti casi:

  • In svuota cache: I messaggi vengono rimossi insieme agli elementi della cache una volta svuotata la cache.

  • Al riavvio della cache: Analogamente alla cancellazione della cache, il contenuto della cache viene cancellato al riavvio della cache. Questo include anche tutti gli argomenti e i messaggi in essi contenuti.

  • Sfratto: If espulsione è abilitato su una cache Pub/Sub, i dati verranno rimossi prima e poi i messaggi.

  • Crittografia e compressione: If crittografia and compressione Le impostazioni sono configurate a livello di cache e si applicano anche al payload del messaggio Topic.

  • Trasferimento statale: In caso di trasferimento di stato, quando i messaggi si spostano su un altro nodo del cluster, il nodo in cui il messaggio viene infine archiviato è responsabile della consegna.

Notifica di mancata consegna del messaggio

Consigli

Un editore che si è registrato per le notifiche di mancata consegna dei messaggi riceve una notifica quando un messaggio con scadenza scade prima di essere consegnato a qualsiasi abbonato.

Nel caso in cui un messaggio non venga assegnato o consegnato a nessuno degli abbonati, viene considerato un fallimento. Può accadere quando l'abbonato non esiste o è inattivo a causa di un problema tecnico della rete. In uno scenario del genere, un editore può registrare la notifica di mancata consegna del messaggio. È importante notare che la notifica di mancata consegna è solo per i messaggi con scadenza. La consegna di un messaggio è considerata fallita quando un messaggio scade prima di essere consegnato a uno qualsiasi degli abbonati.

Note:

Se ci sono più editori su un argomento, la notifica di errore verrà recapitata a uno qualsiasi degli editori attivi che si è registrato per la notifica di errore.

Scadenza del messaggio

Simile agli elementi della cache, un editore può impostare la scadenza per i messaggi. I messaggi scadranno dalla cache non appena sarà trascorso l'intervallo di scadenza e utilizzeranno lo stesso meccanismo di intervallo di pulizia.

La scadenza di un messaggio determina il tempo in cui persiste nella cache. Indipendentemente dalla consegna, se un messaggio non viene consegnato, verrà rimosso dopo la scadenza. Se un messaggio viene recapitato correttamente prima della scadenza, viene rimosso dalla cache senza attendere la scadenza.

Messaggi ordinati

NCache ora supporta i messaggi ordinati in cui la sequenza dei messaggi viene mantenuta sul lato client. Un editore può pubblicare messaggi ordinati specificando un nome di sequenza per un blocco di messaggi. I messaggi ordinati vengono quindi recapitati agli abbonati nello stesso ordine in cui sono stati pubblicati. La stringa di sequenza deve essere la stessa per una catena di messaggi ordinati. Utilizzando la stringa di sequenza, tutti i messaggi risiedono sullo stesso nodo tramite il meccanismo di affinità di posizione. Di seguito sono riportate le caratteristiche principali dei messaggi ordinati:

Note:

La modalità di consegna sincrona può essere utilizzata per i messaggi ordinati.

  • I messaggi di un publisher con la stessa sequenza risiedono su un singolo nodo della cache.

  • Se l' DeliveryOption è impostato su Qualsiasi, tutti i messaggi ordinati della stessa sequenza vengono consegnati allo stesso abbonato. Nel caso in cui l'abbonato specifico perda la connessione o non sia disponibile, a questo scopo viene riassegnato un nuovo abbonato. Tuttavia, se il DeliveryOption è impostato su Tutti, quindi tutti i messaggi ordinati della stessa sequenza vengono consegnati a tutti gli abbonati.

  • In caso di trasferimento di stato, i messaggi ordinati potrebbero perdere la sequenza e venire pubblicati senza mantenere l'ordine.

  • I messaggi ordinati possono essere pubblicati solo utilizzando la modalità di sincronizzazione nell'API di pubblicazione. Le chiamate API in blocco e asincrone non sono supportate.

Controllo

NCache ti fornisce la possibilità di monitorare le statistiche degli argomenti Pub/Sub e di osservare vari contatori di prestazioni a questo proposito. L'attività e lo stato degli argomenti Pub/Sub possono essere monitorati tramite Contatori PerfMon di Windows and Strumenti della riga di comando.

Affidabilità e alta disponibilità

NCache implementa il meccanismo di conferma per la consegna dei messaggi. I messaggi vengono conservati in memoria finché non vengono consegnati correttamente in base al almeno una volta la consegna criteri. Quindi, NCache garantisce l'affidabilità della consegna dei messaggi per la messaggistica Pub/Sub nelle architetture distribuite.

Inoltre, tolleranza ai guasti fino a un nodo in Topologia partizione-replica rende l'archivio Pub/Sub Messaging altamente disponibile. Se un nodo lascia il cluster per qualsiasi motivo, la replica dispone del backup del messaggio.

In questa sezione

Argomenti Pub/Sub
Spiega come creare, ottenere ed eliminare argomenti per il modello Pub/Sub in NCache.

Pubblica messaggi su un argomento
Spiega come creare un argomento (Topic) e pubblicare messaggi al suo interno.

Iscriviti a un argomento
Spiega come iscriversi a un argomento e ricevere messaggi di interesse.

Eventi Pub/Sub
Spiega gli eventi Pub/Sub per notificare all'editore e all'abbonato i vari eventi che si verificano nella cache e nelle applicazioni.