DSD 2017 Londra

Ridimensionamento di applicazioni .NET con cache distribuita

Di Iqbal Khan
Presidente ed evangelista tecnologico

Se stai aumentando il volume delle transazioni di dati, il volume della sessione o la dimensione degli oggetti, questo discorso è per te. Scopri come aumentare le prestazioni delle app utilizzando una cache distribuita tra le tue app e il tuo database. Questo discorso copre:

• Panoramica rapida dei colli di bottiglia della scalabilità nelle applicazioni .NET
• Descrizione della cache distribuita e di come risolve i problemi di prestazioni
• Dove puoi utilizzare la cache distribuita nelle tue applicazioni
• Alcune caratteristiche importanti in una cache distribuita
• Esempi pratici utilizzando una cache distribuita

Panoramica

Ciao a tutti, mi chiamo Iqbal Khan. Sono un evangelista tecnologico presso Alachisoft. Siamo i creatori di NCache. Quante persone hanno sentito parlare NCache prima? Buono, buon numero. L'argomento di oggi è il ridimensionamento delle applicazioni .NET con la memorizzazione nella cache distribuita. Non si tratta NCache, si tratta in generale del problema di scalabilità che devono affrontare le applicazioni .NET e di come risolverlo.

Preferisco una discussione più interattiva. Quindi, invece di aspettare fino alla fine per fare domande, per favore alza la mano se hai una domanda mentre sto parlando. Passerò attraverso una combinazione di codice architettonico e poi reale e te lo mostrerò anche NCache come esempio di come appare una cache.

Che cos'è la scalabilità?

Quindi, togliamo alcune definizioni di mezzo. Sono sicuro che molti di voi lo sanno già, ma cos'è la scalabilità? La scalabilità non è la prestazione dell'applicazione. Sono le prestazioni dell'applicazione con carichi di picco. Quindi, se hai un'applicazione che funziona in modo super veloce con 5 utenti, non è necessariamente scalabile a meno che non funzioni in modo super veloce con 5,000 o 50,000 o 500,000 utenti. Ovviamente se la tua applicazione non funziona velocemente con 5 utenti, hai altri problemi oltre alla scalabilità.

Scalabilità lineare e scalabilità non lineare

La scalabilità lineare è più un'architettura di distribuzione. La tua applicazione è progettata in modo tale da poter continuare ad aggiungere più server in un ambiente con bilanciamento del carico e quindi, aggiungendo più server, aumenti la capacità di transazione. A proposito, quando uso la parola scalabilità, intendo la scalabilità delle transazioni non i dati della scalabilità. Non stiamo parlando di enormi quantità di dati. Non stiamo parlando di terabyte o petabyte di dati. Parliamo di molta attività. Quindi, se la tua applicazione è progettata in modo da poter aggiungere più server e man mano che aggiungi più server la tua capacità aumenta in modo lineare, allora sei linearmente scalabile.

In caso contrario, allora hai più una curva logaritmica, per quelli di voi che ricordano ancora i loro calcoli al college e il problema con questa curva è che vedrai un aumento, ma dopo un certo punto l'aggiunta di più server in realtà non ha alcun vantaggio, in realtà riduce le prestazioni perché ci sono alcuni colli di bottiglia nell'applicazione che semplicemente non scompaiono. Quindi, sicuramente non vuoi essere non lineare.

Quali applicazioni necessitano di scalabilità?

Quindi, quali applicazioni necessitano di scalabilità? Di solito si tratta di applicazioni server ovviamente. Applicazioni Web, ASP.NET, ora ASP.NET Core anche. Servizi web. Ancora una volta puoi farlo tramite WCF. Potresti farlo API Web ASP.NET o ASP.NET Core API web. E, cioè, i servizi web sono solitamente il back-end per Internet of Things, che è uno spazio emergente piuttosto veloce in questi giorni.

Queste sono anche grandi applicazioni di elaborazione dati. Quindi, se hai molti dati, ecco dove arriva la parte dei dati della scalabilità, ma anche lì non si tratta di dati, ma di quanto velocemente puoi elaborarli. Quindi, se si dispone di una grande applicazione di elaborazione dati, è necessario ridimensionarla. La maggior parte delle applicazioni di elaborazione di big data generalmente non sono in .NET. Sono più sul lato Java e il mio focus è più sull'applicazione .NET. Ma, concettualmente parlando, anche le applicazioni di elaborazione dei big data sono qualcosa che necessita di scalabilità.

E, infine, qualsiasi altra applicazione server. Potresti essere un istituto finanziario, potresti essere una grande banca, avere milioni di clienti, loro chiamano, cambiano indirizzo, emettono una nuova carta o qualsiasi altra cosa e devi elaborare, forse vogliono trasferire fondi e devi elaborare tutte quelle richieste entro un determinato periodo di tempo ai fini della conformità. Quindi, hai molti di questi processi batch di back-end in corso e devono elaborare sempre più transazioni in quel brevissimo lasso di tempo, piccolo in termini di poche ore che ottieni ogni notte. Quindi, qualsiasi applicazione server. Quindi, se disponi di una di queste applicazioni e hanno bisogno di scalabilità, oggi sei nel posto giusto.

Il problema della scalabilità

Allora, qual è il problema della scalabilità? Bene, il livello dell'applicazione non è il problema. Nella maggior parte di queste applicazioni che ho menzionato, il livello dell'applicazione sembra funzionare perfettamente. Puoi aggiungere più server. Di solito hai un ambiente con carico bilanciato. Se hai un'applicazione diciamo ASP.NET, avrai un sistema di bilanciamento del carico in alto e avrai un gruppo di server a cui il sistema di bilanciamento del carico invia il traffico e poiché hai bisogno di più traffico, poiché devi gestire più utenti aggiungi solo più server. Quindi, è molto semplice.

Ma il problema è che il tuo database è se si tratta di dati relazionali o mainframe, diventano il collo di bottiglia. E, relazionale non significa un database specifico. Potrebbe essere un server SQL, potrebbe essere Oracle, MySQL, Db2, uno qualsiasi di questi. Tutti i database relazionali hanno questa debolezza intrinseca che non possono scalare. Quindi, questo è esattamente il motivo NoSQL il movimento è iniziato e infatti abbiamo anche un prodotto sullo spazio .NET chiamato NosDB che è un open source NoSQL database ma il NoSQL databases non sono sempre la risposta. Voglio dire, risolvono definitivamente il problema della scalabilità. Tecnicamente parlando se usi a NoSQL database non avrai colli di bottiglia di scalabilità. Ma il problema è che per una combinazione di ragioni tecniche e aziendali non puoi spostare tutti i tuoi dati al di fuori del mainframe relazionale o legacy in NoSQL.

Così, la NoSQL è più di alcuni di quelli che chiamiamo i nuovi dati, sai. I dati aziendali tradizionali risiedono ancora nei database relazionali per una serie di motivi. Quindi, ciò significa che devi risolvere questo problema mentre vivi con database relazionali. Non si può dire che rimuoverò semplicemente il database relazionale dalla mia immagine. Infatti anche nessuno dei nostri clienti si trasferisce completamente in a NoSQL. Spostano alcuni dei dati in NoSQL. Giocatori ancora più grandi come MongoDB, hanno la stessa storia delle persone in cui si trasferiscono NoSQL database spostare alcuni dei dati in NoSQL e conservano ancora i dati tradizionali nel database relazionale.

Distribuzione cache distribuita (NCache)

Quindi, è necessario risolvere il problema con i database relazionali nell'immagine ed è qui che a cache distribuita entra. In realtà ti dà spesso lo stesso vantaggio NoSQL database. In realtà è, se ci pensi, è un NoSQL archivio valori chiave in memoria. Quindi, sai, se hai esaminato NoSQL databases, c'è il database dei documenti JSON, c'è l'archivio dei valori chiave e c'è il database dei grafici e ci sono gli altri tipi. Quindi, l'archivio dei valori chiave, se è un ... L'unica cosa che una cache distribuisce è che non fa persistenza, è tutto in memoria. È il negozio di valori chiave. Inoltre, è distribuito su più server, quindi ti offre lo stesso vantaggio, è scalabile perché puoi aggiungere più server. Quindi, pensa a questo come al livello dell'applicazione qui sopra. Proprio qui c'è il livello dell'applicazione e quindi di solito un bilanciamento del carico qui da qualche parte. E, man mano che si aggiungono più server in questo livello, il database sarà sempre più sotto stress a meno che non si metta un livello di memorizzazione nella cache nel mezzo.

Il livello di memorizzazione nella cache viene ridimensionato proprio come il livello dell'applicazione. Non ha colli di bottiglia, perché continui ad aggiungere sempre più scatole. I dati sono distribuiti su più server. Questi sono server a basso costo tra l'altro. Questi non sono server di tipo database di fascia alta. Infatti i nostri clienti... La configurazione tipica è di circa 16 giga di RAM, circa 8 core box, come un tipico web server box ma solo più memoria. 16 giga, da 16 a 32 giga, non consigliamo nemmeno di andare più di 32. In effetti 64 giga è praticamente il massimo che consiglieremo ai nostri clienti. Diciamo, aggiungi più server. Perché? Perché, se aumenti troppo la memoria, .NET ha questa cosa chiamata garbage collection. Inoltre, la raccolta dei rifiuti richiede molta potenza di elaborazione. Quindi, più memoria hai, più garbage collection deve fare e più veloce deve diventare la tua CPU e quindi la tua cache non sta diventando sempre più simile a un database e sta diventando più costosa e tutto il resto. Quindi, è meglio avere più server che avere alcuni server di fascia alta.

Quindi, una cache distribuita forma essenzialmente un cluster di server. Questo è in genere un cluster basato su TCP e quel cluster significa che ogni server nel cluster conosce l'uno dell'altro e raggruppa le risorse insieme in un'unica capacità logica. Avere il cluster significa che quando è necessario aumentare la capacità, è sufficiente aggiungere un altro server al cluster. Oppure, quando è necessario ridurre la capacità, si elimina un server. E, quando hai questo livello di memorizzazione nella cache, è un archivio in memoria perché non è necessario persistere i dati. Non è un negozio permanente. L'archivio permanente è ancora il database e, poiché è un archivio in memoria, deve fornire anche la replica dei dati.

