Campo del codice di Boston 31

Ottimizza ASP.NET Core Prestazioni con cache distribuita

Di Iqbal Khan
Presidente ed evangelista tecnologico

ASP.NET Core sta rapidamente diventando popolare per lo sviluppo di applicazioni Web ad alto traffico. Scopri come ottimizzare ASP.NET Core prestazioni per la gestione di carichi di transazione estremi senza rallentamenti utilizzando una cache distribuita .NET open source. Questo discorso copre:

Panoramica rapida di ASP.NET Core colli di bottiglia delle prestazioni
Panoramica della cache distribuita e di come risolve i problemi di prestazioni
Dove puoi utilizzare la cache distribuita nelle tue applicazioni
Alcune importanti funzionalità della cache distribuita
Esempi pratici utilizzando Open Source NCache come cache distribuita

Ok, grazie a tutti, tutti mi sentono bene? Ok, ho dimenticato di includere la diapositiva, ringraziando tutti gli sponsor. Vado solo sul sito e ti mostro i loghi di tutti gli sponsor. siamo uno di loro comunque, quindi lo mostrerò anche alla fine. Questo è ciò che ci hanno detto gli organizzatori. Quindi, affronterò questo argomento e vorrei mantenere questa conversazione più interattiva, se possibile. Quindi, se avete domande, sentitevi liberi di fermarmi. Fammi solo assicurarmi che tutto stia registrando.

Quindi, l'argomento di oggi è come si ottimizza ASP.NET core prestazioni dell'applicazione con cache distribuita? Userò un prodotto open source chiamato NCache. Quanti qui ne hanno sentito parlare NCache prima? È un buon numero. Va bene, lo userò NCache come esempio. Questo discorso non riguarda NCache, si tratta di ASP.NET Core prestazioni e come è possibile utilizzare la memorizzazione nella cache? Quindi, sono sicuro che eri qui perché l'ASP.NET core è diventato popolare, sta diventando popolare, è la nuova architettura leggera e pulita, è la tecnologia multipiattaforma, la riprogettazione di .NET è open source, ci sono molte applicazioni legacy ASP.NET che si stanno spostando anche su ASP.NET core. Asp.NET core sarà la tecnologia principale con cui svilupperai applicazioni web in .NET.

Quindi, sempre più persone ora stanno sviluppando applicazioni che richiedono scalabilità. Quindi, ASP.NET core ovviamente necessita anche di scalabilità. Permettetemi di definire rapidamente cos'è la scalabilità? Sono sicuro che molti di voi lo sanno già, ma per motivi di completezza, lo definirò.

Che cos'è la scalabilità?

La scalabilità è se hai un'applicazione che ha un tempo di risposta davvero buono, funziona davvero bene con cinque utenti, se riesci a mantenere le stesse prestazioni con cinquemila, cinquantamila, cinquecentomila utenti, la tua applicazione è scalabile. Se la tua applicazione non funziona bene con cinque utenti, allora hai altri problemi che non affronteremo qui. Quindi, parlerò di come mantenere quelle buone prestazioni da cinque utenti a cinquantamila o cinquecentomila utenti.

Scalabilità lineare

La scalabilità lineare significa che la tua applicazione è progettata in modo tale che tu possa semplicemente aggiungere più server in produzione man mano che il tuo carico aumenta e man mano che aggiungi più server, la tua capacità di transazione aumenta ed è ciò che ti dà quelle buone prestazioni se sei in grado di mantenere scalabilità lineare. Se non sei in grado di mantenere la scalabilità lineare, c'è una sorta di collo di bottiglia, che la tua applicazione dovrà affrontare molto presto quando aggiungi più server, molto presto non importa se aggiungi più server o meno e lo farai appena colpito un collo di bottiglia, c'è e parlerò del collo di bottiglia.

Le seguenti applicazioni richiedono scalabilità

Quindi, quali applicazioni necessitano di scalabilità? Generalmente, applicazioni server, queste sono applicazioni web, ASP.NET core, servizi Web, utilizzati da altre applicazioni Web. I servizi Web potrebbero essere applicazioni indipendenti che vengono utilizzate da applicazioni esterne o potrebbero far parte di applicazioni Web che stai sviluppando, in entrambi i casi, se hanno transazioni elevate, avranno anche bisogno di scalabilità.

I microservizi stanno diventando una nuova parola d'ordine ora, ecco come vuoi riprogettare la tua applicazione. I microservizi utilizzeranno anche la loro tecnologia lato server, sono utilizzati in applicazioni ad alta transazione e avranno bisogno di scalabilità. Per qualsiasi altra applicazione server, molte grandi organizzazioni hanno l'elaborazione batch nel back-end e devono eseguire il flusso di lavoro nel back-end. Un gruppo di applicazioni server back-end che devono solo provare a gestire molte transazioni, avranno anche bisogno di scalabilità. Quindi, se la tua azienda o se sei impegnato in uno di questi tipi di applicazioni e desideri avere buone prestazioni, questo è il discorso che fa per te.

Il problema della scalabilità

Quindi, ora che abbiamo stabilito che queste applicazioni necessitano di scalabilità, c'è un problema di scalabilità? Sì, c'è e non è nel livello dell'applicazione, l'ASP.NET core applicazione puoi facilmente aggiungere più server man mano che il carico della transazione aumenta e, di solito, hai un sistema di bilanciamento del carico davanti al livello dell'applicazione, che indirizza il traffico in modo uniforme a tutti i server e poiché hai sempre più utenti, aggiungi semplicemente più scatole, nessun problema lì. Il problema ovviamente è l'archiviazione dei dati o dei database. Questi sono i tuoi database relazionali, il tuo mainframe e questo è uno dei motivi, perché NoSQL databases ha iniziato a prendere piede, ma si è scoperto che nella maggior parte delle situazioni è ancora necessario utilizzare database relazionali, sia per motivi tecnici che non. Quindi, se guardi alla maggior parte delle applicazioni che voi ragazzi avete fatto o state facendo, finite per usare database relazionali nel caso di .NET, quello più popolare ovviamente è un server SQL. Quindi, se non sei in grado di utilizzare a NoSQL database, a che serve aiutare con la scalabilità? E il motivo è che il NoSQL database ti chiede di abbandonare il database relazionale e di spostare i dati in NoSQL, che per alcuni dati puoi, per molti dati aziendali non puoi, tutti i tuoi clienti, i tuoi account, le tue attività tutto ciò che deve ancora rimanere in un database relazionale. Quindi, devi risolvere questo problema di scalabilità con i database relazionali nella foto ed è per questo che lo dico NoSQL database non è sempre la risposta perché non sei in grado di usarlo.

