NCache Architettura
Oggi parlerò di NCache Architettura. NCache è un archivio distribuito in memoria per applicazioni .NET e Java. È estremamente veloce e scalabile. Inoltre, puoi utilizzarlo nelle tue applicazioni server ad alte transazioni per migliorare le prestazioni e la scalabilità delle tue applicazioni.
Usi comuni di NCache
Cache distribuita
I due modi comuni NCache si usa. Il numero uno è come a Cache distribuita dove si memorizzano nella cache i dati dell'applicazione per ridurre quei costosi viaggi nel database e, il numero due è a Messaggistica e flussi piattaforma. Esaminerò brevemente entrambi prima di entrare nell'architettura.
-
Memorizzazione nella cache dei dati dell'app
Pertanto, nella cache distribuita, la memorizzazione nella cache dei dati dell'applicazione implica l'utilizzo di un file NCache L'API di solito memorizza solo nella cache i dati dell'applicazione, quindi non è necessario accedere al database con la stessa frequenza perché la cache è molto più veloce del database. È anche più scalabile perché è in memoria, quindi è veloce. È vicino alla tua applicazione, quindi è veloce ed è distribuito, quindi è scalabile. Inoltre, se disponi di un'applicazione .NET e usi EF Core, puoi utilizzare NCache anche tramite EF Core e anche NHibernate ed EF 6. Se disponi di applicazioni Java puoi utilizzare NCache come cache di secondo livello di ibernazione. Puoi anche usarlo con come Spring Cache oppure puoi programmarlo contro JCache. -
Memorizzazione nella cache dell'app Web
La seconda parte dell'utilizzo della cache distribuita è, se disponi di applicazioni Web, che puoi archiviare i tuoi file sessioni in NCache poi NCache replica queste sessioni su più server, in modo che se ce n'è uno NCache server che va giù in modo da non perdere alcun dato ma queste sessioni sono ancora una volta scalabili perché è un archivio distribuito ed è ovviamente super veloce. È inoltre disponibile una funzionalità di sessione multisito in tutti i linguaggi .NET, Java, Nodejs, ecc. Oltre alle sessioni, ad esempio, per .NET 6, ASP.NET Core le applicazioni possono memorizzare i propri file Cache delle risposte inserita NCache e possono anche usare NCache la backplane per SignalR. SignalR è destinato alle applicazioni Web live in cui l'app Web deve inviare eventi ai client. Inoltre, se utilizzi .NET 4.8 puoi anche memorizzare lo stato della sessione, Visualizza stato, Cache di outpute anche SignalR.
NCache per app mission-critical
Lascia che ti mostri rapidamente cosa NCache sembra. Ecco di cosa si tratta come cache distribuita per applicazioni mission-critical. Uso la parola mission-critical perché nella maggior parte dei casi vediamo che i clienti lo utilizzano NCache in applicazioni molto sensibili rivolte ai clienti e sono molto importanti per la loro attività. COSÌ, NCache è, sai, parte della tua infrastruttura molto critica in quel caso.
E queste sono, come ho detto, applicazioni server ad alta transazione. Queste sono applicazioni web. Si tratta di microservizi, API Web o altre applicazioni server. Ovviamente puoi eseguire .NET, Java, Node.js o Python. Inoltre, queste applicazioni stanno tentando di accedere al tuo database come SQL Server, Oracle, Db2, MySQL o qualsiasi altro database relazionale, oppure stanno accedendo forse ai tuoi dati mainframe legacy o forse stanno utilizzando un NoSQL database come Mongo DB, Cosmos DB, Cassandra o altri. In questa situazione, NCache diventa una cache distribuita da... che usi NCache come due o più server con un livello di caching separato, anche se non è necessario disporre di un livello di caching separato, l'applicazione può essere eseguita nella stessa casella di NCache e funziona perfettamente, ma l'architettura di distribuzione più popolare è quella di avere un livello di memorizzazione nella cache separato, è semplicemente un modo più pulito di utilizzo NCache.
Quindi, diciamo, inizi con un cluster di cache a 2 server, NCache grappolo, NCache raggruppa la memoria, la CPU, le risorse della scheda di rete di tutti questi server in un'unica capacità logica e, diciamo, stai caricando più transazioni attraverso le tue applicazioni su NCache e questi due server sono al massimo, puoi facilmente aggiungere un terzo server, o un quarto server, o un quinto server e, così via, NCache non diventa mai un collo di bottiglia. Questo è qualcosa che non puoi fare con i tuoi database. I database non sono scalabili. NoSQL è scalabile ma, nella maggior parte dei casi, abbiamo scoperto che le persone devono utilizzare database relazionali per una serie di motivi aziendali e dispongono anche di mainframe legacy. Quindi, perché il livello di archiviazione dei dati non è scalabile NCache aiuta la scalabilità della tua applicazione consentendoti di memorizzare nella cache quanti più dati possibile. L'obiettivo generale è avere circa l'80% delle volte in cui dovresti trovare i dati NCache piuttosto che andare nel tuo database. Se riesci a raggiungere questo rapporto, allora, sai, hai allentato la pressione sui database e la tua applicazione sarà scalabile.
Messaggistica e flussi
Il secondo caso d'uso comune, o utilizzo di NCache è usarlo come piattaforma di messaggistica e flussi in cui è possibile avere più applicazioni in grado di comunicare tra loro Messaggistica Pub/Sub, attraverso Interrogazione continua, o NCache eventi basati. Lascia che ti mostri come appare. Quindi, ad esempio, se disponi di un'applicazione server con transazioni elevate che necessita di eseguire molti messaggi in tempo reale o elaborazione di flussi, puoi utilizzare NCache. Adesso lo stesso NCache quella che era una cache distribuita ora diventa una piattaforma di messaggistica e flussi. Ancora una volta, è un archivio distribuito in memoria. Si ridimensiona in modo lineare. Replica i messaggi su più server. Infatti, NCache contiene anche Persistenza.
Quindi, con questo, puoi avere diverse applicazioni, ad esempio, la messaggistica Pub/Sub è un modo molto popolare, è una metodologia, è un paradigma in cui hai più editori e più abbonati che possono comunicare tra loro in modo disaccoppiato. Disaccoppiato significa che l'editore non sa chi è l'abbonato, pubblica semplicemente messaggi su determinati argomenti e questi abbonati possono riceverli. Le query continue funzionano allo stesso modo. Quindi, questi sono i due modi comuni NCache viene utilizzato.
.NET e applicazioni Java
Ora parliamo di come NCache gestisce applicazioni .NET e Java. NCache ha una capacità multipiattaforma nativa davvero unica che troverai molto interessante, lasciami entrare in questo.
Edizione .NET
NCache cerca di fornire una soluzione nativa sia per .NET che per Java. E con questo intendo che quando hai un'applicazione .NET l'intero stack di applicazioni sperimenta .NET, non stai utilizzando altro che .NET. Quindi, ad esempio, NCache ha un client .NET nativo che è ciò che la tua applicazione utilizzerà sulla tua applicazione. Questo viene eseguito sul server delle applicazioni e NCache lo ha sviluppato in 'C Sharp' (C#), al 100%.
Allo stesso modo, se disponi di codice lato server come Read-through, Write-through, Right-behind, Loader/Refresher che hai scritto in .NET, NCache eseguirà il codice nel proprio processo .NET CLR. Lascia che ti mostri come. E tornerò su questo diagramma avanti e indietro. Quindi, ad esempio, ecco un NCache architettura hai un'applicazione .NET qui che potrebbe essere in esecuzione su Windows o Linux. Ha un nativo NCache Cliente .NET. E questo sta parlando con un NCache cluster che è un'edizione .NET NCache Grappolo. Ciò significa quindi che anche il codice lato server è .NET.
Ora il modo NCache è progettato e, questo è il motivo per cui ciò che lo rende davvero potente per il supporto nativo multipiattaforma, è che esiste un processo di cache, esiste un processo di gestione, questi sono separati dal processo di codice lato server. Ed è disponibile un RPC ad altissime prestazioni. È un RPC in memoria NCache usa, quello NCache ha sviluppato un proprio RPC proprietario che è superveloce. Quindi, è così che la cache comunica con il tuo codice lato server. Pertanto, ad esempio, se deve chiamare il gestore Read-through, il gestore Read-through verrà eseguito all'interno di questo processo CLR .NET per accedere al database per ottenere i dati e quindi passarli alla cache. E la stessa cosa vale per Write-through, Loader e Refresher. Pertanto, l'intera esperienza offerta dalla tua applicazione è .NET.
Edizione Java
Bene, passiamo al lato Java. Ancora una volta, allo stesso modo, hai un codice lato server Java. NCache ha un client Java al 100% che viene eseguito sul server delle applicazioni e quindi allo stesso modo di .NET. Ecco l'edizione Java. Diciamo che hai un'applicazione Java che molto probabilmente potrebbe essere in esecuzione su Linux, o forse anche su Windows, forse Docker, forse Kubernetes. Quindi, quell'applicazione incorporerà il file NCache Java Client che, come ho detto proprio qui, è Java nativo al 100%, quindi questo Java Client è sostanzialmente identico al client .NET. Si parla anche con il NCache Eseguire il clustering nello stesso modo in cui lo fa il client .NET utilizzando NCacheil protocollo socket proprietario di e il NCache server è progettato in modo tale che il codice Java lato server venga eseguito sulla propria JVM.
Pertanto, tutto lo sviluppo, i test e il debug che eseguirai saranno tutti nei processi JVM nativi. E questo processo di cache chiamerà, diciamo, il gestore Read-through che entrerà, diciamo, forse in Oracle o Db2, o anche nel database SQL Server e otterrà i dati e li fornirà al processo di cache. Anche in questo caso viene utilizzato lo stesso RPC in memoria ad alte prestazioni. Quindi, avendo un'architettura che incapsula il codice .NET e Java nei rispettivi processi nativi, NCache è in grado di fornirti uno stack nativo sia per Java che per .NET.
E, sempre nel caso di un'applicazione Java, potresti voler eseguire lo sviluppo su Windows o Mac OS e NCache lo supporta completamente, o anche Linux e, quindi, è più probabile che utilizzi Docker e Kubernetes rispetto a quelli di .NET NCache ti fornisce le immagini Docker e quindi anche il supporto completo per Kubernetes, Azure AKS, AWS EKS, Google GKE o Red Hat OpenShift. Puoi usarlo in modo molto semplice.
Così, NCache è davvero unico. Ti offre un'esperienza .NET nativa e allo stesso tempo un'esperienza Java nativa. Quindi, se sei un negozio Java non hai la sensazione di utilizzare un prodotto non Java e se sei un negozio .NET non hai la sensazione di utilizzare un prodotto non . prodotto NETTO. Questa è la bellezza di NCache il modo in cui è architettato.
Cluster dinamico
Ok, entriamo ora nel Clustering dinamico parte NCache Architettura che garantisce la disponibilità elevata. E un secondo, okay. Quindi, la prima parte è il Dynamic Cluster. Quando uso la parola cluster non intendo Kubernetes Cluster, qualsiasi altro cluster a livello di sistema operativo. Questo è NCacheil proprio cluster basato su TCP. Inoltre, questo cluster ha un'architettura peer-to-peer. Ciò che significa peer-to-peer è che non c'è nessun padrone, non c'è schiavo. Il problema del master/slave è che se il master non funziona, lo slave diventa inoperativo o limitato, mentre in un'architettura peer-to-peer ogni nodo è ugualmente capace. Esiste ovviamente un nodo coordinatore del cluster, che è il nodo più vecchio e, quindi, se quel nodo dovesse mai smettere di funzionare, il successivo più vecchio verrà automaticamente selezionato come coordinatore del cluster. Il coordinatore del cluster fa l'appartenenza al cluster. Gestisce la mappa di distribuzione, l'integrità del cluster e un sacco di altre cose di cui parlerò in parte.
Il clustering dinamico significa che puoi aggiungere o rimuovere server al cluster in fase di esecuzione senza interrompere la cache o l'applicazione. Non c'è interruzione. E, quando, diciamo, aggiungi un nuovo server al cluster, l'appartenenza al cluster viene ovviamente aggiornata in fase di esecuzione e le informazioni di runtime vengono quindi propagate ai client. E ne parlerò un po' di più nella prossima diapositiva.
È disponibile anche una funzionalità di failover della connessione cluster. Quindi, poiché si tratta di socket, anche se i server cluster di solito si trovano nella stessa sottorete abbastanza vicini tra loro, ma potrebbe non essere sempre così. Abbiamo clienti che hanno server distribuiti anche in diverse regioni e funziona perfettamente, anche se consigliamo che nella maggior parte dei casi il NCache i server dovrebbero essere abbastanza vicini l'uno all'altro. Tuttavia, potrebbe verificarsi ancora un errore di connessione. Se le cose stanno così NCache ha una logica di tentativi e sono presenti timeout. C'è la logica del battito cardiaco, tutto questo per assicurarsi che sia tutto dinamico.
Client dinamici e configurazione dinamica
Connessioni client dinamiche
L'altra parte dell'architettura dinamica sono i Dynamic Client. Quindi, proprio in questo modo, il cluster aveva la possibilità di aggiungere o rimuovere server in fase di runtime e hai anche la possibilità di aggiungere o rimuovere client in fase di runtime. Cosa significa cliente? Un cliente è il NCache Client che viene eseguito sul tuo server applicativo, il tuo server web, questa è la parte con cui comunica la tua applicazione. Pertanto, puoi aggiungere un client in fase di runtime e rimuovere un client in fase di runtime senza fermarti NCache, la cache o l'applicazione senza alcuna interruzione. Quindi, questa è la prima parte.
Configurazione dinamica
La seconda parte è la Configurazione Dinamica. Pertanto, come ho accennato nell'ultima diapositiva, quando aggiungi un server al cluster, l'appartenenza al cluster cambia. Bene, questo viene propagato a tutti i client esistenti che sono connessi, in modo che ora sappiano che c'è un nuovo server a cui devono connettersi. Pertanto, se scelgono di farlo in base alla topologia di memorizzazione nella cache, possono connettersi anche a quel server. Inoltre, a seconda della topologia potrebbe esserci una mappa di distribuzione. Una mappa di distribuzione è più adatta per la cache partizionata e la cache di replica partizionata. Ma quando aggiungi un server, questo viene aggiornato e questo viene propagato in fase di esecuzione. E anche un sacco di altre modifiche alla configurazione. Esiste una funzionalità di applicazione a caldo che puoi eseguire e che viene propagata in fase di esecuzione. Quindi, questa è la seconda parte.
Failover della connessione client
La terza parte è che, ancora una volta, c'è un failover della connessione client che è identico al failover della connessione cluster. Ma questo è in realtà ancora più necessario perché i client probabilmente non saranno sempre molto vicini ai server del cluster. E potrebbero esserci alcuni router o firewall nel mezzo. Pertanto, è più probabile che la connessione tra i client e il cluster si interrompa. COSÌ, NCache ha una capacità di tentativo abbastanza intelligente, timeout. Esiste anche la funzionalità keep-alive, in modo che il client rimanga connesso anche se la connessione si interrompe, il client si riconnette al NCache Grappolo.
Rilevamento e recupero del cervello diviso
Un altro argomento importante dell'aspetto dinamico di NCache L’architettura è il cervello diviso. Lo Split Brain è un fenomeno che può verificarsi nell'ammasso.
Lo split-brain si verifica alla rottura della connessione
Inoltre, Split Brain si verifica ogni volta, diciamo, se si dispone di un cluster sano di sei server, si verifica uno split-brain quando la connessione tra alcuni di questi server si interrompe per qualche motivo e, ogni volta che si hanno connessioni di rete, queste possono interrompersi. E lo vediamo continuamente. Quindi, quando ciò accade, si formano i sottogruppi. Diciamo che in questo caso c'è una divisione 1, una divisione 2, una divisione 3. Ogni sottogruppo pensa di essere il sopravvissuto. Quindi, crea il proprio coordinatore del cluster e diventa un cluster indipendente.
Rilevamento del cervello diviso
Tuttavia, tutte queste divisioni ricordano che facevano parte di un cluster sano e questi server non se ne sono andati volontariamente, non se ne sono andati in modo fluido. Non hai eseguito un 'abbandono del nodo' dal file NCache Management Tool invece la connessione si è interrotta. Quindi continueranno a cercare questi server per vedere se la connessione di rete viene ripristinata. E, nella maggior parte dei casi, forse cinque, dieci minuti, mezz'ora, un'ora dopo, è molto probabile che la connessione venga ripristinata.
Recupero del cervello diviso
Quando ciò accade, viene eseguito uno Split Brain Recovery. Ed è quello in cui queste divisioni si fondono. Questi sottocluster vengono uniti in modo iterativo dal più grande al più piccolo e, ovviamente, si verifica una certa perdita di dati perché questi sono diventati cluster indipendenti e ora alcuni dati devono essere persi. Ma tutto viene eseguito automaticamente in base alle regole specificate.
Ci sono maggiori dettagli sul cervello diviso in un articolo separato video ma questo ti dà una panoramica. È una caratteristica molto importante che garantisce che il tuo NCache il cluster rimane sano e può riprendersi ogni volta che si verifica una divisione del cervello.
Topologie di memorizzazione nella cache
Ok, ora entriamo Topologie di memorizzazione nella cache. Le topologie di memorizzazione nella cache riguardano essenzialmente l'archiviazione dei dati, le strategie di replica e anche le strategie di connessione del client. Esistono quattro topologie, una è Partitioned Cache, Partition Replica, Replicated Cache e Mirrored Cache. Andiamo con Cache partizionata.
Cache partizionata
Cache partizionata è fondamentalmente che l'intera cache è suddivisa in partizioni, ogni server ha una partizione. E c'è questo concetto di secchi. Quindi, ogni partizione ha dei bucket. Un totale di 100 bucket per l'intera cache. Quindi, a seconda di quante partizioni hai, quei bucket saranno equamente divisi tra loro.
E queste partizioni vengono create in fase di esecuzione, questa è la parte importante in questo. Pertanto, quando aggiungi un server, viene creata una partizione. Diciamo che inizi con un server, c'è solo una partizione e tutti i 100 bucket sono in quella partizione. Se aggiungi un secondo server in fase di esecuzione, non solo vengono aggiornate le informazioni sull'appartenenza al cluster di cui ho parlato nelle diapositive precedenti, ma ora viene aggiornata anche la mappa di distribuzione. Una mappa di distribuzione è essenzialmente una mappa di quale partizione contiene quali bucket. Quindi, diciamo, se hai aggiunto una seconda partizione, la mappa di distribuzione ora verrà modificata. Una mappa di distribuzione è in realtà una mappa hash mappata sui bucket. Il valore della mappa hash varia in bucket. Inoltre, questo non cambia in base alla quantità di dati aggiunti, cambia solo quando si modifica il numero di server, il numero di partizioni o si esegue il ribilanciamento dei dati. Quindi, le partizioni sono dinamiche.
Bilanciamento dinamico dei dati
La seconda parte è che esiste un bilanciamento dinamico dei dati. Quindi, poiché tutto questo è basato sulla mappa hash, è molto probabile che in base al tipo di chiavi utilizzate alcuni bucket ottengano più dati di altri. E ti ritroverai con alcune partizioni quasi piene e le altre quasi vuote. E, quando ciò accade, il NCache ha questa funzione in cui puoi impostare una soglia. Diciamo che se una partizione diventa piena per più dell'80%, rimuoverne il 20%, o il 10%, o il 5%. Non rimuovere, intendo bilanciarlo dinamicamente. Pertanto, il bilanciamento dei dati significa prendere quei bucket dalla partizione 1 e copiarli su un'altra o spostarli su altre partizioni. Pertanto, il bilanciamento dei dati garantisce che i dati e tutte le partizioni siano abbastanza uniformi.
Il client si connette a tutte le partizioni
In Partitioned Cache ogni client si connette a tutte le partizioni o a tutti i server. Il motivo per cui lo fa è perché vuole accedere direttamente a qualsiasi elemento desideri in una chiamata. Se fosse connesso solo a un server, diciamo, e volesse l'elemento numero 3, parlerà con il server 1, il Server 1 andrà al server 2 e lo otterrà. Inoltre, si tratta di un'operazione a due hop che non è così ottimizzata come se il client potesse andare direttamente dove si trovavano i dati. E il cliente lo sa grazie a una mappa di distribuzione. Ecco perché viene creata la mappa di distribuzione per aiutare i clienti a sapere dove si trovano i dati, in modo che possano andare a prenderli direttamente da lì.
Pertanto, Partitioned Cache non ha replica. Quindi, se un server non funziona, perdi quei dati. Non c'è modo se non usi 'Persistence' di cui parlerò tra poco. Quindi anche la cache partizionata non perde alcun dato.
Cache di replica partizione
Repliche di partizioni (dinamiche)
La topologia successiva è la cache di replica delle partizioni. Questa è comunque la nostra topologia più popolare perché ti offre il meglio di entrambi i mondi. Ti dà il partizionamento, che è la scalabilità. E ti dà anche la replica che è l'alta disponibilità. Quindi, non c'è perdita di dati. Quindi, ad esempio, è come Partitioned Cache, tutto è uguale ma ogni partizione ora ha una replica su un server diverso. Quindi, la partizione uno si trova sul Server 1, quindi la sua replica si chiama Replica 1 che è, diciamo, in questo caso sul Server 2. Quindi, proprio come le partizioni sono state create dinamicamente al momento, anche le repliche vengono create in fase di runtime, quando le partizioni vengono aggiunti o rimossi. E ovviamente si trovano sempre su un server diverso.
L'altra parte è che tutte le repliche sono passive. Passivo significa che nessun cliente parla direttamente con loro. I client significano che parlano solo con le partizioni e le partizioni aggiornano quindi la loro replica. Pertanto, ogni volta che aggiorni qualcosa nella partizione, la partizione lo aggiorna nella replica. Inoltre, l'aggiornamento per impostazione predefinita è asincrono. Asincrono è, in modo che possa essere più veloce. Prima di tutto il client non deve attendere che avvenga la replica, in secondo luogo è possibile eseguire una replica di massa. Pertanto, puoi combinare centinaia o migliaia di questi aggiornamenti insieme e spostarli o inviarli alla replica contemporaneamente. Perché il costo di questo viaggio in rete è molto più rapido o molto più costoso rispetto alla combinazione dei dati.
Replica asincrona/sincronizzazione
Tuttavia, la replica asincrona ovviamente non è sempre coerente. Alla fine è coerente, il che è abbastanza buono forse dal 95% al 99% delle volte e forse dall'1 al 5% dei casi in cui hai a che fare con dati molto sensibili. Quindi, non vuoi la replica asincrona, vuoi la replica sincrona. Quindi, esiste una funzionalità chiamata Replica di sincronizzazione che puoi attivare e, quando lo fai, ogni volta che il client aggiorna gli elementi nella partizione, l'operazione non viene completata finché la partizione non aggiorna prima la replica. Pertanto, se la replica fallisce, l'operazione fallisce. Quindi, è così che, se l'operazione è riuscita, anche la replica ha avuto successo. Quindi, questa è una caratteristica molto importante di questo.
E, infine, proprio come la topologia partizionata, la topologia della cache partizionata c'è anche il bilanciamento dinamico dei dati sulle repliche. Pertanto, quando le partizioni vengono bilanciate dinamicamente dai dati, le repliche devono corrispondere perché le repliche sono sempre una copia identica della partizione. Quindi, passeranno anche attraverso un bilanciamento dei dati.
Partizionamento dinamico
Esaminiamo ora rapidamente come avviene realmente il partizionamento dinamico. Quindi, diciamo, se avessi un cluster di due server e avessi 6 elementi al suo interno e volessi aggiungere un terzo server, non aggiungerò ancora altri dati perché questo è un altro caso d'uso, ecco come sono i dati spostato su altre partizioni quando aggiungi un altro nodo.
Diciamo che aggiungi un nodo. Quindi ora c'è un terzo server. Quindi, viene creata la Partizione 3 e la Partizione 3 ora riceve i dati dalla Partizione 1 e dalla Partizione 2. Quindi, ottiene alcuni dati da 1 altri da 2. Quindi, diciamo, diciamo che prende l'Elemento 3 dalla Partizione 1, l'Elemento 4 dalla Partizione 2 e diventa Partizione 3.
Ora, che è diventata la Partizione 3, la sua replica deve trovarsi su un server diverso, quindi, diciamo, viene messa sul Server 1. Quindi, il Server 1 aveva la Replica 2, viene convertito in Replica 3 e quindi la Replica 2 viene spostata nel Server 3. Quindi, ad esempio, ora Replica 3 conterrà 3, 4 invece di 4, 5, 6 e Replica 2 conterrà 5, 6. Tutto ciò verrà eseguito dinamicamente in fase di esecuzione senza che l'applicazione veda qualsiasi interruzione.
La stessa cosa accade all'indietro che se un server va giù, diciamo, avevi tre partizioni NCache Cluster e, Server 3 è andato giù, o l'hai abbassato tu o è andato giù, non appena ciò accade, perché la Partizione 3 non è più disponibile Replica 3, come puoi vedere ho cambiato colore, diventa attiva. Normalmente, come dicevo, le repliche non sono attive, giusto? Sono attive solo le partizioni ma ora questa diventa partizionata. Ma è solo temporaneo perché non vuoi avere due partizioni sulla stessa scatola e quindi nessuna replica.
Quindi, ora questo si fonde qui con la Partizione 1, quindi, diciamo, l'Elemento 3 va alla Partizione 1, l'Elemento 4 va alla Partizione 2, e la tua situazione è così qui e questa Replica 3 ora diventa Replica 2. Quindi, il la stessa cosa accade all'indietro, tutto in fase di runtime, partizionamento dinamico, molto molto flessibile, molto dinamico. Questa dinamicità aggiunge il potere di elevata disponibilità di NCache.
Modalità di manutenzione
Bene, anche se il partizionamento dinamico è molto utile e molto potente, ci sono alcuni casi in cui non si desidera ripartizionare e uno di questi casi è la manutenzione programmata. Diciamo che stai eseguendo una patch del sistema operativo e che la patch arresterà il server per cinque o dieci minuti. Bene, sai che l'intero cluster di cache potrebbe contenere decine di gigabyte di dati. Quindi, non vuoi ripartizionare solo per quei cinque minuti e poi ripartizionare di nuovo quando riattivi il nodo. Quindi, puoi attivare una funzione di manutenzione programmata di NCache nel qual caso quando disattivi questo nodo, devi di nuovo disattivarlo tramite lo strumento di gestione, si attivano cose per cui questa replica diventa attiva ma non c'è ripartizionamento.
Quindi, rimane una configurazione a due server con Partizione 1 Replica 3, Partizione 2 Replica 1 e questa Replica 3 è in realtà Partizione 3, il che significa che è attiva e funziona. Ovviamente, non si tratta di disponibilità elevata perché sebbene qui venga eseguito il backup della partizione 1. La partizione 2 non ha backup e la replica 3 non ha backup. Ma questo è solo temporaneo perché ne hai bisogno solo per 5, 10 minuti. Quindi, una volta ripristinato, questo server torna al vecchio stato e diventa di nuovo una replica quando diventa di nuovo una partizione. Quindi, ecco come funziona la funzionalità di manutenzione programmata NCache .
Cache replicata
La topologia successiva è chiamata a Cache replicata. In questa topologia è possibile avere due o più server in cui ogni server ha una copia intera della cache e ogni server è attivo, il che significa che a ogni server sono collegati dei client. Ma qui ogni client si connette solo a un server. Perché quel server ha l'intera cache. Pertanto, non è necessario connettersi a due server come partizione o replica della partizione.
Con questa topologia, tutte le letture sono superveloci perché l'intera cache è proprio lì, ma gli aggiornamenti devono essere eseguiti in modo sincrono. Poiché entrambi sono server attivi, lo stesso elemento potrebbe essere aggiornato qui e qui contemporaneamente e ovviamente non vuoi affrontare un problema di integrità dei dati. Quindi, viene eseguito in modo sincrono in cui esiste uno schema di indicizzazione, c'è un indice, in realtà viene emesso un numero di sequenza e ogni elemento viene aggiornato nella stessa sequenza. Ciò consente quindi di eseguire gli aggiornamenti sempre in modo corretto. Tuttavia, il costo è che un aggiornamento sincrono significa che se si dispone di un client che aggiorna l'Elemento 1, questo server notificherà all'Elemento 2 di aggiornare l'Elemento 1. Quando entrambi i server hanno aggiornato con successo l'Elemento 1, solo allora l'aggiornamento ha esito positivo e il controllo risale. Ciò significa quindi che non è veloce come la topologia Partition o Partition Replica, ma l'operazione è garantita, se l'aggiornamento ha esito positivo significa che viene sempre eseguito su tutti i server.
Questa topologia è utile per le operazioni ad alta intensità di lettura. Per un cluster a due server anche le scritture sono piuttosto veloci, non quanto la replica della partizione ma ragionevolmente veloci per la maggior parte delle situazioni. Tuttavia, man mano che si aggiungono più server, le prestazioni degli aggiornamenti diminuiscono. In realtà, diventa più lento perché più server devono essere aggiornati in modo sincrono. Quindi, questa topologia ha i suoi usi, ecco perché la manteniamo. Molti dei nostri clienti lo utilizzano in situazioni speciali.
cache specchiata
La quarta topologia è denominata cache specchiata. Anche questa è una topologia molto specifica. È solo una topologia a 2 nodi. C'è un nodo Attivo e uno Passivo. Ancora una volta, il nodo attivo ha l'intera cache e una copia della cache si trova sul nodo passivo. Tutti i client si connettono al nodo attivo e aggiornano il nodo attivo per tutte le cose e gli aggiornamenti vengono sottoposti a mirroring o replicati in modo asincrono sul nodo passivo. E questo significa che è anche piuttosto veloce, proprio come Partition Replica.
In questa topologia, se il nodo attivo si interrompe, il nodo passivo diventa automaticamente attivo e tutti i client si spostano automaticamente sul nodo passivo o appena attivo. E in questo modo non ci sono tempi di inattività, non ci sono interruzioni e si chiama supporto automatico del failover, questo è ciò che intendevo con questo. E, ovviamente, quando il nodo attivo ritorna attivo, questo diventa di nuovo attivo, la stessa cosa accade al contrario.
Quindi, la Mirror Topology è molto utile anche per casi specializzati. Non è scalabile oltre questi due server ma ha un suo proprio utilizzo perché tutti i client si connettono qui e quindi puoi fare una replica su una macchina diversa. Voglio dire, questo potrebbe essere utilizzato ad esempio, in caso di situazione di ripristino di emergenza, ad esempio.
Persistenza viva
Un'altra caratteristica molto potente di NCache è chiamato Persistenza viva. La persistenza live è disponibile solo per le topologie di partizione e replica di partizione ed è live, il che significa che quando si aggiorna la cache in fase di runtime, anche l'archivio di persistenza viene aggiornato immediatamente. L'aggiornamento all'archivio permanente è asincrono. Pertanto, non interferisce con le prestazioni dell'applicazione o NCache prestazione. Quindi, è così che la tua richiesta può rimanere molto veloce. La persistenza viene eseguita a livello di bucket. Quindi, ci sono 100 bucket che rappresentano l'intera cache conservata in un file NoSQL archivio documenti. È un negozio basato su file, quindi non è un negozio basato su server. Non è un NoSQL database server, è un NoSQL memorizzalo nei documenti NCache usi. Puoi usarlo in una posizione comune a tutti i server in NCache cluster e in questo modo possono fare affidamento tutti sullo stesso archivio persistente.
Alcuni dei vantaggi di ciò sono, e il motivo per cui viene fornita questa funzionalità, il primo: qualunque cosa tu stia persistendo puoi, ad esempio, rendere persistente l'intera cache e l'intera cache sarà sempre persistente. Puoi dire che qualunque cosa tu stia aggiornando nella cache, con la differenza di pochi millisecondi, viene anche mantenuta nell'archivio persistente. Quindi, puoi prenderlo e ricaricarlo in una cache diversa, oppure se tutti i server dovessero non funzionare puoi sempre riavviarli dagli archivi persistenti. Non perdi alcun dato tranne una quantità molto piccola di dati. O forse vuoi portare la cache da un ambiente all'altro, puoi farlo facilmente.
L'altro vantaggio è che aggiunge effettivamente una maggiore disponibilità elevata alle topologie delle partizioni e delle repliche delle partizioni. Bene, la topologia delle partizioni, e ne parlerò qui. Quindi, Partitioned Cache, come ho detto prima, non ha alcuna replica, quindi, se una partizione o un server dovesse andare giù, perdi quella partizione, giusto? Bene, se hai perseveranza, allora non lo fai. Perché in questi bucket viene conservata anche una copia di tali dati. Quindi, se questo server dovesse esaurirsi, i bucket in memoria verranno riassegnati ma ovviamente senza dati ad altri server e ora quei server sanno che si tratta di bucket vuoti i cui dati esistono nell'archivio di persistenza, quindi ricaricheranno quei dati dalla persistenza negozio.
Quindi, è così che non perdi alcun dato anche se un server non funziona, anche se stai utilizzando Partitioned-Cache. Inoltre, hai gli stessi vantaggi di una replica della partizione e di Partitioned-Cache.
Il vantaggio che otterrai qui è che puoi utilizzare più memoria. Puoi archiviare più dati nella cache perché qui devi allocare più memoria per la replica che non devi allocare qui ma devi allocare l'archivio di persistenza. Quindi, questo è il vantaggio di Partitioned Cache. C'è anche un vantaggio in Partition-Replica. Ed è piuttosto interessante il fatto che, sebbene questo ti dia già un'elevata disponibilità, ma se l'elevata capacità si verifica solo se un server va giù in un qualsiasi momento ma, diciamo, se due server dovessero andare giù simultaneamente senza nemmeno la persistenza in Partition-Replica perderesti i dati. Perché, sai, c'è solo una copia di ogni partizione e se due server dovessero fallire, perderai più server di quanto puoi permetterti. Bene, con la persistenza non hai alcun problema, puoi semplicemente ricaricare tutti i dati dall'archivio di persistenza.
Ovviamente, in entrambi i casi, devi tenere presente che ogni volta che carichi dati dall'archivio di persistenza avevi tre server, ora ne hai due. Bene, i dati potrebbero valere troppo per essere inseriti nei due server, il che potrebbe essere un altro problema che devi affrontare è assicurarti di avere abbastanza memoria su questi due server rimanenti in modo che possa ospitare l'equivalente di tutti e tre server. Quindi, questa è l'unica limitazione. Altrimenti, la persistenza aggiunge davvero valore sia alla cache Partitioned che a quella Partition-Replica.
Cache cliente
Ok, un'altra caratteristica molto importante di NCache è chiamato Cache cliente. Ti offre una velocità InProc in un ambiente di negozio distribuito. Quindi, ad esempio, hai un distribuito NCache cluster, la tua applicazione è in esecuzione qui, di solito si tratta di una cache sopra il tuo database o qualsiasi altra cosa tu stia facendo, una cache client viene solitamente utilizzata quando hai uno scenario di cache distribuita e una cache client è una cache sopra questo cluster di cache e si trova molto vicino alla tua applicazione. Si trova sul server delle applicazioni o sul file NCache casella cliente. E può anche essere InProc o OutProc a seconda delle tue preferenze. Una cache InProc è superveloce perché mantiene effettivamente i dati sotto forma di oggetto deserializzato nell'heap. Quindi è come avere quell'oggetto nel tuo heap. Può diventare più veloce di così.
Quindi, una cache InProc è superveloce ma allo stesso tempo il bello è che è sincronizzata con il file NCache grappolo. Inoltre, il modo in cui è sincronizzato è ciò che è conservato nella cache del client, di cui il cluster è a conoscenza. Pertanto, se qualcosa che era conservato in questa cache del client viene aggiornato da un altro client nel cluster, il cluster notifica a quella cache del client di andare ad aggiornarsi. E poi la cache del client si aggiorna in modo asincrono. Ovviamente c'è un ritardo di qualche millisecondo ma, come ho detto, nella maggior parte dei casi il modello è la coerenza finale, e di solito è accettabile nel 99% dei casi.
Se questo non è accettabile allora NCache ti fornisce... e la sincronizzazione ottimistica è l'impostazione predefinita, ovvero quando c'è un ritardo di qualche millisecondo e tecnicamente potrebbe esserci una situazione in cui hai dati non aggiornati, il che va bene, come ho detto il 99% delle volte. Ma, diciamo, se non fosse ok e i tuoi dati fossero molto sensibili ma volessi comunque utilizzare la cache del client, potresti utilizzare una funzionalità di sincronizzazione pessimistica in cui si assicura che prima che l'applicazione recuperi qualsiasi cosa dalla cache del client, il client La cache controlla solo per vedere se esiste una versione più recente di quei dati, è una chiamata più veloce rispetto a ottenere i dati stessi perché, NCache quindi conserva più informazioni sulle versioni. E, se c'è una versione più recente di quei dati, la Client Cache la recupera, in caso contrario la restituisce semplicemente dalla Client Cache.
Una cache client che puoi utilizzare senza modifiche al codice. Si collega semplicemente al tuo ambiente ed è utile per situazioni ad alta intensità di lettura. Dove stai facendo molte più letture almeno 5:1, 10:1 è l'ideale ma quando c'è 1:1, diciamo, in caso di sessioni web, Client Cache in realtà non aiuta affatto. In realtà non è affatto consigliato.
Replica WAN
Multizona/Multiregione
Ok, un'altra parte di NCache è il dove NCache effettua Replica WAN per gestire la distribuzione multizona o multiregione delle tue applicazioni. Quindi, ad esempio, potresti distribuire la tua applicazione su due siti diversi per DR, per Disaster Recovery, uno è attivo l'altro passivo. E hai questa applicazione, un NCache in esecuzione con esso e qui hai un'applicazione che non è in esecuzione. Ma vuoi assicurarti che se questo sito dovesse mai crollare, sarà immediatamente in grado di riprendersi il carico. Quindi puoi mettere un ponte. Un bridge è esso stesso un cluster a 2 nodi che può trovarsi sugli stessi box del NCache main, o potrebbe essere dedicato separatamente, dipende da te. Quindi, qualunque cosa aggiorni in questa cache viene replicata in modo asincrono attraverso la WAN sull'altra cache. Quindi questo è attivo-passivo.
Puoi fare la stessa cosa con un attivo-attivo. Diciamo che se hai una situazione in cui anche questo sito è attivo, puoi fare la stessa identica cosa con un attivo-attivo in cui entrambi i siti possono aggiornarsi a vicenda. In tal caso, c'è anche una situazione in cui il conflitto potrebbe risolversi, potrebbe sorgere. E ciò che un conflitto significa è che lo stesso elemento, la stessa chiave viene aggiornata su entrambi i siti contemporaneamente. Se ciò accade, il bridge applica per impostazione predefinita la logica "l'ultimo aggiornamento vince". Quindi, qualunque abbia il timestamp successivo, l'aggiornamento vince. Ma, ad esempio, se lo desideri, potresti anche fornire una risoluzione dei conflitti e un gestore della risoluzione dei conflitti che è il tuo codice .NET o Java che il bridge chiamerà e passerà entrambe le copie dei dati o dell'oggetto a quel gestore della risoluzione e poi puoi analizzare il contenuto per determinare quale è più corretto, e poi dici, okay, questo aggiornamento vince e poi quell'aggiornamento viene applicato a entrambi i siti. Finché ciò viene applicato ad entrambe le parti, non vi è alcun conflitto.
I NCache ha la capacità di fornirti tre o più siti in modalità attivo-attivo, attivo-passivo o una combinazione di questi. Quindi, ad esempio, ne hai bisogno almeno uno attivo ma questi potrebbero essere tutti passivi o potrebbero essere tutti attivi o potrebbe essere una combinazione di attivo o passivo. E, ancora una volta, allo stesso modo, quando ce n'è più di uno attivo, questa potrebbe essere la risoluzione del conflitto.
Contenitori (Docker e Kubernetes)
Infine, i contenitori sono diventati molto popolari Docker e Kubernetes. COSÌ, NCache ovviamente li supporta perché sono più popolari sul lato Java e Linux di quanto non lo siano ancora sul lato .NET e Windows, ma sono sicuro che questo cambierà, sai, con il tempo. Quindi, in ogni caso, NCache è pienamente in grado di gestirlo in entrambi gli ambienti. Quindi, ad esempio, ecco un tipico Distribuzione di Kubernetes di NCache.
Ecco un file NCache distribuzione. C'è NCache ha ottenuto il proprio servizio di rilevamento. Questi sono pod che possono essere scalati e quindi ci sono applicazioni all'interno del cluster Kubernetes che lo sono NCache client e potrebbe essere Azure, AKS, AWS, EKS, Google GKE o Red Hat OpenShift. Red Hat OpenShift di solito è un altro cloud come AWS, Azure o Google o forse un altro cloud ma NCache li supporta tutti. E questo Pod potrebbe essere Linux, come è il caso più comune in Kubernetes, e NCache funziona perfettamente bene. Inoltre, l'applicazione può essere anche Linux o Windows. Quindi, potrebbero essere Linux o Windows, Linux o Windows.
Docker/Kubernetes (multizona)
Allo stesso modo in cui entra in gioco la replica WAN, se lo desideri, diciamo, a causa del cloud puoi avere più zone di disponibilità. Volevi realizzare un Kubernetes multizona.
Quindi, il modo in cui ti consigliamo di creare un cluster Kubernetes e di averne due NCache distribuzioni, queste potrebbero essere attive-attive o attive-passive. E poi il ponte può stare completamente qui, oppure completamente qui. Oppure puoi anche avere una divisione del bridge in cui una parte si trova su questa zona e l'altra su quell'altra zona e quindi la replica avviene in modo asincrono.
Penso che questo copra più o meno l'argomento di oggi. Ti consiglio vivamente di visitare il nostro sito Web e di dare un'occhiata NCache Parco giochi che è davvero un modo molto semplice e veloce dal tuo browser per utilizzare una copia live in esecuzione di NCachee puoi persino ottenere un 2-Node NCache Cluster con tutti gli strumenti senza alcuno sforzo di installazione. Oppure se sei pronto, vieni qui e registrati e scarica o NCache Enterprise per l'edizione .NET o NCache Enterprise per l'edizione Java. Come ho detto, puoi ottenere .tar.gz per Linux, .msi o anche Docker. Puoi semplicemente estrarre un'immagine Docker di NCache. Questa è la fine della mia presentazione. Grazie mille.