L'obiettivo in tutta questa immagine è essenzialmente quello di andare nella cache circa l'80% delle volte. Quindi, se potessi solo immaginare, se andassi alla cache l'80% delle volte il tuo database sarebbe totalmente privo di stress, lo sai. Potresti davvero aumentare un po' la scalabilità.

Domanda: l'applicazione non deve ancora parlare troppo con il database?

Non è così, in realtà. Quindi, dipende dai dati. Tuttavia, la maggior parte dei dati delle applicazioni rientra nella categoria dei dati di riferimento o dei dati transazionali che non cambiano ogni pochi secondi. Cambia forse ogni pochi minuti. Quindi, per tutti questi dati, esegui molte più letture di quelle che scrivi. Quindi, la prima lettura va al database e anche a quelle funzionalità simili NCache ha una funzione in cui puoi precaricare la cache con i dati. Quindi, puoi riscaldare la cache con tutti i dati che pensi di avere e quindi anche quel traffico non viene colpito, il database non viene colpito. Ma dipende dai dati. Ad esempio, se hai un altro tipo di dati, diciamo, se dovessi archiviare sessioni al suo interno, per ogni lettura ce n'è una scrittura. Quindi, dipende e esaminerò quei dettagli, ma questa è una buona domanda.

Bene, il motivo per cui non lo saresti, perché la cache carica i dati e li mantiene nella cache. Quindi, il traffico tra la cache e il database è molto raro. Ancora una volta, come ho detto, l'80% delle volte le letture vengono eseguite e la cache contiene i dati. Quindi, quando lo metti nella cache lo stai memorizzando nella cache per un certo periodo di tempo e per quella durata la cache non va al database ogni volta. Ma l'applicazione arriva ogni volta nella cache. Quindi, anche se hai molto traffico, tutto arriva nella cache e improvvisamente il database è molto leggero.

In realtà, c'è il partizionamento per ogni scatola che memorizza dati diversi e c'è anche una certa ridondanza integrata per l'affidabilità, ma lo approfondirò in modo più dettagliato.

Quindi, questa immagine (Fig-1) ha lo scopo di convincerti che nell'ambiente odierno ad alta scalabilità la cache distribuita è una specie di best practice de facto. Quindi, se progetti la tua applicazione, tieni a mente una cache. Non importa quale cache. Questa è una discussione a parte. La prima discussione è che è necessario progettare l'applicazione in modo da passare a una cache distribuita. Se lo fai e puoi essere sicuro che quando l'azienda ha bisogno della tua applicazione per funzionare, l'applicazione non si strozzerà.

E, se non lo pianifichi in anticipo, il vero svantaggio di non essere in grado di scalare è che questo problema si verifica quando l'azienda sta andando davvero bene. Immagina se sei una compagnia aerea e hai appena lanciato la promozione di questo fine settimana in un luogo di vacanza e milioni di nuovi utenti stanno visitando un sito Web per cercare voli e magari acquistare biglietti. Se le prestazioni del tuo sito web hanno iniziato a rallentare ogni clic è stato di un minuto, perdi clienti. E se va anche peggio e la tua applicazione inizia a bloccarsi perché il database si è appena bloccato, perdi molti affari. Quindi, è necessario pianificare in anticipo. Anche se oggi non stai affrontando quel problema e, ancora una volta, non si tratta di prestazioni.

Molte persone pensano di usare la cache perché migliorerà le prestazioni. Migliora le prestazioni, ma al giorno d'oggi i database sono piuttosto veloci. Se hai solo quei cinque utenti. Non ho sentito nessuno lamentarsi della lentezza del database. Quindi, il problema non sono le prestazioni. Il problema è la scalabilità, perché c'è un solo server di database ed è possibile aggiungere più server nel livello dell'applicazione e quindi improvvisamente il database diventa un collo di bottiglia.

Domanda: dovremmo usare macchine virtuali o box fisici per i cluster di cache?

Ottima domanda. Stavo per parlarne e me ne sono dimenticato ed è un bene che tu lo chieda. Quindi, queste potrebbero essere scatole fisiche. Abbiamo ancora clienti che hanno box fisici, ma sempre più clienti si stanno spostando verso le VM e ora la nuova tendenza sono i container. Quindi, come minimo avrai VM. Quindi, ogni server cache è una VM. Quindi, hai un minimo di due VM del server cache. Come ho detto da 16 a 32 giga ciascuno. Ovviamente non vuoi avere entrambi i VMS sulla stessa scatola fisica. Perché, in tal caso, perdi quel vantaggio di alta disponibilità. Perché, se quella scatola si arresta in modo anomalo, entrambi i VMS sono spariti.

Un'altra domanda. Quindi, i dati fisici sono archiviati in memoria?

In memoria. Esatto, esatto. È tutto spazio di archiviazione in memoria. E, poiché è un negozio temporaneo, lo conservi per pochi minuti, poche ore, pochi giorni, poche settimane, sai, non lo conservi in ​​modo permanente. L'archivio permanente è ancora la banca dati. Qualunque cosa sia. Potrebbe essere, come ho detto, potrebbe essere un mainframe legacy, potrebbe essere relazionale, potrebbe essere NoSQL.

Anche con NoSQL database, dovresti usare una cache distribuita. Perché NoSQL non è veloce come una cache distribuita e perché abbiamo entrambi i prodotti che conosciamo. Facciamo i benchmark. È ancora 10 volte più veloce.

Non ho familiarità con NoSQL database, quindi mi chiedevo solo perché funziona meglio di un database relazionale?

È più scalabile perché si distribuisce anche su più server. Quindi, proprio come una cache distribuita può avere 5, 10, 15, 20 server, puoi fare lo stesso con un NoSQL database. Non puoi avere 20 server per SQL. Puoi averne forse 2, per attivo-passivo o attivo-attivo, ma questo è tutto. Sai, non puoi davvero scalare. Quindi, è per motivi di scalabilità.

Quindi, sono le macchine virtuali o ora i container stanno diventando sempre più popolari per la gestione e questo potrebbe essere in locale o potrebbe essere nel cloud, in qualsiasi ambiente.

Usi comuni della cache distribuita

Quindi, spero che questa immagine (Figura-1) vi convinca che dovete usare la memorizzazione nella cache. Quindi, ora sei convinto, diciamo. La prossima domanda che viene è, bene come lo uso? Dove lo uso, sai? Quindi, ci sono tre luoghi comuni in cui usi la memorizzazione nella cache.

Memorizzazione nella cache dei dati dell'app

Il numero uno è quello di cui ho parlato fino ad ora, che sono i dati dell'applicazione, che era questa immagine esatta. I dati vengono memorizzati nella cache qui, in modo da non dover accedere al database. L'unica cosa da tenere a mente memorizzazione nella cache dei dati dell'applicazione è che ora i dati esistono in due posti. Uno è la cache, uno è il database. Quando i dati esistono in due posti, cosa potrebbe essere sbagliato? Sincronizzazione. Quindi, questo è un grosso problema che la maggior parte delle persone ha paura di usare la cache, per qualcosa di diverso dai dati di sola lettura. Se chiedi a una persona media, hai pensato di usare la cache o stai facendo una memorizzazione nella cache? Le persone a volte costruiranno queste tabelle hash o alcune in un archivio di memoria, inseriranno solo dati di sola lettura. Dati che non cambiano mai nella totalità dell'applicazione o in tempi davvero molto comodi. Bene, i dati di sola lettura o i dati di riferimento sono solo il 10-15% dei dati totali. Quindi, ti dà sicuramente molti vantaggi, ma il vero vantaggio è se puoi memorizzare nella cache tutti i dati. Ciò significa che devi davvero essere in grado di gestire...

Una buona cache distribuita deve gestire la sincronizzazione. Quindi, deve garantire che la cache sia sempre aggiornata. Quindi, hai quella fiducia nella cache che qualunque cosa tu stia leggendo dalla cache è l'ultima copia di quei dati.

E, se non hai la certezza che sarai limitato ai dati di sola lettura che praticamente riducono al minimo o riducono il valore della cache.

Memorizzazione nella cache specifica di ASP.NET

Quindi, il secondo vantaggio è il Cache specifiche di ASP.NET. Non entrerò in ASP.NET Core in questo momento, ma lo toccherò brevemente. Ma, cache ASP.NET, ci sono tre posti in cui lo fai e almeno due ora. Se hai il framework MVC, non hai lo stato di visualizzazione ma le sessioni di ogni applicazione ASP.NET hanno sessioni e le sessioni devono essere archiviate da qualche parte. Per impostazione predefinita, vengono archiviati in memoria, ovvero In-Proc, all'interno del processo di lavoro dell'applicazione ASP.NET o del server SQL. Il server di stato non è disponibile nel cloud, è solo in loco e tutti quelli hanno problemi. Alcuni hanno problemi di scalabilità. In realtà, tutti hanno problemi di scalabilità. Alcuni hanno anche problemi di prestazioni. Come il database SQL ha anche problemi di prestazioni.

Quindi, un ottimo caso d'uso per la cache distribuita è semplicemente mettere quelle sessioni nella cache. Sai, quelle sessioni vengono archiviate ... se le memorizzi in SQL vengono archiviate come BLOB. Inoltre, i database relazionali non sono progettati per l'archiviazione BLOB. Ma, NoSQL o archivi di valori chiave, il valore è il BLOB. Quindi, si adatta davvero molto bene in una cache distribuita. Ovviamente devi anche risolvere... sempre più persone utilizzano più database o più data center per il ripristino di emergenza o per il bilanciamento del carico, il bilanciamento del carico geografico. Quindi, devi risolvere anche questo problema.