La soluzione (cache distribuita)

Quindi, il modo per risolvere questo problema, ovviamente, è utilizzare una cache distribuita e questo è il modo in cui una cache distribuita viene distribuita nel tuo ambiente.

Quindi, questo è il livello dell'applicazione, in alcuni casi potresti avere un bilanciamento del carico qui davanti, che dirige il traffico a tutti i server delle applicazioni. In alcuni casi, potrebbe non esserci un sistema di bilanciamento del carico, potrebbe esserci un altro modo in cui il carico viene condiviso perché si tratta di alcune applicazioni back-end, ma comunque hai più server che eseguono le tue applicazioni. Quindi, questo è molto scalabile ma al database non puoi continuare ad aggiungere sempre più database. Ora che le società di database relazionali stanno cercando di fare tutto il possibile per ridimensionarsi, ad esempio, hanno tabelle in memoria, che sono molto più veloci. Penso che anche il server SQL non abbia introdotto questo concetto di repliche di sola lettura dove si trovano, quindi se combini tabelle in memoria con repliche di sola lettura, ottieni un aumento delle prestazioni ma come vedrai, entrerò in questo. Più repliche crei, più mal di testa hai, in termini di aggiornamento ogni volta che aggiorni qualcosa deve essere aggiornato su tutte le repliche. Pertanto, per ottenere le migliori prestazioni con la scalabilità è necessario assicurarsi di non avere più di una replica. Quindi, una copia master e una replica di ogni dato e, allo stesso tempo, devi essere in grado di ridimensionare. Quindi, il motivo per cui non possono farlo è che un database relazionale non può essere partizionato nello stesso modo in cui può essere una cache distributiva o un NoSQL database può essere perché sia cache distribuita che NoSQL sono coppie chiave-valore, che è un design molto diverso da un database relazionale, ma alla fine è necessario inserire una cache distribuita come livello di memorizzazione nella cache tra il livello dell'applicazione e il database.

Quindi, che aspetto ha in termini di qual è la configurazione? Quindi, in genere queste non sono scatole molto costose. Di solito si tratta di scatole da 8 core a 16 core, molta memoria da 16 a 32 giga di memoria e schede di rete da 1 a 10 gigabit. A volte hai due schede di rete, una per il clustering e una per gli strumenti che ordinano i client, ma questo è tutto, è molto diverso dall'ottenere un server di database di fascia alta con molta potenza di elaborazione per fare il tuo lavoro perché ce n'è solo uno o pochissimi. Quindi, non c'è altro modo per aggirare questo. Diciamo ai nostri clienti che non ottengono più di 64 giga di RAM per scatola perché quando si hanno più di 64 giga di RAM in un ambiente .NET, quella memoria deve essere raccolta tramite Garbage Collection e raccolta man mano che si accumula sempre più memoria di quanto ti serva più potenza di elaborazione. Quindi, allora entri nello stesso problema di iniziare a ottenere scatole davvero costose. È meglio avere una memoria da 32, da 16 a 32 bit, da 16 a 32 giga, ma più scatole lo rendono più economico.

Come funziona una cache distribuita?

Quindi, cosa fa una cache distribuita? In realtà crea un cluster e di nuovo sto parlando da un NCache prospettiva, ce ne sono anche altri simili Redis che fanno cose simili ma in un modo diverso. Quindi, la cache distribuita creerà un cluster, è un cluster basato su TCP e la cosa più importante in un cluster è che, proprio come non vuoi che il database vada inattivo e in produzione, non vuoi che la cache scendi anche tu. Quindi, questo cluster deve essere altamente disponibile. Quindi, il modo migliore per renderlo altamente disponibile per i clienti è assicurarsi che abbia un'architettura peer-to-peer, in cui ogni nodo è un cittadino uguale e qualsiasi nodo può andare giù o puoi aggiungere più scatole, non c'è master- slave perché ciò crea complicazioni e problemi di alta disponibilità. Quindi, ha raggruppato le risorse, la memoria, la CPU e la scheda di rete come risorse. Quindi, quando ne aggiungi di più, diciamo che hai sempre più traffico o sempre più transazioni aggiungi più server in seguito con un rapporto 4 a 1, 5 a 1 che di solito aggiungeresti più caselle. Minimo due server di cache e poi continui ad aggiungerne altri, quindi inizi con due, inizierai ad avere sempre più carico e all'improvviso tutto inizierà a rallentare e aggiungi una terza casella tutto migliora quando ne aggiungi altri carica e aggiungi più scatole, qui le cose iniziano a rallentare fino a un certo punto. Aggiungi una quarta casella e l'immagine va.

Quindi, è così che si ridimensiona in modo lineare, in teoria, niente è illimitato ma si adatta a più situazioni, si ridimensiona in modo illimitato dove non c'è collo di bottiglia. Quindi, questo ti consente di non fare in modo che il tuo database diventi un collo di bottiglia. Quindi, questa è diventata praticamente una best practice essenziale per l'architettura dell'applicazione. Se stai facendo applicazioni ad alta transazione, devi incorporare la cache distribuita e poiché questo è l'unico modo, sarai in grado di ottenere prestazioni perché è tutto in memoria, tutto ciò che tocca il disco non può mai essere veloce come in -memoria e scalabilità perché è distribuito. Qualche domanda su questo prima di andare? In realtà, nel caso di NCache puoi. NCache supporta .NET e Java ma se hai altre applicazioni come Python o altre, non puoi usarle NCache, devi quindi utilizzare altre soluzioni di memorizzazione nella cache, ma l'applicazione deve trovarsi in un ambiente scalabile. Fondamentalmente, non importa quale lingua usi, la funzionalità rimane la stessa. Ci sono alcuni vantaggi, se sei un'applicazione .NET allora NCache ti offre molti vantaggi specifici di .NET che è uno stack .NET completo, il suo stack di corsi .NET, quindi si adatta molto bene. Ci sono prodotti simili anche sul lato Java che sono chiamati griglie di dati in memoria e quindi si adattano molto bene allo stack Java. Ad esempio, condividerò solo alcune informazioni. Così, NCache ha un'API Java ma le uniche persone che usano l'API Java sono quelle che acquistano NCache o usare NCache da una prospettiva .NET. Quindi, hanno NCache internamente e hanno detto che potrebbe anche usarlo per Java e un negozio Java cercherà una griglia di dati in memoria basata su Java, un negozio .NET cercherà NCache. Quindi, è così che il mercato è segmentato a causa di tutta l'esperienza, se sei un negozio .NET, hai tutta l'esperienza .NET rispetto a Java. Allora, perché complicare il quadro? Per i database, quindi è possibile utilizzare qualsiasi database non SQL? Chiunque, chiunque perché il modo in cui accedi al database avviene tramite il tuo codice personalizzato che risiede nel livello di memorizzazione nella cache.

Quindi, questa è un'altra caratteristica che esaminerò è che una delle caratteristiche essenziali per assicurarsi che la cache rimanga sincronizzata con il database è che il codice personalizzato deve vivere sul server della cache. Se rendi la cache una scatola nera, dove non c'è nulla nella cache tranne i dati che è come avere un database relazionale senza trigger e stored procedure o altro. Quindi, questo limita l'uso della cache. Quindi, le cache inizialmente erano solo la scatola nera. Memcached era una cache popolare, non faceva nulla, era solo un negozio e, nel tempo, si sono evoluti in una vera e propria entità intelligente in cui possono anche eseguire il tuo codice. Qualsiasi NoSQL, qualsiasi database relazionale può essere utilizzato con esso. E ancora, tutte queste funzionalità di cui sto parlando sono sia open source che enterprise. Quindi, ecco perché lo sto menzionando perché è open source. Qualsiasi altra domanda? Quando si ha a che fare con NCache è per lo più la memorizzazione nella cache automatica o usi l'API per la cache? Quindi, entrerò più nel dettaglio, ma dipende da cosa stai memorizzando nella cache? Alcuni tipi di utilizzo della cache sono automatici. Ad esempio, se stai inserendo ASP.NET core sessioni quindi è un modulo collegabile, si collega e inizia a memorizzare le sessioni nella cache, quindi non c'è niente che devi fare, ma se hai intenzione di memorizzare nella cache i dati dell'applicazione che è dove la maggior parte del vantaggio è , quindi c'è un'API che devi chiamare per determinare, cosa vuoi memorizzare nella cache? Per quanto tempo vuoi memorizzarlo nella cache? Come vuoi sincronizzarlo con il database? Ci sono molte altre cose, che devi tenere a mente. Quindi, esaminerò tutte quelle funzionalità su come dovresti usare la cache distribuita come NCache per assicurarti di poter memorizzare nella cache tutti i tipi di dati ma c'è un'API. Sì.

Utilizzo della cache distribuita

Bene. Quindi, ora che abbiamo stabilito che una cache distribuita è importante. Ti offre prestazioni e scalabilità, esaminiamo come si utilizza una cache distribuita e ci sono tre possibili modi in cui è possibile utilizzarla. I tre grandi casi d'uso tecnico.

Memorizzazione nella cache dei dati dell'app

E il numero uno è la memorizzazione nella cache dei dati dell'applicazione, di cui ho parlato finora e ne parlerò presto in modo più dettagliato. Nella memorizzazione nella cache dei dati dell'applicazione, c'è una cosa che devi tenere a mente che i dati esistono nel database e nella cache. Quindi, ci sono due posti in cui i dati esistono, quando i dati esistono in due posti, qual è la cosa più comune che potrebbe andare storta? Potrebbero perdere la sincronizzazione, quindi un cliente potrebbe prelevare quei milioni di dollari due volte dalla banca una volta dalla cache, quelli dal database e quindi non vorresti mai avere quella situazione. Quella situazione era così grave in passato che le persone usavano quando si menziona la parola cache, il pensiero che è venuto alla maggior parte delle persone è che memorizzerò nella cache i dati di sola lettura. I dati non cambiano mai, perché se inserisco nella cache qualcosa che cambia, non potrei potenzialmente avere problemi. Quindi, esaminerò come puoi assicurarti che ciò non accada, ma questa è la cosa più importante da tenere a mente nella memorizzazione nella cache dei dati dell'applicazione.

ASP.NET Core Memorizzazione nella cache specifica

Il secondo caso d'uso è ASP.NET core-caching specifico e ci sono due cose che puoi memorizzare nella cache dall'ASP.NET core. Uno sono le sessioni, che sono praticamente tutti gli ASP.NET core l'applicazione utilizza sessioni e tu nel precedente ambiente ASP.NET, Microsoft ha fornito tre opzioni di archiviazione InProc, server di stato e SQL e la quarta era l'abitudine. I primi tre praticamente non funzionavano ma il quarto ti permetteva di collegare una cache ma in ASP.NET core in realtà hanno fatto la cosa giusta che è che hanno dal codice git, l'hanno effettivamente progettato in modo che sia basato su un'interfaccia IDistributedCache. Quindi, ti consente di collegare un negozio di terze parti e puoi collegare qualcosa del genere NCache e inizia automaticamente a memorizzare le tue sessioni e ti mostrerò come farlo.