Uno stato di visualizzazione è qualcosa che non è più in ASP.NET ma se sei precedente, penso che ASP.NET 5. Se sei su ASP.NET 4, visualizza lo stato o pre MVC, lo stato di visualizzazione esisteva. Esiste ancora nella maggior parte delle applicazioni ASP.NET che sono state sviluppate in tutto quel tempo.

Per quelli di voi che non sanno cos'è uno stato di visualizzazione, uno stato di visualizzazione è una stringa crittografata che viene inviata dal server Web al browser, solo per tornare quando si verifica un post. Quindi, questa stringa potrebbe essere di centinaia di kilobyte e viaggia verso il browser viene archiviata nel browser e quindi torna indietro. Moltiplicalo per milioni di transazioni che la tua applicazione deve elaborare e ha due problemi, uno consuma molta larghezza di banda che non è una larghezza di banda economica, devi pagare per la larghezza di banda. In secondo luogo, rallenta il tempo di risposta perché è un carico utile pesante che sta viaggiando. Quindi, è un caso ideale per memorizzarlo nella cache sul server e inviare semplicemente una piccola chiave e quando torna la prossima volta, lo stato di visualizzazione viene recuperato dalla cache e pubblicato sulla pagina. Ancora una volta, lo stato di visualizzazione è solo una questione se non si utilizza il framework MVC e sicuramente non è nemmeno presente in ASP.NET Core perché ASP.NET Core è MVC.

Anche la cache di output di ASP.NET è qualcosa che fa parte dell'ASP.NET framework, non nell'ASP.NET Core dove praticamente memorizza nella cache gli output della pagina. Quindi, se la tua pagina non cambia alla richiesta successiva, perché eseguirla di nuovo? Quindi, ASP.NET memorizza nella cache la pagina, quindi la prossima volta che la richiesta arriva con gli stessi parametri, stesso tutto, verrà servito alla pagina un output dell'ultima esecuzione.

Quindi, quel framework è già lì ed è davvero una buona cosa usare una cache distribuita per esso, in modo che, in un ambiente multi-server, una volta memorizzato nella cache, sia immediatamente disponibile per tutti i server. ASP.NET Core ha solo sessioni per la memorizzazione nella cache e non c'è stato di visualizzazione e non c'è cache di output. Ma c'è un'altra cosa chiamata cache di risposta. Quindi, ASP.NET Core si è in qualche modo standardizzato ora con le applicazioni Web complessive in cui la memorizzazione nella cache dei contenuti avviene al di fuori del server. Quindi, questo è anche un buon candidato per la memorizzazione nella cache. Quindi, ASP.NET Core ha questo un concetto di middleware di cache di risposta. Quindi, c'è un middleware integrato che puoi usare e quindi puoi creare un middleware di terze parti. Piace NCache ne fornirà uno abbastanza presto.

Quindi, comunque, per la memorizzazione nella cache di ASP.NET e questa è una cosa importante da tenere a mente ora è che non stai più archiviando questi dati nella cache. Quindi, a differenza dei dati dell'applicazione in cui i dati esistono in due posti, ora i dati esistono solo in un posto e questa è la cache ed è una cache in memoria. Quindi, quando il negozio in memoria è il tuo unico negozio, cosa potrebbe andare storto? Sì. Voglio dire, se quella scatola va giù sei lavato. Perché la memoria è volatile. Non è persistente. Quindi, il modo per gestirlo ovviamente è eseguire la replica. Per avere quei dati su più di un server. Ma, ancora una volta, due problemi molto diversi da risolvere. Una buona cache distribuita deve eseguire una replica intelligente. Ad esempio, per archiviare in modo sicuro le sessioni ASP.NET. Altrimenti cosa accadrà? Torniamo a questo, sai, compagnia aerea. Sono appena andato su quel sito web. Comprerò biglietti per un valore di 5,000 dollari. Ho fatto tutte le mie ricerche di voli, tutti i tipi di combinazioni e sto per... Ho inserito i miei dati di pagamento e sto per inviare e, all'improvviso sono tornato alla, sai, la pagina di avvio, qualunque cosa, perché la mia sessione è perso. Perché quando ho premuto invia è andato al server web, quel server web non era lì, si è bloccato e la sessione era scomparsa. Quindi, sicuramente non è una bella foto.

Condivisione dei dati di runtime tramite eventi

Il terzo caso d'uso è a condivisione dei dati di runtime attraverso gli eventi. Questo è qualcosa che molte persone non sanno che sta diventando sempre più popolare di una cache distribuita una volta che l'hai nel tuo ambiente, è una piattaforma davvero potente per la condivisione dei dati tra più applicazioni attraverso come un Pub / Sub modello o altra condivisione di dati basata su eventi.

Ad esempio, potresti avere più applicazioni che devono condividere i dati. Un'applicazione produce qualcosa, lo mette nella cache, attiva alcuni eventi, ci sono abbonati a quell'evento. Quindi, ci sono altre istanze dell'applicazione o altre applicazioni, molte volte si verifica una sorta di flusso di lavoro nelle applicazioni. Che qualcosa viene prima fatto e poi in base a quel qualcos'altro viene fatto. E, in tal caso, ci sono questi abbonati a quegli eventi. Tali domande saranno notificate.

Pensa ora a questa immagine (Figure 1 ) qui. Non vederlo come una cache tra l'applicazione e il database. Pensalo come un bus di messaggi e queste applicazioni sono tutte collegate al bus di messaggi. Un'applicazione di questo server inserisce i dati nella cache, attiva un evento. Altre applicazioni forse su alcuni di questi server vengono notificate e andranno immediatamente a consumare i dati. Modo molto potente.

Alcune persone usano le code di messaggi. Per molti di questi messaggi le code hanno uno scopo preciso. Una cache distribuita non è qui per sostituirli completamente, ma un sottoinsieme dei casi. Quando tutta la condivisione dei dati è all'interno dello stesso data center, non è un ambiente molto distribuito ed è un ambiente ad alto traffico. Una coda di messaggi non è scalabile, a differenza di una cache distribuita. Perché una coda di messaggi non ha un cluster come questo. Non puoi davvero aggiungere altro. Quindi, se hai avuto milioni di transazioni in corso e parte di queste erano anche informazioni sui messaggi, le code di messaggi non possono gestire quel carico, ma una cache può farlo.

Quindi, una condivisione dei dati di runtime è un modo davvero potente e lo toccherò. Anche in questo caso, nella condivisione dei dati di runtime, i dati esistono solitamente solo nella cache. Tuttavia, potrebbe esistere una forma diversa nel database. Perché è stato letto dal database, trasformato in un'altra forma e quindi inserito nella cache per la condivisione.

Quindi, alcune delle funzionalità sono comuni a tutte le cache. Alcuni sono solo NCache sul lato .NET ma tutto ciò che è NCache sul lato .NET non è una funzionalità proprietaria .NET. Perché vedi le stesse funzionalità sul lato Java e tutte le cache Java. Quindi, Java è un mercato molto più avanzato o molto più maturo perché Java è stata la tecnologia lato server per più tempo di .NET. Quindi, vedi che... Sul lato Java. Sul lato .NET lo vedrai in alcune cache, non in tutte. Per esempio, AppFabric, penso di non averlo. Redis ne ha parte non tutto. NCache ha un pieno come le cache Java.

Quindi, questi sono i tre casi d'uso. Qualche domanda su questo, prima di approfondire ciascuno di essi?

Demo pratica

Prima di entrare in uno di questi, lascia che ti mostri prima che aspetto ha una cache? Ovviamente lo userò NCache come l'esempio, ma lo scopo è darti un'idea di come appare veramente una cache. Ad esempio, ho tre macchine virtuali in Azure. Loro stanno correndo. Demo1 e demo2 sono le mie VM del server cache. Quindi, avrò un cluster di cache a 2 nodi.

Il client demo è il mio server delle applicazioni. Quindi è una VM client cache.

Crea una cache raggruppata

Ho effettuato l'accesso alla VM del client demo qui. Andrò avanti e creerò una cache in cluster. In caso di NCache, userò questo strumento chiamato NCache direttore, che è uno strumento grafico. Verrò qui e dirò, prima assicurati che la cache non esista già. Va bene, non è così, va bene, verrò qui e dirò di creare una nuova cache in cluster.

In caso di NCache tutte le cache sono nominate. Quindi, la mia cache viene chiamata demoCache. Lascerò semplicemente tutto il valore predefinito. Non entrerò nei dettagli di questo. Mi limiterò a mantenere... Parlerò solo di quelle parti che sono importanti.

La prima cosa che sceglierai è ciò che chiamiamo a topologia di memorizzazione nella cache NCache ed è qui che uno di voi ha posto la domanda sul partizionamento. I dati sono realmente distribuiti o esistono gli stessi dati in ogni server. Quindi, la replica della partizione è una topologia che NCache ti dà.

Ad esempio, salterò rapidamente questo e parlerò rapidamente di quale topologia è? Quindi, una topologia di replica di partizione... Quindi, questa è una topologia partizionata, questa è una replica di partizione.

In un partizionamento ogni server ha l'1ennesimo dei dati. Quindi, se hai, diciamo, in caso di NCache, quando crei una cache in cluster, vengono creati mille bucket. Quindi, se hai un cluster di due server, ogni server 500. Se ne hai tre, ogni server è un terzo di mille.

Quindi, quei bucket sono essenzialmente proprio come i bucket di una tabella hash. A ogni bucket viene assegnato un intervallo di valori chiave. Quindi, c'è una funzione di mappatura hash che trasforma le tue chiavi in ​​valori hash e cadranno in qualsiasi bucket in cui dovrebbero cadere in base alle chiavi. Quindi, una replica partizionata ha una partizione su ogni server. Diciamo, se dovessi venire qui. Diciamo che ecco un cluster di tre server, quindi le tre partizioni e ogni partizione ha un backup o una replica su un server diverso.