La seconda cosa in ASP.NET Core è la memorizzazione nella cache delle risposte, che è l'output della pagina che puoi memorizzare nella cache. Quindi, la prossima volta che viene chiamata quella pagina, la pagina non dovrebbe nemmeno essere eseguita, dovrebbe semplicemente restituire l'output se non è cambiato. Se riprodurrà di nuovo lo stesso output, perché rieseguono o eseguono la pagina? Perché non servire solo l'output, quindi è quello che è stato chiamato il caching dell'output in ASP.NET, ora si chiama caching delle risposte. Ora è basato su più standard HTTP. Quindi, puoi collegare la memorizzazione nella cache di contenuti di terze parti al limite, il che non era possibile, ma approfondirò anche questo. La differenza da tenere a mente tra la memorizzazione nella cache dei dati dell'applicazione e ASP.NET core la memorizzazione nella cache è che, a differenza della memorizzazione nella cache dei dati dell'applicazione, dove c'erano due posti in cui esistevano i dati, ora i dati esistono solo nella cache e poiché la cache è in memoria, questi dati andranno persi se un server della cache si interrompe, a meno che non vi sia la replica . Quindi, questo è un punto molto importante da tenere a mente che qualsiasi cache che non offre una buona replica non è adatta per sessioni di memorizzazione nella cache o altre tendenze nei dati.

C'è un terzo ASP.NET core-cosa specifica che si chiama SignalR, di cui non parlerò, se si dispone di app Web live, che possono fornire feedback in tempo reale, diciamo che i prezzi delle azioni devono essere aggiornati continuamente. Quindi, anche questo può utilizzare una cache distribuita come backplane, ma non l'ho menzionato.

sicurezza

Eventuali domande nelle prime due e andrò più in dettaglio se necessario su queste. Quindi, prima di tutto, la cache vive dietro la tua applicazione. Vive tra l'applicazione e il database. In genere, in un ambiente abbastanza sicuro. Abbiamo clienti che mantengono la cache più vicino, se la loro applicazione è nella DMZ, potrebbero mantenere la cache non nella DMZ ma dietro il firewall. A volte lo tengono nella DMZ, ma la maggior parte delle volte è in una situazione sicura, ma molti dei nostri clienti di servizi finanziari come le grandi banche e altri, non sono soddisfatti di questo, quindi vogliono ulteriori titoli. Quindi, ecco dove l'Enterprise Edition di NCache ha funzionalità, dove può eseguire la crittografia. Quindi, tutti i dati che inserisci nella cache verranno automaticamente crittografati con crittografia come 3DES o AES256 e quindi c'è anche la sicurezza, tutte le connessioni alla cache verranno autenticate tramite Active Directory e ci saranno cose di autorizzazione. Pertanto, le funzionalità di sicurezza complete sono integrate nell'edizione aziendale.

Un cliente medio non utilizza la crittografia a meno che i suoi dati non siano sensibili. Quindi, se stanno conservando i dati finanziari, ci sono alcuni problemi di conformità o HIPAA, quindi se non appena si verificano problemi di conformità, anche se il tuo ambiente è sicuro, devi fare un passo avanti ed è lì che faresti la crittografia . Così, NCache Enterprise, ad esempio, eseguirà la connessione TLS tra il client e il livello di memorizzazione nella cache. Quindi, quella connessione stessa è completamente protetta e hai la crittografia integrata, quindi tutti i dati sono conservati in memoria, sono anche mantenuti in una forma crittografata. E questo soddisfa più o meno, voglio dire che abbiamo molti clienti di servizi finanziari e ne sono totalmente soddisfatti.

NCache può essere distribuito e la maggior parte dei nostri clienti lo utilizza ancora in una situazione locale. Quindi, hanno il proprio data center in cui viene distribuita la loro applicazione, quindi implementano NCache come parte della loro applicazione. Se sei nel cloud, NCache è disponibile sia in Azure che in AWS ed è disponibile come VM o stiamo per avviare anche il servizio di cache gestita, in entrambi i casi, ci assicuriamo che NCache vive all'interno della tua rete virtuale nel cloud. Quindi, in un locale, non è un problema perché sempre nel tuo ambiente, ottieni solo un mucchio di VM o se sei il tuo data center, ottieni i tuoi server e li distribuisci con l'applicazione. Installi tu NCache come software ed è per installazioni interne, puoi anche usare la finestra mobile e hai visto tutte le cose che ti aspetteresti che le applicazioni moderne siano in grado di fare, NCache andrà bene. E poi nel cloud, puoi ottenere le VM o ottenere la cache gestita, ma nel cloud lo faremo sempre all'interno del tuo VPC in caso di AWS e vnet in caso di azure. È all'interno della tua rete virtuale. Quindi, è vicino alla tua applicazione perché se non lo è se devi crescere su più hop, e diciamo se fosse una cache ospitata, il che probabilmente va bene per piccole applicazioni ma qualcosa di serio, NCache viene quasi sempre utilizzato nelle applicazioni mission-critical in cui si svolge la propria attività tramite quell'applicazione. Quindi, è lì che useresti NCache.

Quindi, in quelle situazioni, non puoi permetterti di avere alcun rallentamento e se non puoi permetterti di aver rallentato, è lì che vuoi tutto il controllo e mantenere la cache il più vicino possibile all'applicazione. Dipende dal caso d'uso che intendi fare, quindi, ad esempio, il vantaggio più grande e più rapido sono le sessioni e lo collegheresti immediatamente senza alcuna modifica al codice. È solo una modifica alla configurazione. Nel caso dell'ASP.NET core, non è una modifica alla configurazione. È una modifica del codice del file di avvio, ma solo molto piccola, ma se si desidera eseguire la memorizzazione nella cache dei dati dell'applicazione, è comunque una modifica molto semplice.

Lascia che ti mostri rapidamente come appare l'API. Quindi, guarda questa API.

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");

È solo un piccolo cache.get, cache.add, Inserisci, rimuovi. Quindi, hai una chiave e un valore come oggetto. Quindi, molto facile da incorporare ma devi andare e farlo, quindi ogni volta che ottieni dati dal database controlli prima la cache, se la cache ce l'ha, li prendi dalla cache, oppure vai al database prendilo e lo metti nella cache, questo è il modello. Esattamente. In caso contrario accelererò, non ce la farò. Ti mostrerò NCache Un po piu tardi.

Messaggistica Pub/Sub ed Eventi

Quindi, anche la messaggistica pub/sub è una funzionalità molto potente. Molte applicazioni oggi devono coordinare lo sforzo. Stavo parlando con qualcuno oggi, che ha detto che hanno bisogno di fare molta programmazione basata sugli eventi. Quindi, la messaggistica pub/sub ti offre un modello di programmazione basato sugli eventi molto potente perché hai un'infrastruttura in cui è una piattaforma scalabile in memoria ora all'interno della tua applicazione, puoi pensarla come un bus di messaggistica. Non è per ambienti distribuiti. È per lo stesso data center un tipo di posizione di una situazione, ma è super veloce perché è tutto in memoria ed è scalabile. Quindi, questo è il terzo caso d'uso che avrai per utilizzare una cache distribuita come NCache. Sì, lo fa, lo fa e anche l'open-source lo supporta. Quindi, tutte queste funzionalità sono disponibili sia open source che enterprise, in effetti, tutte le NCache L'API è praticamente la stessa tra open source e enterprise.

Quello che abbiamo visto con pub/sub è di nuovo se hai un'applicazione ad alto traffico, una transazione elevata, allora hai davvero bisogno che il motore pub/sub sia super veloce ed è qui che NCache brilla davvero.

ASP.NET Core Memorizzazione nella cache dei dati dell'app

Bene. Quindi, memorizzazione nella cache dei dati dell'applicazione. Come si fa? Quindi, questo è anche per rispondere lì, quindi ci sono tre modi in cui puoi farlo.

IDistributedCache

È possibile utilizzare l'interfaccia IDistributedCache che ASP.NET core viene fornito con e se hai programmato contro di esso, puoi semplicemente collegarlo NCache come fornitore. Quindi, non ci sono ulteriori modifiche al codice dopo aver effettuato la programmazione dell'API IDistributedCache. Quindi, il vantaggio è che programmi una volta e non sei bloccato in nessun fornitore di memorizzazione nella cache. Lo svantaggio è che è il minimo comune denominatore. Ti mostrerò com'è, ecco tutto. C'è Prendi e metti tutto qui. Sai Ottieni, Rimuovi e Imposta, mentre c'è molto di più che devi essere in grado di fare per sfruttare appieno la cache, che stavamo parlando del fatto che vuoi che la cache sia sincronizzata con il database. Quindi, ci sono pro e contro.

Entity Framework Core Cache

Il secondo è se hai un'applicazione EF Core, hai un'applicazione EF core, è un modo più semplice per collegarsi NCache e te lo mostro. Quindi, abbiamo effettivamente implementato metodi di estensione per EF Core e ancora una volta questo è sia open source che enterprise. C'è l'esempio di EF Core. Bene. Quindi, se avessi un'applicazione EF Core, in genere avresti una query EF Core come questa, in un certo senso recupererai qualcosa usando le query in stile LINQ. Quindi, abbiamo implementato un metodo di estensione, diciamo FromCache, quindi sono un mucchio di metodi, questo è uno di questi quindi questo dirà vai alla cache se questa query è stata memorizzata l'ultima volta nella cache, prendila dal cache. Se non è nella cache, vai al database, esegui questa normale query principale di EF, scaricala e inseriscila nella cache. Quindi, è solo quella riga o solo quella chiamata al metodo che inizia automaticamente a memorizzare nella cache tutti i dati provenienti dal database. Quindi, semplifica il tuo lavoro e sai esattamente dove inserire il plug-in, non ci sono molte chiamate API aggiuntive che devi fare.

Quindi, per le applicazioni principali EF, di nuovo c'è una modifica del codice ma il meno possibile che puoi fare e iniziare a memorizzare nella cache i dati. Quindi, in realtà, per EF core sono un mucchio di metodi, questo è FromCache, ce n'è la maggior parte da, ci sono solo quattro o cinque metodi che puoi usare, FromCache, quindi LoadIntoCache, FromCacheOnly. Quindi, e anche con EF Core, quando salvi le modifiche, aggiorna anche la cache prima o dopo aver aggiornato il database, aggiorna anche la cache. Quindi, la cache ha la versione aggiornata dei dati. L'integrità della cache viene mantenuta prima di tutto assicurandosi che tutti i dati che conservi nella cache e salterò, ad esempio, questo è un server cache. Diciamo che se hai due server e diciamo che hai tre server. L'intera cache è suddivisa in partizioni, ogni partizione ha il proprio set di bucket, quindi i tuoi dati risiedono solo in una delle partizioni. Quindi, e poi quei dati vengono replicati su un altro server, che è chiamato repliche ma le repliche nel caso di NCache non è attivo, è passivo la tua applicazione non comunica con le repliche. La tua applicazione parla solo con la partizione. Quindi, poiché i dati vengono archiviati solo in una posizione, non ci sono problemi di sincronizzazione. Tutti andranno sullo stesso server ma poiché è partizionato, non tutti andranno sullo stesso server, alcune chiavi sono archiviate qui, alcune sono archiviate qui, altre sono archiviate qui.