In caso di NCache la replica non è attiva. È passivo. Quindi, solo la partizione comunica con le repliche. L'applicazione comunica con le partizioni. Quindi, diciamo che ogni client cache, ogni server delle applicazioni si connette a tutti i server cache. Si connette e ottiene tutte le informazioni sull'appartenenza al cluster. La mappa di distribuzione è quella mappa del secchio. Quindi, ottiene la mappa del secchio che gli dice dove si trova ciascun secchio? Sulla base di ciò sa, ok, se devo aggiungere l'elemento numero tre, devo andare al server 2. Perché è lì che risiede la partizione 2, che dovrebbe avere la chiave per l'elemento numero 3. Quindi, va direttamente a quel server e può farlo.

E, quindi, se un server si interrompe, diciamo che la partizione 3 si interrompe, quindi la replica 3 diventerà immediatamente attiva. Quindi, ora diventerà una partizione. Si trasformerà da replica in partizione. Perché, non lo sai, vuoi continuare. La cache deve essere eseguita, l'applicazione deve continuare. È alta disponibilità, giusto. Quindi, e poi questa partizione tre si rende conto che ci sono solo due server, quindi deve fondersi in queste due partizioni e in qualche modo andare via, svanire. Quindi, si fonde nelle altre due partizioni e quindi, una volta terminato, viene creata qui una replica per la partizione due.

Quindi, ancora una volta, solo per darti una panoramica del significato di quella topologia ed è così che avviene la distribuzione per garantire che quando aggiungi più server, hai sempre più spazio di archiviazione e questo è anche il modo in cui avviene la replica in modo che tutti i dati esistano in due server . Quindi, non c'è perdita di dati se un server si interrompe.

Ancora una volta, la teoria dell'elevata disponibilità afferma che due server non si disattivano contemporaneamente. Le possibilità che due server si interrompano contemporaneamente sono astronomicamente basse rispetto a qualsiasi server che si disattiva. Ovviamente, come ho detto, se due server sono sullo stesso alimentatore, quell'alimentatore si interrompe, quindi presumo che tutto sia ridondante. Allora due cose non mancheranno allo stesso tempo. Quindi, ecco perché avere solo due copie è più che sufficiente.

Torniamo indietro. Quindi, quella era la replica della partizione. Quindi sceglierò una replica asincrona.

Quindi, ci sono due modalità. La maggior parte delle cache distribuite esegue questa cosa chiamata consistenza finale. Il che significa che a causa della distribuzione, se dovessi effettuare la sincronizzazione immediata, tutto rallenterà. Ma la maggior parte dei dati che puoi permetterti, li metti in coda e hai aggiornamenti asincroni. Quindi, l'asincrono è ciò che verrà preso come predefinito qui.

Sceglierò il client demo o la demo 1 è il primo server. Scelgo la demo 2 come secondo server.

Verrò qui, prenderò solo le impostazioni predefinite.

Specificherò quanta memoria dovrebbe utilizzare ogni server.

Ovviamente nel tuo caso sarà molto di più. Quindi, diciamo, se hai 16 gig di memoria in ogni scatola devi allocarne parte per la partizione e parte per la replica. Quindi, diciamo, dovrebbero essere lasciati da 2 a 3 giga per il sistema operativo e altri processi e circa 13 giga sono rimasti. Quindi, da 7.5 o 6.5 giga, uno per la partizione uno per la replica. E poiché specifichi quella dimensione per assicurarti che la cache non consumi più di questo. Poiché è un archivio in memoria, la memoria è sempre limitata e su quella scatola potrebbero essere in esecuzione altre applicazioni. Quindi, vuoi in qualche modo limitare la quantità di memoria che la cache dovrebbe utilizzare e una volta che la cache ha utilizzato quella memoria ...

Quindi, allora la pagina successiva sarebbe. Diciamo che hai esaurito tutta quella memoria. Quindi, ora la cache è piena. Quindi, possono succedere solo due cose. Uno, elimina alcuni dei dati più vecchi o altro, oppure rifiuta i nuovi inserti. Quindi, devi scegliere quei due. Ovviamente vuoi fare la tua pianificazione della capacità, dove i dati che sono, se i dati dell'applicazione, possono essere eliminati perché puoi sempre ricaricarli dal database. Non va bene sfrattare le sessioni. Quindi, vuoi pianificare la tua capacità in modo che queste sessioni non vengano mai sfrattate. Ora hai abbastanza memoria, abbastanza RAM e abbastanza server per avere sempre memoria per le sessioni. E vuoi far scadere le sessioni, non eliminare il tema. Sfratto significa che le sessioni non erano ancora scadute ma non c'è più memoria, quindi stai per sfrattare con la forza. Scadenza in caso di NCache significa che hai specificato che una sessione va bene solo per, diciamo, 20 minuti di inattività. Successivamente, la sessione deve essere ripulita. Quindi, questa è la scadenza. Quindi, la scadenza è OK, non ci sono problemi ma lo sfratto è qualcosa che non dovresti fare alla sessione, va bene farlo ai dati dell'applicazione.

Quindi, cosa fare in caso di NCache, crei una cache per le sessioni e crei una cache per i dati dell'applicazione. Quindi, è così che separi i due. Quindi, diciamo che ho appena creato questa cache. Quindi, è una cache a due nodi. Andrò avanti e aggiungerò un nodo client che è la mia casella il client demo e ora avvierò semplicemente la cache.

Simula lo stress e monitora le statistiche della cache

Quindi, come puoi vedere, è piuttosto semplice. È una sorta di interfaccia in stile Explorer. Da un posto puoi andare avanti e creare cache multi-server, gestirla, monitorarla e poi una volta che hai fatto quello che succede è, diciamo, ora che lo ha fatto vedrò alcuni contatori PerfMon e lo farò esegui questo strumento chiamato strumento di stress test che viene fornito con NCache, che ti consente di simulare molto rapidamente l'utilizzo dell'applicazione.

Quindi, diciamo che l'ho appena fatto e ora sta iniziando a... Quindi, sta facendo da 500 a 800 transazioni per server. Quindi, è circa volte 2, questo è il carico. Voglio aumentare il carico. Quindi, voglio aggiungere un altro strumento per lo stress test. I nostri clienti lo usano abbastanza perché quasi tutti vogliono vedere come si comporta la cache nel loro ambiente. Sai, abbiamo tutti i benchmark pubblicati e tutto, ma vogliono vederlo nel loro ambiente. Quindi, invece di programmare e applicare l'applicazione per farlo, questo può simulare molto rapidamente. Quindi, diciamo, ne ho eseguiti due e ora il carico è aumentato. Quindi, posso continuare ad aggiungerne sempre di più fino a quando non esaurisco questi due server. Quindi, ecco dove arriva la scalabilità.

Questi due server stanno funzionando molto velocemente in questo momento. Ma, aumentando il carico, dopo un certo punto si esauriranno, che è ciò che accade a un database. L'unica differenza è che puoi venire qui e aggiungere un altro nodo. Quindi, se avevi una terza VM, vieni qui e aggiungila qui e non appena lo fai, all'improvviso il carico verrà distribuito e, abbiamo quell'immagine in cui, sai, dove ti ho mostrato dove hai iniziato i due server e ora questi due sono stati esauriti, vuoi aggiungerne un terzo. Quindi, ottieni un'altra VM e la aggiungi e ora diventa un tre server e NCache riaggiusterà automaticamente tutto, ripartizioniamo o redisomaggio la mappa del secchio. Quindi, c'è un terzo server aggiunto in fase di esecuzione. Quindi, all'improvviso non hai quel problema di capacità.

Sì, quindi, quello che fai è installare il file NCache software server, su tutte queste macchine virtuali. In caso di cloud di solito hai un'immagine VM preconfigurata su cui crei le istanze e quindi avvii semplicemente una nuova VM, ha NCache software in esecuzione e lo si aggiunge a questo cluster.

Ma, ancora una volta, il punto principale è che, a differenza di un database in cui una volta raggiunto quello stato di massimo, sei incasinato, lo sai. Cosa fai? Sai, ok, voglio comprarne uno più costoso. Bene, allora devi andare a comprare un'altra scatola e portare giù questa scatola ed è un incubo. Qui aggiungi solo un'altra casella.

utilizzando NCache con sessioni ASP.NET

Quindi, ora vado a quello successivo. Quindi, ora che sappiamo come appare una cache. Quindi, ora lo vediamo... in caso di NCache, tutte le cache sono nominate. Quindi, finché conosci il nome della cache, ti connetti semplicemente alla cache. Quindi, come ti connetti alla cache per le sessioni? Questo è il più facile. Ancora una volta, la maggior parte dei nostri clienti, la prima cosa con cui fanno NCache lo usano per le sessioni. Come mai? Perché non è necessaria alcuna programmazione. L'unica cosa che devi assicurarti in caso di sessioni è che tutti gli oggetti che stai inserendo nella sessione siano tutti serializzabili. Se stai già archiviando la sessione in SQL, lo hai già assicurato. Se stai archiviando sessioni in modalità In-Proc, potresti non averlo assicurato. Quindi, sai, questo è l'unico test che devi fare. Ma dopo è abbastanza semplice.

Vi mostro solo un piccolo campione qui. Quindi, ad esempio, qui c'è un esempio chiamato esempio del provider del negozio di sessione. Quindi, ho un'applicazione ASP.NET. Andrò su web.config. Supponiamo che io sia su questa casella del server delle applicazioni, lo sai. Se vedi quella foto qui. In effetti, fammi tornare qui. Quindi, ecco il server cache giusto ma la mia applicazione è in esecuzione su questa scatola. Quindi, su questa scatola, ho creato due cluster di server e ho aggiunto un client a questo, giusto. Quindi, ora quello che è successo su quel cliente è che in caso di NCache, oops no non qui. Va bene, in caso di NCache in realtà crea nella cartella config c'è un client.ncconf, quindi crea una voce. Ecco come l'applicazione sa a quale server connettersi.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
    <cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
      <server name="10.2.0.5"/>
      <server name="10.2.0.6"/>
    </cache>
  </configuration>