Quindi, ecco com'è una cache distribuita NCache è in grado di fare ciò che il server SQL non può fare perché la natura del database relazionale è che non puoi partizionare, ma la natura della cache distribuita è che puoi e quando partizioni qui, questi sono tre server, forse sono condivisi da dieci server delle applicazioni e ogni server delle applicazioni può avere quattro o cinque o sei o otto processi di lavoro. Quindi, ci sono molti processi client diversi che comunicano con la cache, non ci sono problemi di sincronizzazione perché i dati effettivi sono archiviati solo in una posizione. Ora ci sono altre topologie in NCache che vengono replicati, laddove esistano gli stessi dati attivo-attivo e multiplo e in tal caso, NCache deve sincronizzare le modifiche. È basato su token, è un algoritmo di aggiornamento basato su sequenze, non è molto scalabile. Quindi, non lo consigliamo per un ambiente con transazioni elevate.

La cache partizionata con replica è la strategia migliore o la chiamiamo una migliore topologia di memorizzazione nella cache da utilizzare. Quindi, ecco come NCache fa in modo che all'interno della cache i dati siano sempre corretti. Questo ha risposto alla tua domanda? Quindi, la porta che hai mostrato, c'è qualche configurazione o impostazione sul codice che dice, da quale cache deve prelevarla? Sì. Quindi, ad esempio, quando vai in app.config, vedrai che dirà che usi mycacheId e ti mostrerò qual è la cache. Quindi, quando crei una cache in NCache. Ogni cache riceve un nome e quel nome dietro la scena sa dove si trova la cache, quindi tutto ciò che devi fare è specificare il nome qui e quindi sa dove andare a prendere la cache. E ti mostrerò come appare effettivamente la cache. Un nome di cache è su tutti quei server e all'interno degli stessi server puoi avere più nomi di cache, sullo stesso server puoi avere più cache e una cache può vivere su più ed è una cache distribuita, un nome di cache deve vivere su più server è così che viene distribuito, ma gli stessi server possono essere utilizzati anche per altri nomi di cache e ogni nome di cache fornisce il suo isolamento. Buona domanda.

Alta disponibilità

Quindi, è qui che stavo dicendo che l'elevata disponibilità è davvero molto importante. Se non sei in grado di aggiungere o rimuovere server in fase di esecuzione senza alcuna interruzione, la tua applicazione non è davvero altamente disponibile. Abbiamo clienti che sono stati in esecuzione NCache per mesi e anni senza interruzioni. Quindi, ad esempio, supponiamo che tu abbia una configurazione a due server e che tu abbia appena aggiunto un terzo server perché il tuo carico è cresciuto. Quindi, devi aggiungere un terzo server, tutto ciò che farai è aggiungere un terzo server e te lo mostrerò solo attraverso lo strumento, basta aggiungerne uno e NCache dietro le quinte si ripartirà. Quindi, queste due partizioni verranno ora trasformate in tre partizioni. Alcuni dei bucket da qui e qui verranno assegnati automaticamente alla terza partizione mentre un'applicazione è in esecuzione, la tua applicazione non se ne accorge nemmeno. Dietro le quinte ora che esiste una terza partizione e ora c'è la replica c'è anche una terza replica che viene creata, quindi diciamo che la replica 2 deve essere spostata qui e la replica 3 viene creata qui.

NCache lo mantiene, dietro questo NCache usa le chiavi per la mappatura hash ma fa tutto in modo dinamico, quindi come una mappa di distribuzione, che è come una mappa di bucket che viene ripartizionata e riassegnata. Quindi, i dati si spostano effettivamente da un server all'altro automaticamente in fase di esecuzione.

Affinità di posizione

Quindi, in alcuni casi, potresti voler tenere insieme alcuni dati sulla stessa partizione. NCache ha una funzione di affinità di posizione, in cui è possibile specificarla e quindi specificarla. Dirai che questi due dati sono correlati, voglio che siano sullo stesso server e poi NCache lo manterrà sullo stesso server tramite una chiave aggiuntiva che crea sopra di esso. Come ho detto, tutte queste sono funzionalità avanzate, che non ottieni se vai solo con il minimo comune denominatore e, usando quelle funzionalità, puoi regolare NCache al tuo ambiente in base alle tue esigenze in particolare.

Funzionalità di memorizzazione nella cache dei dati dell'app

Quindi, la prima cosa che volevo trattare, questi argomenti, sono molto importanti. Per la memorizzazione nella cache dei dati dell'applicazione, la cosa più importante è che la cache sia sempre fresca, il che significa che fresca significa che ha dati corretti, se i dati cambiano nel database, la cache ha i dati più recenti.

Scadenze basate sul tempo

Quindi, la scadenza è il modo più comune con cui le cache lo fanno, quasi tutte le cache hanno la scadenza come funzionalità. NCache ce l'ha anche. C'è una scadenza assoluta e poi c'è una scadenza scorrevole. La scadenza assoluta è, diciamo che stai aggiungendo dati alla cache, puoi dire ok dopo cinque minuti che scadono perché non penso che sia sicuro per te tenerlo nella cache per più di cinque minuti. Quindi, stai facendo un'ipotesi plausibile, che è sicuro conservare i dati nella cache per cinque minuti e che è abbastanza buono per alcuni dati, per altri potrebbe non esserlo.

La scadenza scorrevole è più per quando stai archiviando sessioni e stai dicendo che va bene dopo che nessuno lo sta usando, dopo che tutti hanno finito di usare quella sessione, rimuovila. Quindi, è più una scadenza di pulizia. La scadenza assoluta è la sincronizzazione per mantenerla coerente con il database, lo scorrimento è ripulito, ma la scadenza è un'ipotesi plausibile qualunque sia l'ipotesi sbagliata

Dipendenze dal database

In alcuni casi, puoi permetterti che i dati siano incoerenti, in alcuni casi non puoi. Quindi, se non puoi, devi avere altre funzionalità, quindi ecco dove NCache spicca davvero il fatto che, ad esempio, puoi avere una sincronizzazione della cache con il database. Così, NCache usa la dipendenza SQL incorporata in SQL Server per monitorare SQL Server. Quindi, puoi per ogni elemento memorizzato nella cache, puoi dire ok mapparlo con questa riga corrispondente nella tabella del database SQL, NCache lo monitora, se quella riga cambia, NCache quindi rimuove quell'elemento dalla cache o lo ricarica di nuovo. Quindi, ora improvvisamente hai una cache intelligente, è in grado di assicurarsi che qualunque cosa tu stia memorizzando nella cache sarà sempre coerente e questo è qualcosa che non ottieni se la cache è una scatola nera.

Quindi, devi essere in grado di avere quel tipo di intelligenza con la cache e le dipendenze SQL sono una funzionalità .NET, quindi ecco dove NCache essere .NET aiuta se il tuo database è SQL. Ora, siamo anche una dipendenza da Oracle, che utilizza anche le notifiche del database Oracle e c'è un altro modo per farlo che è la nostra notifica basata sul polling, che è più efficiente ma non è così in tempo reale e quindi puoi anche sincronizzare la cache con fonti di dati non relazionali. I tuoi dati potrebbero essere in a NoSQL database, potrebbe essere nel cloud, potrebbe essere ovunque e tu desideri essere in grado di monitorarlo. Quindi, puoi creare quella che chiamiamo una dipendenza personalizzata, che è il tuo codice che risiede sul server cache. NCache lo chiama a un certo intervallo, va e controlla l'origine dati, se i dati cambiano, notifica NCache, ok i dati sono cambiati per favore rimuovilo o ricaricalo.

Quindi, questa è un'area in cui NCache è davvero molto forte. Se vuoi mantenere i tuoi dati aggiornati, devi essere in grado di fare queste cose per assicurarti che la cache sia fresca.

Read-through e write-through

Un'altra caratteristica è la lettura e la scrittura. Quindi, ora questo è combinato con la scadenza e la sincronizzazione del database. Ciò consente alla cache di caricare i dati dal tuo database ed è così, ad esempio, se hai un read-through, ti mostrerò come appare un read-through. È solo un'interfaccia che implementi e il tuo codice risiede effettivamente nella cache, quindi ecco un'interfaccia per implementare questo codice. Quindi, c'è un carico dalla chiamata sorgente che ti dà una chiave e poi NCache chiama il tuo metodo, il server cache chiama il tuo metodo, questo codice è in esecuzione sui server, su tutti i server cache, NCache chiama questo metodo e dice per favore vai avanti e carica questa chiave perché non è nella cache. Quindi, se eseguo una cache.Get, penso che la chiave non sia nella cache, restituisco un valore nullo, dicendo che la chiave non esiste, o se ho un read-through, posso semplicemente andare nella cache, e NCache può andare al database e leggerlo per te. Quindi, lo avrai sempre. Ora, questo è molto utile in molti casi, in cui vuoi semplicemente mantenere sempre quei dati nella cache.

Quindi, il read-through ti consente, quando combini il read-through con le scadenze o la sincronizzazione del database, ciò che fa è quando i dati scadono NCache può aggiornarlo automaticamente, perché rimuoverlo? Se hai intenzione di ricaricarlo, la prossima volta comunque perché quei dati sono necessari e li stai scadendo solo per mantenerli freschi. Quindi, perché non basta NCache torna indietro e ricaricalo. Se hai implementato il read-through, NCache lo farà automaticamente e succederà la stessa cosa, se i dati cambiano nel database o nell'origine dati e questa funzione di sincronizzazione calcola che là fuori ok quel database è cambiato, se hai implementato la lettura, lo ricaricherà automaticamente .

Allo stesso modo, il write-through ti offre un altro vantaggio che è che se hai un write-behind puoi aggiornare la cache. Quindi, alcuni dati, non sono così sensibili per gli aggiornamenti, ovviamente se si tratta di saldi bancari di dati finanziari non vuoi eseguire il write-behind ma in alcuni casi va bene se puoi semplicemente mettere in coda gli aggiornamenti. Quindi, se aggiorni la cache, aggiornare la cache è molto più veloce dell'aggiornamento del database, ovviamente, più scalabile perché è distribuito e aggiorni la cache e dici NCache per favore vai avanti e aggiorna questo, il database in modo asincrono dietro le quinte. Quindi, questa è la funzione write-behind e che ora accelera improvvisamente la tua applicazione perché qual è il collo di bottiglia? Legge dal database e scrive nel database. Letture che puoi memorizzare nella cache, in modo da non andare nemmeno al database ma le scritture devono andare al database, non puoi significare che il database è il master giusto, quindi non c'è modo di girarci intorno ma di tipo write-behind È facile.

Quindi, questa è un'altra caratteristica che se ce l'hai, NCache improvvisamente ti dà ulteriore spinta nella tua applicazione. Domanda: quindi, per ogni evenienza, non è in grado di scrivere nel database e fare in modo asincrono, genererà un'eccezione? Sì. Genererà un'eccezione, puoi avere una richiamata che viene chiamata da NCache e di nuovo il codice è che questo codice write-behind è in esecuzione sui server cache ma il callback è qui, quindi avviserà il client e verrà chiamato il tuo callback, quindi puoi intraprendere azioni correttive. Una volta che ti sarai abituato a quella cache, NCache puoi sincronizzare la cache con il database, memorizzerai nella cache sempre più dati. Più dati si memorizzano nella cache, più la cache inizia a sembrare un database, il che significa che un modo per recuperare i dati basato su valori chiave non è abbastanza intelligente. Quindi, devi essere in grado di trovare i dati basati su SQL, in particolare i dati di riferimento.