Ancora una volta, questi sono solo l'elenco iniziale dei server. Non è l'elenco finale. Come mai? Perché, per un ambiente ad alta disponibilità, cosa succede se aggiungessi quel terzo server in fase di esecuzione? Non è in questa lista, giusto? Quindi, diciamo, era il punto otto (.0.8), qualcosa. Quindi, questo è solo l'elenco iniziale. Una volta che l'applicazione ne conosce uno, si connette a quello. La prima cosa che accade all'applicazione, una volta che si connette, riceve le informazioni sull'appartenenza al cluster e anche ogni volta che l'appartenenza al cluster cambia e si aggiunge un altro server e l'appartenenza al cluster aggiornata viene inviata al client e tutto viene mantenuto in memoria. È tutto nascosto dalla tua applicazione. È tutto gestito dal NCache parte client ma è così che l'applicazione sa come connettersi alla cache.

Quindi, in caso di sessioni, vieni qui. Quindi, nelle sessioni, devi prima aggiungere l'assembly.

...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
    <compilers>
		<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
	</compilers>
	<assemblies>
	<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /></assemblies>
</compilation>
...

In caso di NCache tu solo... questa assemblea implementa il interfaccia del provider dello stato della sessione che fa parte dell'ASP.NET framework e così facendo NCache diventa una terza parte, un archivio personalizzato. E quindi, questo è solo un copia-incolla e quindi le modifiche effettive nel tag di stato della sessione. Quindi, quello che fai qui ti assicuri che la modalità sia personalizzata.

...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
    <providers>
        <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
    </providers>
</sessionState>
...

Quindi, le modalità sono, c'è In-Proc, il server di stato, l'SQL e c'è il costume. Quindi ci sono quattro modalità che hai. Quindi, se la modalità è personalizzata, devi anche assicurarti che il timeout sia quello che vuoi che sia il timeout della sessione e quindi copiare i dettagli del provider. Che è, in caso di NCache è questa riga e l'unica cosa che devono cambiare è il nome della cache. Quindi, ad esempio, qui il nome della cache è già cambiato. Fai quel cambiamento, tutto qui. E, non appena apporti tale modifica, ASP.NET riavvia comunque il tuo processo di lavoro e vedrai che ogni sessione verrà salvata come un unico oggetto nella cache e vedrai immediatamente un enorme aumento delle prestazioni. Perché ora non li stai salvando in SQL.

Quindi, il modo più veloce per beneficiare di una cache distribuita come NCache è semplicemente, metterlo per le sessioni. Perché, per l'oggetto per la memorizzazione nella cache dei dati dell'applicazione c'è più lavoro. Ovviamente sai, vuoi farlo in questo ed è quello che intendo approfondire, ma il primo caso d'uso è la specifica ASP.NET.

Qualche domanda su questo? Quindi, come abbiamo visto, ad esempio, alcuni dei nostri clienti di fascia alta hanno da 50 a 100 server nel livello dell'applicazione. Per questo, diciamo, mantenere un rapporto da 1 a 5 è ciò che di solito accade. Quindi per una configurazione di 100 server avranno 20 server di cache. Più di 50, sono pochissimi, sai, devi davvero avere molto traffico per avere più di 50 server in un ambiente con carico bilanciato. La maggior parte dei clienti ha da 4 a 12 server. Inoltre, consigliamo di avere un rapporto, come ho detto, 4 a 1 o 5 a 1 a seconda della natura dell'applicazione. A volte, può anche essere più di 5 a 1, ma voglio dire che questo è come il caso d'uso medio. Quindi, se hai un 5 a 1 e hai 12 server nel livello dell'applicazione, hai un livello di memorizzazione nella cache di tre server. Quindi, non così tante connessioni, sì.

Teoricamente sì. Se continui ad aggiungere sempre più server avrai un sacco di ridondanti. Ma i casi d'uso di cui stiamo parlando, non cadono. L'elaborazione di big data potrebbe avere 50 o 100 server ma non ci sono client in quel caso e un'elaborazione di big data è solo del server. Perché tutto è in esecuzione sul server stesso. Ma, nel caso di un'applicazione web o di un'applicazione di servizi web, quello che chiamiamo e-commerce, il modello di business online. Voglio dire, è più o meno. Penso che tu possa presumere che nella maggior parte dei casi avrai meno di 20 server e una percentuale molto piccola di clienti ne avrà più di 20 e più di 50 è molto piccola.

Sì, decisamente. Quindi, per esempio, se dovessi venire qui, lo farò... se dovessi venire qui. Non sto usando il Pacchetto NuGet qui ma potrei venire qui e andare al NuGet e potrei dire qui NCache, ad esempio, e otterrai un NCache SDK, NCache Servizi di sessione per Enterprise e Professional e c'è anche un Open-Source, c'è anche NHibernate. Quindi, ci sono un sacco di NuGet. Quindi, un tipico... per le sessioni includerai semplicemente questo pacchetto NuGet di sessione. Per la memorizzazione nella cache dei dati dell'applicazione, includi semplicemente l'SDK e questo includerà tutto ciò di cui hai bisogno.

Panoramica della memorizzazione nella cache dei dati dell'app (API)

Così, memorizzazione nella cache dei dati dell'applicazione è qualcosa in cui devi programmare. Quindi, vedi la cache come un database. Ti connetti alla cache. In caso di NCache abbiamo chiamato questo metodo Inizializza cache.

Connessione cache

Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

Recuperando i dati

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");

Scrittura di dati

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

Potresti avere altri metodi per altre cache e c'è un nome di cache in caso di NCache come abbiamo detto e questo ti dà un handle di cache.

Quindi, entriamo in un'applicazione. Ancora una volta, entreremo in ... Questa è una semplice applicazione console. Quello che fai è che, se avessi incluso il pacchetto NuGet, tutto questo sarà fatto per te. Ne faresti riferimento ad alcuni NCache assemblee. Quindi, ci sono solo due assiemi a cui devi fare riferimento, NCache.Durata ed NCache.Ragnatela. NCache.Ragnatela è l'attuale API pubblica in caso di NCache. Quindi nella tua applicazione includi lo spazio dei nomi. Quindi, hai il NCache.Durata ed NCache.Web.Caching come gli spazi dei nomi.

Quindi all'inizio dell'applicazione, ottieni il nome della cache da, diciamo, App.config e quindi inizializzi la cache e ottieni un handle della cache. Quindi, ecco quell'handle della cache che devi usare ovunque nell'applicazione.

Ora, entriamo nell'handle della cache. Quindi, puoi fare cache.Aggiungi, specificare la chiave. La chiave è come ho detto, di solito una stringa. L'oggetto è il tuo oggetto reale qualunque esso sia. È un qualsiasi oggetto .NET, NCache lo serializzerà effettivamente e lo invierà al cluster. Quindi, tutto questo sta accadendo sul lato client, sul server delle applicazioni.

// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;

namespace Alachisoft.NCache.Samples
{
    /// <summary>
    /// Class that provides the functionality of the sample
    /// </summary>
    public class BasicOperations
    {
        private static ICache _cache;

        /// <summary>
        /// Executing this method will perform all the operations of the sample
        /// </summary>
        public static void Run()
        {
            // Initialize cache
            InitializeCache();

            // Create a simple customer object
            Customer customer = CreateNewCustomer();
            string key = GetKey(customer);

            // Adding item synchronously
            AddObjectToCache(key, customer);

            // Get the object from cache
            customer = GetObjectFromCache(key);

            // Modify the object and update in cache
            UpdateObjectInCache(key, customer);

            // Remove the existing object from cache
            RemoveObjectFromCache(key);

            // Dispose the cache once done
            _cache.Dispose();
        }

        /// <summary>
        /// This method initializes the cache
        /// </summary>
        private static void InitializeCache()
        {
            string cache = ConfigurationManager.AppSettings["CacheID"];

            if (String.IsNullOrEmpty(cache))
            {
                Console.WriteLine("The CacheID cannot be null or empty.");
                return;
            }

            // Initialize an instance of the cache to begin performing operations:
            _cache = NCache.Web.Caching.NCache.InitializeCache(cache);

            // Print output on console
            Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
        }