Ricerca SQL

Quando abbiamo parlato della query EF Core che stai recuperando i dati in base agli attributi, non solo alla chiave. Quindi, se sei in grado di cercare i dati con query SQL o LINQ o con EF core, la cache è molto più veloce. Questo è un altro modo NCache spicca è che una volta inseriti tutti quei dati nella cache, puoi cercare, puoi dire dammi tutti i miei clienti che hanno sede a Boston o New York e ti darà una raccolta di oggetti cliente dalla cache. Quindi, sta iniziando a sembrare più simile a un database e stai togliendo tutta quella pressione da quel database, specialmente per i dati di riferimento. Quindi, la ricerca SQL è davvero molto importante.

Bene. Ora voglio mostrarti cosa NCache sembra o sembrerebbe una cache? Quindi, ho effettuato l'accesso ad Azure. Quindi, ho due VM del server cache. quindi, ho due server cache, un client Windows e una linea Linux perché c'è .NET Core, potresti eseguire l'applicazione su Windows o Linux e NCache funziona in realtà, i server cache possono anche essere eseguiti su Linux a causa di .NET Core perché NCache Europe è .NET Core nativo.

Crea una cache

Quindi, ad esempio, ho eseguito un desktop remoto sul client Windows. In realtà andrò avanti e creerò una cache, quindi la mia cache avrà due server e avrò un client Windows, un client Linux e quando userò la parola client che in realtà è il tuo server delle applicazioni. Bene. Quindi, userò questo NCache strumento di gestione. Ora questo strumento fa parte dell'Enterprise Edition ma puoi fare tutte le stesse cose tramite gli strumenti da riga di comando open source o i file di configurazione, ma solo per motivi di praticità, andrò avanti e creerò una cache.

Chiamerò la mia cache democache come ho detto che tutte le cache hanno un nome.

Sceglierò una topologia. Sceglierò la cache partizionata con la replica.

Eseguirò la replica asincrona, quindi c'è una replica asincrona e una replica asincrona. La replica di sincronizzazione è quando non puoi permetterti di eseguire la sincronizzazione se si tratta di dati più sensibili, dati finanziari e cose in cui desideri che queste repliche avvengano come parte dell'aggiornamento, il che ovviamente rallenta le cose ma le rende di più.

Quindi, ecco il mio server cache uno, ecco il mio server cache due, quindi ho appena creato un cluster a due server. non è ancora in esecuzione. Aggiungerò due nodi client. Questa è la mia finestra, c'era un server. Quindi, 6 è il mio client Windows e 7 è il mio client UNIX. Bene. Quindi, di solito ho due server cache e due client, come ho detto avrai un minimo di due server cache e un rapporto di quattro a uno, cinque a uno tra i client e il server. Quindi, sto solo avviando la cache ora. Ancora una volta, da un posto, posso fare tutto questo e lo stesso nella prossima versione che stiamo per lanciare, è tutto basato sul Web, quindi nel cloud, puoi farlo. Apro le statistiche e queste sono come il monitoraggio, queste sono statistiche perfmon.

Simula lo stress e monitora le statistiche della cache

Proverò e vedrò se il mio cliente è in grado di parlare con questo, ora questa scatola è un cliente. quindi, aprirò la console di PowerShell. Avrò due parziali da Windows e ho effettuato l'accesso a due Linux qui, quindi ho un Linux qui, ora il Linux qui. Giusto? Qui, devo avviare PowerShell e qui, devo anche importare il mio modulo che non devo fare per Windows, è già lì per me e devo fare lo stesso qui. Devo avviare PowerShell su Linux e ok ora avvierò un client. Così, NCache viene fornito con questo strumento di stress test, che rende davvero facile lo stress test nel tuo ambiente. Quindi, puoi vedere esattamente come NCache esegue? Quindi, non devi prendere una parola per le sue prestazioni. Quindi, diciamo qui, sto facendo circa 500 richieste al secondo per server.

Bene. Quindi, voglio aumentare il carico, quindi andrò sulla seconda console e dirò di eseguire nuovamente uno stress test.

Ora, all'improvviso vedrai che questo salterà raddoppiato, giusto, e lasciami andare avanti e aggiungere più stress. Verrò su uno di quelli Linux e dirò la stessa cosa e improvvisamente ora sono più come 1500 per richiesta. Quindi, ora ho un totale di circa 3,000 richieste al secondo come se ne facessi un'altra e ora ne sto facendo più come 4,000 richieste al secondo. Quindi, posso continuare ad aggiungere sempre di più se ho più VM, posso o posso semplicemente avere più istanze e vedrai che molto presto una volta, raggiunge il massimo di qualunque cosa sarà e questi due server dovrebbero essere in grado di gestire almeno 50,000 richieste al secondo, ma ancora una volta è con il piccolo set di dati, man mano che le dimensioni dell'oggetto aumentano, ovviamente diminuirà, ma una volta raggiunto il massimo, andrò avanti qui e ancora questo è funzionando bene, non ho una terza VM ma tutto ciò che devo fare è semplicemente farlo e aggiungere un terzo indirizzo e dirò finito e aggiungerà una terza casella qui e farà tutto quel partizionamento o ripartizionare automaticamente per te.

Allo stesso modo, se ho bisogno di abbattere una qualsiasi delle VM, lo farà anche. Sì, ecco, questa è la fine del mio discorso. Possiamo rispondere a qualsiasi domanda? È l'unica soluzione .NET nativa, l'unica altra soluzione nativa era AppFabric che è stato interrotto. Così, Redis non è una soluzione .NET anche se Microsoft l'ha scelta per Azure perché volevano essere indipendenti dalla tecnologia, quindi l'hanno scelta ma siamo .NET nativi. Siamo stati così dal primo giorno e per quanto ne sappiamo siamo la scelta preferita per .NET.

NCache Dettagli

Confronto edizione

Scaricare NCache