        /// <summary>
        /// This method adds object in the cache using synchronous api
        /// </summary>
        /// <param name="key"> String key to be added in cache </param>
        /// <param name="customer"> Instance of Customer that will be added to cache </param>
        private static void AddObjectToCache(string key, Customer customer)
        {
            TimeSpan expirationInterval = new TimeSpan(0, 1, 0);

            Expiration expiration = new Expiration(ExpirationType.Absolute);
            expiration.ExpireAfter = expirationInterval;

            //Populating cache item
            CacheItem item = new CacheItem(customer);
            item.Expiration = expiration;

            // Adding cacheitem to cache with an absolute expiration of 1 minute
            _cache.Add(key, item);

            // Print output on console
            Console.WriteLine("\nObject is added to cache.");
        }

E poi, una volta che l'hai fatto, puoi farlo anche tu _cache.Get e recuperare lo stesso oggetto. Quindi, se dovessi vederlo in termini di API, ecco qui cache.Ottieni, Ottieni, Contiene, Aggiungi, Inserisci, Rimuovi e tutti e tre hanno una versione asincrona, il che significa sostanzialmente che l'applicazione non attende l'aggiornamento della cache, il controllo torna immediatamente. Ma la chiave è solitamente una stringa. Di solito è di qualcosa del genere. Hai il nome del tipo. In caso di NCache dipende. Se hai utilizzato questa funzione, chiama cache del cliente. Quindi, ho intenzione di saltare in quello.

Cache client (vicino alla cache)

Quindi, per impostazione predefinita, presumerai che ogni volta che esegui un cache.Get, stai effettivamente andando al livello di memorizzazione nella cache. Ma c'è una cosa interessante che la maggior parte delle persone non si rende conto, ovvero che, se hai utilizzato una cache In-Proc, come l'oggetto cache ASP.NET e hai deciso di passare a qualcosa di simile NCache perché abbiamo detto che migliorerà le prestazioni e la scalabilità. Beh, è ​​un po' migliorare la scalabilità, ma all'improvviso le tue prestazioni diminuiranno, abbiamo molti clienti che ci chiamano e dicono, sai, la mia applicazione è effettivamente rallentata da quando ho collegato NCache. Allora, perché ne ho davvero bisogno, lo sai. Non è davvero buono, è un-sai. Quindi, dobbiamo spiegare loro che quando si esegue una cache In-Proc, non c'è serializzazione, non c'è comunicazione tra i processi tra l'applicazione e la cache, sia che si trovi nella stessa casella o in una casella separata, di solito è un scatola separata, a destra. Quindi, se l'oggetto viene mantenuto nell'heap in una forma di oggetto, è super veloce, giusto. Basta andare e ottenere un riferimento. Niente può eguagliare quella prestazione. Ma il motivo per cui si passa a una cache distribuita è perché quel modello In-Proc ha molte limitazioni. Non può scalare. Non puoi aggiungere sempre più dati, è un solo processo e se hai più di un processo la duplicazione non è sincronizzata. Quindi, ci sono molti altri problemi, ecco perché passi a una cache distribuita, ma perdi quel vantaggio, giusto. Quindi, quello che abbiamo fatto è stato inventare questa cosa chiamata cache client che sul lato Java viene chiamata vicino alla cache e sul lato .NET dal momento e la cache è l'unica che ce l'ha.

Quindi, ciò che fa effettivamente, crea effettivamente una cache locale In-Proc all'interno dell'applicazione. Quindi, mantiene quell'oggetto in una forma di oggetto nell'heap. Quindi, ottieni le stesse prestazioni a cui sei abituato all'interno della cache In-Proc standalone. L'unica differenza è che questa cache sa che fa parte di una cache in cluster. Quindi, qualunque cosa conservi nella sua copia locale, ha un collegamento al livello di memorizzazione nella cache. Ha detto al livello di memorizzazione nella cache che, sai, ho questo oggetto, per favore avvisami se qualcuno cambia quell'oggetto. Quindi, se ce ne sono, diciamo, se questo client ha il numero dell'oggetto un altro client e, ovviamente, anche l'oggetto numero uno è in questo livello di memorizzazione nella cache. Un altro cliente entra e aggiorna l'articolo numero uno. Il livello di memorizzazione nella cache sa che queste cache client hanno l'elemento numero uno, quindi lo notificano tramite eventi, lo sai. In caso di NCache sono eventi abbastanza veloci. Questi non sono eventi .NET, sono comunicazioni a livello di socket. Quindi, la cache del client si aggiorna immediatamente. Quindi, stiamo parlando forse di un millisecondo di ritardo.

Quindi, in questo modo sei sicuro di essere, qualunque cosa tu stia ricevendo è tutto o la maggior parte del tempo è accurato. C'è tecnicamente qualche piccola probabilità che forse una copia più vecchia. In caso di NCache, se sei troppo preoccupato per questo, puoi usare quella che chiamiamo la modalità di sincronizzazione pessimistica in cui ogni volta che prendi qualcosa, sai, NCache controlla internamente il livello di memorizzazione nella cache per vedere se ha una copia più recente. In caso contrario, lo fornisce dai dati dalla cache del client, altrimenti lo recupera dal livello della cache. Ma non è necessario per la maggior parte dei casi. Nella maggior parte dei casi sei d'accordo a correre così tante possibilità. Quindi, questo ti dà l'aumento delle prestazioni della cache In-Proc. Ma, ancora una volta, la tua applicazione non sa che tutto ciò sta accadendo.

In caso di NCache la tua applicazione lo sa. L'applicazione pensa che stia solo parlando con il livello di memorizzazione nella cache. C'è solo una cache con cui sta parlando. Si chiama la mia cache o altro. È la cache demo e la cache demo può avere una cache client collegata tramite la configurazione in caso di NCache. Qualche domanda su questo?

API JCache (JSR 107).

Quindi, voglio dire che questo è l'aspetto di una tipica cache. È abbastanza facile fare questa programmazione. Quello che sta succedendo ora sul lato Java, perché ancora una volta continuo a lodarli perché sono molto più avanzati su questo. Hanno un'intera API standard chiamata JCache. Quindi, l'API di JCache è una caratteristica molto... ha tutte le caratteristiche di cui ho appena parlato o di cui sto parlando. Quindi, JCache è uno standard che ogni cache Java deve implementare se vuole essere compatibile con il settore.

API IDistributedCache

Sul lato .NET non esiste ancora una cosa del genere. C'è un oggetto cache ASP.NET che fino a poco tempo fa non era collegabile. Quindi, se programmi nella cache ASP.NET non puoi collegarti NCache al suo posto. Quindi, non puoi collegare una cache di terze parti. È solo una cache autonoma. In .NET 4.0 hanno avviato una cache .NET che non si è mai realmente attivata. Ora in ASP.NET core hanno un iDistributedCache interfaccia. Il che è ancora una volta, un metodo molto semplice per ottenere i metodi di input.

Quindi, il problema con l'API standard sarebbe che non sarai in grado di sfruttare tutte le funzionalità che dovrebbe darti una buona cache. Sei davvero limitato all'input di base. Ma ancora una volta, la maggior parte dei nostri clienti incapsula comunque il livello di memorizzazione nella cache. Quindi, anche se stanno facendo tutto NCache chiamate, l'intera applicazione non è esposta ad essa. Quindi, comunque ecco come appare l'API.

Funzionalità di memorizzazione nella cache dei dati dell'app

Ora, entriamo in alcune delle caratteristiche che sono importanti. Quindi, la maggior parte di loro... vai avanti. Solo una semplice domanda. C'è differenza tra inserire e aggiungere? Sì, inserire significa aggiungere o aggiornare. Se i dati esistono già, aggiornali, in caso contrario aggiungili. L'aggiunta avrà esito negativo se i dati esistono già. E, ancora una volta, questa è un'API della cache ASP.NET a cui siamo rimasti, perché vogliamo essere il più vicino possibile a qualunque fosse lo standard in quel momento. No, no, non lo è. Voglio dire, l'abbiamo tenuto. L'oggetto cache ASP.NET ora è sparito perché ora, come ho detto, nell'ASP.NET Core non c'è più, ASP.NET ce l'ha ancora ma ASP.NET Core non lo fa.

Scadenze assolute

Quindi, la prima cosa che devi tenere a mente è mantenere la cache fresca di cui abbiamo parlato, giusto. Come si fa quella tecnica numero uno è le scadenze. Le scadenze assomigliano a questo, torniamo a questo. Quindi, diciamo che ho... Ragazzi, potete vederlo? Riesci a vedere questo? OK. Diciamo che ho una chiave e un valore o qualche oggetto. Voglio aggiungerlo alla cache e specificherò una scadenza di 1 minuto. Quindi, questo è chiamato il scadenza assoluta.

public static void AddObjectToCache(string key, Customer customer)
    {
        DateTime expirationInterval = new DateTime();
        expirationInterval.AddMinutes(1);
        //Adding item with an absolute expiration of 1 minute
        _cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Console.WriteLine("\nObject is added to cache");
    }

La scadenza assoluta significa che dopo che è trascorso 1 minuto scadono questo, qualunque cosa accada. Ciò significa che sto dicendo alla cache, non mi sento davvero a mio agio a memorizzarlo nella cache per più di un minuto. Perché sto facendo un'ipotesi plausibile che sia sicuro tenerlo nella cache per un minuto.

Scadenze scorrevoli

La scadenza scorrevole d'altra parte ha uno scopo completamente diverso. È per la pulizia di cose come le sessioni. Non ha nulla a che fare con la sincronizzazione o il mantenimento della cache. Quindi, l'espressione assoluta è qualcosa che quasi tutte le cache hanno. Infatti, anche l'ASP.NET Core IDistributed Cache Interface ha l'espressione assoluta.

Sincronizza la cache con il database

Ma cosa c'è di sbagliato nel fatto che l'espressione sia l'unico modo per creare cache o mantenere la cache fresca? È che stai ipotizzando che questi dati non cambieranno. E se lo facesse? Cosa succede se ci sono altre applicazioni, ci sono altri script, che stanno modificando i dati che in qualsiasi azienda, di solito ci sono più posti da cui i dati vengono aggiornati. Quindi, se non puoi prevedere la frequenza con cui i dati verranno aggiornati, le espressioni sono solo un punto di partenza. Devi passare alla fase successiva, che è sincronizzare la cache con il database. Quindi, in pratica, sincronizzando la cache con il database in caso di NCache usiamo questa funzionalità che fa parte di ADO.NET .NET chiamata dipendenza SQL.

In sostanza, la dipendenza da SQL, lascia che ti mostri come appare. Quindi, in caso di una dipendenza SQL, sto facendo la stessa cache. Aggiungi, giusto. Avrò la chiave e invece di avere il valore avrò un elemento della cache che è la nostra struttura all'interno della quale mettiamo l'oggetto reale e ora abbiamo questo e quindi specifichiamo questa cosa chiamata dipendenza SQL, dipendenza del server SQL che è questa variabile che crea essenzialmente l'istruzione SQL.

private static void AddProductToCacheWithDependency(Product product)
    {
        // Any change to the resultset of the query will cause cache to invalidate the dependent data
        string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);

        // Let's create SQL depdenency
        CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);

        CacheItem cacheItem = new CacheItem(product);
        cacheItem.Dependency = sqlServerDependency;

        // Inserting Loaded product into cache with key: [item:1]
        string cacheKey = GenerateCacheKey(product);
        _cache.Add(cacheKey, cacheItem);
    }

Questo codice è in esecuzione sulla casella del client, proprio qui.

Parla con il server cache. Indica al server cache di utilizzare la funzione di dipendenza SQL ADO.NET per connettersi al mio database. Quindi, in realtà mi dà una stringa di connessione al database. Quindi, ora l'applicazione dice alla cache, ecco il mio database per questo elemento memorizzato nella cache, ecco l'istruzione SQL che rappresenta i dati corrispondenti nel database.

Integrazione Entity Framework/ Entity Framework Core

Buona domanda. Nel caso di Entity Framework, l'implementazione che abbiamo per Entity Framework l'abbiamo implementata all'interno. Anche con Entity Framework ci sono due modi per usare una cache. O tu, nel caso di EF Core ora la nuova architettura consente il collegamento della cache di terze parti ma fino a EF6 non c'era modo di collegare una cache. Quindi, dovresti comunque effettuare queste chiamate API. Quindi, diciamo, hai recuperato una raccolta di entità e mentre le memorizzi nella cache puoi specificare la dipendenza SQL. Hai capito cosa intendevo?

In caso di NCache stai dicendo NCache ecco la mia istruzione SQL. NCache useremo ADO .NET per connetterci al tuo database e useremo la funzione di dipendenza SQL di ADO.NET per quindi monitorare quel set di dati. Così, NCache sta dicendo al server SQL, per favore avvisami se questo set di dati cambia. Quindi il server SQL invia una notifica del database a NCache perché NCache non è un client del database e quindi NCache ora sa che questi dati sono cambiati nel database. Quindi, anche se avevi EF, è come bypassare quello e ora quello NCache sa che questi dati sono cambiati NCache ha due opzioni. Uno può rimuovere quell'elemento dalla cache e quando lo rimuovi, sai, la prossima volta che qualcuno ne avrà bisogno non lo troverà nella cache, quindi dovranno andare a prenderlo dal database. Quindi, in un certo senso lo stai preparando fresco o NCache può ricaricare quei dati dal database stesso per te e ciò non è possibile a meno che tu non usi un'altra funzionalità chiamata read-through, ci arriverò.

Quindi, la dipendenza SQL garantisce sostanzialmente che se non puoi prevedere quando i dati potrebbero cambiare, lo dici NCache o la tua cache, per favore, controlla il database per me.

La dipendenza SQL ha una limitazione per cui non puoi avere join al loro interno. Quindi, è una cosa da tavolo singolo. Ci sono altri modi per monitorare. Ad esempio, in caso di NCache c'è una funzione chiamata Dipendenza personalizzata, che è il tuo codice. NCache chiama il tuo codice e dice per favore vai a monitorare la tua fonte di dati e vedere se i dati sono cambiati. Quindi, è un po' come fare un sondaggio. Così, NCache eseguirà il polling della tua dipendenza personalizzata e quindi potrebbe essere una struttura complessa.

Si Esattamente. In realtà, quando esegui la dipendenza SQL, la cache non parla con il database così frequentemente, perché solo... Quindi, il database è quello che avvia la comunicazione perché c'è un evento. È un'architettura guidata dagli eventi. Quindi, il database invia un evento ogni volta che i dati cambiano.

In realtà il server SQL ha questa funzione in cui monitora il set di dati e quindi invia notifiche di database ai client. Così, NCache diventa un client di database.

Quindi, un'opzione era rimuovere quell'elemento dalla cache. L'altro è semplicemente ricaricarlo. Bene, ricaricare significa NCache deve avere un modo per sapere come ottenere quei dati e questo significa che c'è questa funzione chiamata read-through che è il tuo codice che scrivi e registri con il server cache, il cluster di cache. Ti mostrerò rapidamente come appare quel codice.

Cache di lettura

No, in realtà è solo il tuo codice personalizzato. Quindi, anche tu puoi effettuare chiamate ORM all'interno di quel codice. Quindi, tutto quel codice sembra essere questo. Quindi, c'è un'interfaccia IReadThruProvider, proprio qui.

...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
    object connString = parameters["connstring"];
    sqlDatasource = new SqlDatasource();
    sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}

// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
    sqlDatasource.DisConnect();
}

// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
    ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
    cacheItem.ResyncOptions.ResyncOnExpiration = true;
    // Resync provider name will be picked from default provider.
    return cacheItem;
}
...

Quindi, c'è l'interfaccia IReadThruProvider. Ha tre metodi. C'è un Init che viene chiamato solo all'avvio della cache. Quindi, dovrebbe connettersi alla tua origine dati. C'è uno smaltimento che è alla fine e c'è un carico. Quindi, il caricamento ti dà una chiave e dovresti restituire un elemento della cache.

Quindi, in base a quella chiave, il tuo codice deve sapere dove andare perché è già connesso alla tua origine dati. Quindi, sia che tu lo usi ORM, sia che tu faccia chiamate EF, chiamate NHibernate, chiamate ADO.NET, questo è tutto il tuo codice e poi andrai a caricarlo, diciamo, andrai a caricare quell'oggetto dal database e tu inseriscilo e metti scadenze o qualsiasi altro metadato che desideri con esso e lo restituisci NCache. NCache lo memorizzerà quindi nella cache, prima di restituirlo all'applicazione.

Quindi, l'intero scopo del read-through ... fammi arrivare a questo read-through stesso. Il read-through è un modo per consentire alla cache di caricare i dati dal database. Quindi, stai effettivamente spostando parte del tuo codice di persistenza nel livello di memorizzazione nella cache. E, se hai più applicazioni che vogliono condividere una cache, è perfetto avere un meccanismo di lettura e scrittura. Perché stai consolidando, stai creando le applicazioni, una specie di meno codice, lo sai. Quindi, avranno meno codice perché sempre più codice di persistenza andrà al livello di memorizzazione nella cache. Questo è un vantaggio. Sai, incapsulamento e consolidamento.

Il secondo vantaggio del read-through è quello di cui abbiamo appena parlato di ricaricare. Quindi, la ricarica avviene in due casi. Uno in sincronizzazione del database, l'altro in scadenza. La scadenza è anche un ottimo caso se hai un'applicazione ad alto traffico che, diciamo, hai una sorta di tabella di ricerca o tabella dei prezzi che cambia e hai migliaia di richieste in arrivo, se non hai il ricarica la funzione quindi quando i dati scadono migliaia di quelle richieste andranno a colpire il database. E caricheranno tutti lo stesso oggetto nella cache. Che alla fine è solo molto traffico verso il database. Moltiplichi che per migliaia di elementi che potresti avere il tuo database vedrà molto traffico non necessario.

In effetti, uno dei nostri clienti è un cliente di e-commerce di fascia alta nel settore dei fiori negli Stati Uniti, ha avuto quel problema. Quindi, quando hanno implementato la funzione di ricarica all'improvviso, l'intero problema è scomparso perché ora quell'elemento non viene mai rimosso dalla cache. Quindi, le vecchie copie vengono conservate fino a un certo punto e la nuova copia viene aggiornata su di essa. Quindi, l'applicazione non deve mai andare al database. Quindi, perché anche durante l'esplorazione aggiorna semplicemente la nuova copia. Quindi, è molto... Quindi, questi sono i due vantaggi che puoi combinare con questa sincronizzazione.

Cache write-through

L'altro aspetto è il write-through, che funziona proprio come il read-through tranne che per la scrittura e una scrittura può essere aggiunta, inserita o eliminata o rimossa. Ancora una volta, allo stesso modo in cui hai Init, hai Dispose e ora hai WriteToDataSource. Dice qual è l'operazione e ha anche i dati e tu vai ad aggiornare il database. Quindi, write-through significa che aggiorni la cache, la cache aggiorna il database.

Allora, qual è il vantaggio di write-through? Bene, un vantaggio è lo stesso della lettura. Consolidi tutta la persistenza. In secondo luogo, il vantaggio è il write-behind. Perché gli aggiornamenti del database non sono veloci come, sai, e se ritieni che l'aggiornamento del database avrà esito positivo, aggiorna semplicemente la cache e lascia che la cache aggiorni il database in modo asincrono. Ovviamente puoi essere avvisato se qualcosa non va, ma puoi andare avanti e fare altre cose e questo migliora anche le prestazioni di aggiornamento della tua applicazione. Quindi, ora non devi attendere il completamento degli aggiornamenti del database perché sono tutti in coda. Quindi, questa è la parte write-behind. Inoltre, la coda write-behind viene nuovamente replicata su più server. Quindi, se un server si interrompe, nessuna delle tue operazioni andrà persa, in caso contrario NCache.

Ma questo è il tuo codice. intendo NCache chiama il tuo. Quindi, tutto questo è il tuo codice. Così, NCache ti chiama e capisci cosa significa la scrittura o cosa significa la lettura.

Quindi, read-through, write-through è un'altra funzionalità molto potente che puoi combinare con la scadenza e la sincronizzazione. Quindi, devi assicurarti che la cache rimanga aggiornata e quindi devi assicurarti di utilizzare il read-through, write-through. Ora che inizi a farlo, puoi memorizzare nella cache molti dati. E ora quella cache inizia ad assomigliare al database. Ciò significa che non puoi davvero ottenere, sai, la chiave non è abbastanza ora. Devi essere in grado di fare ricerche. Devi essere in grado di recuperare le cose in modo più intelligente. Quindi, è qui che dovresti essere in grado di eseguire query di tipo SQL sulla cache. Ad esempio, qualcosa come clienti selezionati, dove il punto cliente City è uguale a Londra. Ti dà una raccolta di tutti gli oggetti del cliente che corrispondono a quei criteri. E la cache indicizza quegli oggetti in base, diciamo, all'attributo della città. Quindi, è così che ti permette di cercare.

Quindi, se non sei in grado di farlo, la tua applicazione diventa più complessa perché puoi cercare cose solo su chiavi e, sai, sei abituato a fare molte altre cose con il database che non puoi fare con la cache.

Non ci sono join in una cache ma puoi fare raggruppamenti. E quel tipo di servire allo scopo che puoi ottenere dati e quindi raggrupparli e quindi in base a quei gruppi puoi dirmi di dammi tutto ciò che appartiene a questi gruppi, sottogruppi, tag, targhette. Quindi, ci sono altre cose che puoi fare per raggruppare logicamente le cose e i dati stessi che stai memorizzando nella cache possono arrivare attraverso i join. È solo che la cache non può essere... la cache non è un motore di ricerca. Quindi, se disponi di dati di partecipazione, raggruppali.

Dipendenze della cache

Quindi, c'è una caratteristica e ancora perché c'è così tanto di questo che non posso davvero coprire in questo momento. Quindi, c'è una funzione chiamata dipendenza dalla cache che viene dall'oggetto cache ASP.NET tra l'altro, NCache ha anche implementato che consente ... Dici alla cache che questo elemento dipende da questo elemento. Se questo elemento viene aggiornato o rimosso, questo viene automaticamente rimosso. Quindi, creando quelle relazioni puoi avere quell'uno-a-molti, diciamo, se avessi una relazione uno-a-molti in cui i molti lati non possono esistere senza l'uno. Diciamo che è un cliente e un ordine. Quindi, se rimuovi il cliente, vuoi rimuovere anche l'ordine. Quindi, puoi lasciare che la cache lo gestisca per te. Allo stesso modo, quando si memorizza nella cache, diciamo, si ottiene una raccolta di oggetti, è possibile memorizzare nella cache l'intera raccolta come un unico oggetto o suddividerli in un individuo. Se li interrompi, allora vuoi fare le dipendenze della cache. Quindi, se un qualsiasi oggetto viene rimosso, quella raccolta non è più valida.

Sì, quindi, questo è un intero argomento su cui ho un discorso, che puoi venire sul nostro sito web. Lascia che te lo mostri velocemente. Quindi, c'è un intero discorso su questo. Penso che sia Gestione dei dati relazionali in una cache. Quindi, questo va oltre tutto l'uno-a-molti, uno-a-uno, molti-a-molti, che va oltre le raccolte e tutte quelle cose di cui hai appena parlato. Vai e dai un'occhiata. Mi limiterò a passare velocemente perché non abbiamo tempo a disposizione.

Quindi, ho provato a fare un caso sul perché dovresti usare una cache e come dovresti usarla e massimizzare i benefici attraverso di essa. Ho intenzione di saltare il condivisione dei dati di runtime parte, penso di aver coperto abbastanza. Puoi andare sul nostro sito Web e leggere di più. Ho parlato della cache del client, ho parlato dell'alta disponibilità attraverso il partizionamento e tutto il resto.

Replica WAN della cache distribuita

Ci sono anche più datacenter. Sai, ti aspetti che il tuo database sia in grado di gestire più data center, quindi, perché non la cache, lo sai. Quindi, di nuovo, NCache ti fornisce questa funzione. Sul lato Java hai cache che fanno questo. Sul lato .NET NCache è l'unico. Quindi, puoi avere un datacenter attivo-passivo o attivo-attivo e le cache sono sincronizzate. Ancora una volta, non puoi avere un cluster che si estende sulla WAN, perché le prestazioni si esauriscono. Devi eseguire una replica o una sincronizzazione asincrona attraverso la WAN perché quando hai due data center potrebbero non trovarsi nella stessa posizione.

Uno dei nostri clienti è Ryanair che è una grande compagnia aerea qui e hanno un datacenter a Dublino, Londra e Francoforte. Quindi, devono assicurarsi che possano sincronizzarsi. In caso di NCache abbiamo anche Replica WAN. Esiste anche un concetto di sessione multi datacenter in cui la sessione può spostarsi da un datacenter all'altro. Ma, comunque, la tua cache deve essere in grado di supportare più data center. Quindi, assicurati di esaminarlo.

NCache vs Redis

La maggior parte della gente di .NET conosce Redis. NCache, mi dispiace, Microsoft li ha selezionati come loro scelta per Azure anche se Redis proviene da un background Linux. Penso che il motivo principale per cui Microsoft li ha scelti sia perché volevano avere più lingue. Così, Redis copre molte lingue. NCache è praticamente focalizzato su .NET. Abbiamo anche API Java ma NCache di per sé è focalizzato su .NET. Voglio fare una rapida panoramica dei due solo in modo che tu possa vedere cosa significa e poi puoi venire sul nostro sito Web e in realtà c'è un vero e proprio confronto. Puoi fare un confronto delle funzionalità qui. E poi puoi anche scaricare questo. Quindi, dai un'occhiata a questo. Si basa sulla loro documentazione e sulla nostra. Quindi, non è altro che... non c'è alcun effetto in questo.

NCache è anche open source, così è Redis. In caso di NCache hai il... puoi venire sul nostro sito web e puoi scaricare o l'Enterprise Edition o l'open source oppure puoi anche andare su GitHub, dove si trova NCache? Proprio qui GitHub e poi puoi vedere NCache anche qui.

Quindi, questa edizione aziendale è completamente supportata. In caso di Redis Microsoft ha portato Redis da Linux a Windows. Quindi, si potrebbe pensare che Microsoft stia utilizzando la porta in Azure, ma non lo è. Quindi, la porta che hanno ha molti problemi. Molti clienti se ne sono lamentati con noi.

Quindi, se usi Redis in Azure usano la versione Linux è stabile, non ci sono problemi, ma perdi tutte le funzionalità di cui abbiamo appena parlato. Se vuoi fare un supporto on-premise, NCache ti darà l'open source è tutto gratuito, l'impresa è qualcosa che ottieni più funzionalità di quante paghi anche per il supporto. Se vuoi in loco con Redis, l'unica opzione che hai è andare con la versione Linux da Redis laboratori. Ora hanno anche questo nella finestra mobile. Quindi, puoi eseguirlo tecnicamente su Windows ma comunque nell'ambiente Linux per loro. L'on-prem di Windows è di Microsoft, che come ho detto è instabile e senza supporto.

In azzurro Redis ti offre un modello di servizio cache, NCache ti dà un modello VM. Il modello VM ti offre molto più controllo. Tutte queste cose di cui abbiamo appena parlato read-through, write-through, caricatore della cache, sincronizzazione del database, ottieni tutto quel controllo e c'è solo un'API client.

Questa è solo una rapida panoramica dei due. Volevo una specie di accenno. Fondamentalmente, NCache è la cache più vecchia nello spazio .NET. Abbiamo tonnellate e tonnellate di clienti che utilizzano NCache. Inoltre, molti di loro sono nel Regno Unito. Sai, il Regno Unito è il nostro secondo mercato più grande e se hai un'applicazione .NET, spero che tu preferisca che l'intero stack sia .NET. NCache ti dà quello stack .NET, Redis non lo fa.

Qualche domanda prima di concludere questo discorso? Ma poi stai esponendo tu stesso il partizionamento. Perché, in un database relazionale, devi quindi programmare l'applicazione in modo che i dati risiedano nell'uno o nell'altro. Voglio dire, l'intero concetto di No SQL è che fanno lo sharding per te perché tutto è basato sulla chiave. In un relazionale hai molte più complessità e finora nessuno dei database relazionali è stato in grado di affrontare il problema della scalabilità. Hanno provato molto duramente e hanno migliorato enormemente le prestazioni. Ci sono molte opzioni in memoria, quindi hanno anche database in memoria e fanno molte tabelle in memoria e cose del genere. Quindi, le prestazioni sono leggermente migliorate, ma le prestazioni non sono il problema qui. Sai, il problema è la scalabilità. Riesci a gestire quel carico e finora non possono.

Quindi, il motivo per cui abbiamo l'indicizzazione è che puoi cercare su quegli attributi. Quindi, potresti eseguire un'istruzione SQL e cercare quegli attributi dell'oggetto su cui sei stato indicizzato.

Quindi, quello che facciamo è che non ti permettiamo di fare una ricerca a meno che tu non abbia creato l'indice. Quindi, se fai una ricerca NCache genererà un'eccezione dice che questo attributo non è stato indicizzato. Quindi, in un modo un po' più doloroso, sì. Ma quello che diciamo ai nostri clienti è che, qualunque cosa tu stia cercando di cercare, devi creare un indice. E, a differenza di un database in cui tutto è SQL, qui tutto non passa attraverso l'SQL. Ancora una volta, stai facendo un sacco di cose solo attraverso l'API e poi alcune cose sono attraverso l'SQL.

Intendi per il nome della cache? C'è una convenzione secondo cui la chiave dovrebbe contenere le informazioni sul tipo e quindi in base a determinati, diciamo, se si tratta di un singolo oggetto e il tipo e il valore della chiave primaria o il nome dell'attributo della chiave primaria e quindi il valore, quello è il cosa comune e quindi se stai salvando l'intera collezione, diciamo, stai salvando tutti gli altri ordini per il cliente e quindi potresti volerlo recuperare in base al cliente, quindi la chiave può essere cliente, ID cliente, i miei ordini o qualcosa del genere così, lo sai. Quindi, le chiavi devono essere significative in base a come vuoi recuperare i dati.

Sì, tutte queste sono opzioni che puoi scegliere. Se guardi il mio video sulla gestione dei dati relazionali, esamino tutte queste opzioni. E, sempre con la memorizzazione nella cache, diciamo che hai una relazione molti-a-molti nel database. Non ci sono molti a molti a livello di applicazione. Nell'applicazione o ti avvicini da questo lato o da questo lato. È sempre uno a molti. Quindi, è cose del genere che improvvisamente la prospettiva cambia.

Non stai cercando di ricreare l'intero database in memoria. Puoi ricapitolare i vantaggi dell'utilizzo di una cache distribuita? Hai detto che era scalabilità. Ce ne sono altri? Penso che il vantaggio più importante sia la scalabilità. Il vantaggio secondario sono le prestazioni e, ancora una volta, per i casi d'uso, per i casi d'uso specifici di ASP.NET, le sessioni, c'è un enorme vantaggio. Perché le alternative a una cache distribuita sono tutte molto lente o non scalabili. Quindi, se esegui un In-Proc, non è scalabile. Perché devi seguire lo stesso processo ogni volta.

Sto anche registrando questo e penso che lo sia anche l'SDD Conf. Faremo questo discorso su YouTube e se vieni al nostro stand e ti lasci scansionare, possiamo inviarti via email il link al discorso e poi puoi condividerlo con i tuoi colleghi. Grazie mille ragazzi per la vostra pazienza.

Cosa fare dopo?

• NCache Dettagli
• Scaricare NCache
• Richiedi una Demo LIVE personalizzata