Campo di codice .NET di Philadelphia

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

L'argomento di oggi è come ottimizzare l'ASP.NET core prestazione. Preferisco avere discussioni più interattive, quindi, mentre sto parlando, se avete domande, alzate la mano in modo che possiamo ottenere. Quindi, sono sicuro che sei qui perché l'ASP.NET core è ora la tecnologia popolare per lo sviluppo di nuove applicazioni .NET o applicazioni Web .NET perché ha un'architettura pulita e leggera. Probabilmente sei già su MVC da ASP.NET. Quindi, in tal caso, passare a un ASP.NET core sarà abbastanza facile. ASP.NET core è leggero. È multipiattaforma, è open source e c'è un'enorme base di utenti ASP.NET legacy che lo rende un caso molto probabile che la maggior parte di voi ragazzi passerà ad ASP.NET Core.

Quindi, ASP.NET core in futuro sarà la scelta, la scelta tecnologica per .NET, per lo sviluppo di applicazioni web ad alto traffico o applicazioni server e applicazioni web ad alto traffico. Ciò significa ASP.NET core ha bisogno di scalabilità e sono sicuro che è per questo che sei qui. Cerchiamo di capire le definizioni prima di approfondire.

Che cos'è la scalabilità?

Cos'è la scalabilità? La scalabilità significa essenzialmente che se hai un'applicazione con cinque utenti e offre tempi di risposta super veloci e buoni, puoi mantenere lo stesso tempo di risposta, le stesse prestazioni con cinquemila o cinquantamila o cinquecentomila utenti, utenti simultanei quindi la tua applicazione è scalabile. Se la tua applicazione non funziona bene con cinque utenti, allora questo non è il discorso per te, ne hai altri, probabilmente devi guardare il modo in cui stai accedendo al tuo database e stai facendo la tua programmazione generale. Questo presuppone che tu abbia fatto un buon lavoro, sviluppando un'applicazione per almeno pochi utenti e quindi devi sapere come ridimensionarla.

Che cos'è la scalabilità lineare?

La scalabilità lineare significa che puoi aggiungere più server in produzione e man mano che aggiungi più server, puoi aggiungere in modo lineare la capacità di transazione.

Ora entrerò più nel dettaglio, ma quello che succede è, diciamo che inizi con il carico di due server web farm bilanciato. Dopo un certo numero di utenti, quei due server raggiungeranno il massimo e le tue prestazioni inizieranno a rallentare, quindi aggiungi il terzo server e improvvisamente la capacità dovrebbe aumentare di almeno un terzo o qualunque sia la nuova formula e quindi quando vai quando raggiungi il massimo di tre server, sicuramente aggiungi di nuovo incrementale. se sei in grado di farlo, hai un'architettura dell'applicazione scalabile linearmente. Se non sei in grado di farlo, hai un non lineare.

Che cos'è la scalabilità non lineare?

Non lineare fondamentalmente significa che dopo alcuni server, l'aggiunta di più server non farà alcuna differenza perché c'è un collo di bottiglia nell'applicazione che ne impedisce il ridimensionamento. Quindi, le tue prestazioni in realtà diminuiranno man mano che aggiungi più carico e parli nella misura in cui la tua applicazione potrebbe persino arrestarsi in modo anomalo. Quindi, sicuramente non vuoi una scalabilità non lineare che in pratica significa che dopo un certo punto non c'è scalabilità.

Quali app necessitano di scalabilità

Quindi, quale tipo di applicazioni necessita di scalabilità? Queste sono tutte applicazioni server. Queste sono le tue applicazioni web che hanno l'ASP.NET core servizi web, sempre ASP.NET core. Se sviluppi in microservizi, i microservizi stanno diventando una grande parola d'ordine ora e poiché puoi eseguirli in contenitori e in ambienti containerizzati, puoi eseguire anche ASP.NET core in un ambiente containerizzato, ma i microservizi sono un altro ottimo caso d'uso per la scalabilità o qualsiasi altra applicazione server in cui si elaborano molte transazioni sul back-end.

Quindi, se si dispone di uno di questi tipi di applicazioni, di solito si tratta di applicazioni rivolte al cliente, rivolte all'output o almeno fanno parte dell'applicazione rivolta all'output. Diciamo che se la tua applicazione di servizi Web, potresti far parte di un'applicazione Web generale e c'è un livello di servizi Web e lo stesso vale con i microservizi, ma in genere sono applicazioni rivolte ai clienti o all'output, ma non sempre. Se sei una grande azienda, potresti avere decine di migliaia di utenti interni ma la maggior parte delle volte sono cose esterne.

Il problema e la soluzione della scalabilità

Quindi, c'è un problema di scalabilità ed è per questo che stiamo avendo questa conversazione oggi e il problema di scalabilità non è nel livello dell'applicazione. Pertanto, se si dispone di un ambiente con bilanciamento del carico, il livello dell'applicazione viene ridimensionato in modo molto lineare. Puoi aggiungere più server, nessun problema. È il database o l'archiviazione dei dati. Qualsiasi tipo di dati che stai archiviando potrebbe essere i dati della tua applicazione, che potrebbero essere le tue sessioni, che potrebbero essere qualsiasi altro dato che stai archiviando o recuperando che diventa un collo di bottiglia ed è per questo, è uno dei motivi per cui NoSQL databaseha guadagnato popolarità.

NoSQL Database

Il problema con NoSQL databases è che richiedono che tu ti allontani dai database relazionali. Quello che abbiamo visto che per molte situazioni, lasciami dire nella maggior parte dei casi, puoi usarlo NoSQL databases per alcuni dati, ma molti dati devono ancora risiedere nei database relazionali. Quindi continuerai a usare SQL Server o il database SQL in Azure. Quindi, è necessario risolvere questo problema di scalabilità con i database relazionali. NoSQL databases non sono sempre la risposta perché non puoi usarli, non puoi sostituire un database relazionale con a NoSQL database sempre. E, se non puoi sostituirlo, se non puoi usarlo, non puoi trarne vantaggio. Anche se potessi usare un NoSQL database, continuano a non fornire le prestazioni fornite dalla cache distribuita in memoria. Quindi, avresti ancora bisogno di molte delle cose di cui sto parlando.

Quindi, vediamo cosa succede effettivamente e lasciami entrare davvero nel merito. Il problema della scalabilità è qualcosa che non vuoi davvero aspettare finché non accada. Perché se stai sviluppando un'applicazione e dici cosa sta funzionando bene oggi e va bene per un migliaio di utenti o qualunque sia il numero di utenti che hai e improvvisamente la tua attività inizia a diventare popolare, hai molti più clienti in arrivo. Sei marketing o il tuo dipartimento aziendale ha fatto un buon lavoro e improvvisamente la tua applicazione inizia a rallentare ed è stato documentato attraverso studi che rallentano ogni secondo, un'applicazione web si traduce in una perdita di entrate. Poiché i tuoi clienti in molte di queste attività online, i tipi di attività online sono le attività di e-commerce, le attività di vendita al dettaglio con negozi online, questo potrebbe essere l'assistenza sanitaria, l'e-government, i social media, il gioco d'azzardo online, l'industria dei viaggi. Molte aziende stanno andando online perché qualsiasi azienda che ha a che fare con consumatori che condurrà affari con loro. Questi sono consumatori o decine di migliaia, di solito vanno online con loro. E online non è sempre un'applicazione Web, potrebbe anche essere un'applicazione di servizi Web perché potresti avere un'applicazione mobile che parlerà con un back-end.

Quindi, non è una buona idea aspettare fino a quando non hai problemi di scalabilità perché in tal caso sarà molto costoso per la tua azienda. Queste applicazioni rallenteranno poiché hai visto che la curva non lineare in quel momento l'aggiunta di più servizi non aiuta. Quindi, è necessario pianificarlo in anticipo. Assicurati che l'architettura dell'applicazione sia corretta e che ne tragga vantaggio. È quasi come una cosa obbligatoria come best practice per te incorporare una cache distribuita nell'architettura dell'applicazione.

Caching distribuito

Quindi, in che modo aiuta una cache distribuita? lo userò NCache come esempio qui e NCache è una cache distribuita open source per .NET. Puoi trovarlo su GitHub e puoi anche trovarlo sul nostro sito Web e c'è anche Enterprise Edition. Quindi, se non hai i soldi o non hai il budget, scegli l'open source. Se desideri una versione più supportata con alcune funzionalità in più rispetto all'open source, scegli Enterprise. Quindi, userò NCache come l'esempio ma non sto parlando NCache. Sto parlando della memorizzazione nella cache in generale. Quindi, in che modo aiuta una cache distribuita? Bene, diciamo in caso di NCache crea un cluster di due o più server così come puoi vedere questo livello intermedio che è un livello di memorizzazione nella cache avrà due e questi due server e forse più di due a seconda di quanti server hai qui? Quanto carico hai qui?

Quindi, quando non hai una cache distribuita, il database è solo un server che non puoi davvero distribuire un database relazionale. Voglio dire, i database relazionali di SQL Server stanno cercando di migliorare le loro prestazioni. Ad esempio, ora hanno nelle tabelle di memoria. SQL ha anche repliche di sola lettura del database. Quindi, le letture possono essere replicate, ma il problema con le repliche è che ogni aggiornamento è molto più lento perché ogni volta che si aggiorna verrà aggiornato in cinque o quattro posizioni. Quindi, non è il modo ideale per risolvere questo problema. C'è un modo migliore che è la cache distribuita e il motivo per cui una cache distribuita è scalabile è la parola distribuita e il motivo per cui può essere distribuito è perché è un archivio di valori chiave. Tutto è memorizzato in base a una chiave. La chiave può essere facilmente mappata tramite hash in più partizioni e ogni partizione è un server ed è così che si ottiene la distribuzione.

Quindi, hai un minimo di due server cache, una configurazione tipica che vediamo è di circa 16-32 gig per server come memoria perché, ancora una volta, è un archivio in memoria, quindi devi avere molta memoria. E forma un cluster, è un cluster basato su TCP che estrae questa memoria e CPU come risorsa del cluster. Quindi, supponiamo che tu abbia iniziato con un'applicazione Web chiara con 4 o 6 server Web, quindi avrai 2 server cache e diciamo da 16 a 32 gig di memoria e ora inizi a ottenere sempre di più e l'80% delle volte che vai nella cache, il 20% andrai al database per gli aggiornamenti. Potrebbe anche essere inferiore al 20% dipende da quanti aggiornamenti stai facendo. Per alcuni dati gli aggiornamenti sono più degli altri, ma diciamo ancora, qui aggiungerai più server al livello dell'applicazione e farà di nuovo ciò che ha fatto al database. Al massimo il livello di memorizzazione nella cache. Quindi, hai solo 2 server. Supponiamo che tu abbia raggiunto circa 8 server nella web farm quassù. Perché come ho detto, quando hai più utenti hai più servizi applicativi. Quindi, questo raggiungerà il massimo. Non appena raggiunge il massimo, abbiamo aggiunto il terzo server. E questi non sono server di fascia alta. Questi sono server a basso costo.

Di solito, un server tipico è di circa 8 core. Se ottieni più di 30 giga di RAM, dovresti passare a 16 core perché più RAM hai più garbage collection che deve fare perché non è una cosa di memoria gestita e quindi hai bisogno di più potenza di elaborazione. Tuttavia, consigliamo alla maggior parte dei nostri clienti, e ancora una volta questi consigli si applicano anche all'open source, consigliamo ai nostri clienti di andare tra 16 e 32 giga di RAM per server. Basta aggiungere più server invece di ottenere pochi servizi davvero di fascia alta per aggiungere più server. Quindi, quando due server sono al massimo, aggiungine un terzo e succede la stessa cosa, puoi aggiungerne un quarto o un quinto e probabilmente non raggiungi mai il massimo perché qualunque sia la capacità di transazione di cui hai bisogno, diciamo se hai 20,000 30,000 utenti simultanei, questo è praticamente nella fascia alta della maggior parte delle applicazioni web, voglio dire che potrebbero essercene alcune che sono di più forse potrebbero esserci più di centomila utenti simultanei, ma se hai 20,000 utenti simultanei significa che probabilmente milioni di persone visitano il sito web ogni giorno . Quindi, voglio dire, stiamo parlando di quella scala.

Quindi, per questo motivo, ora improvvisamente il database non è più il collo di bottiglia. I dati dell'applicazione di memorizzazione nella cache... Quindi, è una cache comune. È una cache condivisa. Quindi, quando metti qui questa cache, poiché è una cache in memoria, in memoria significa che se un server della cache si interrompe, perderai dati. Quindi, ciò significa che la cache deve fornire una replica intelligente ma NCache fa per assicurarsi che se un server si interrompe, un altro server ha una copia di quei dati, ma se si creano troppe copie, ciò rallenta anche l'intera operazione. Così, NCache fa solo una copia dei dati e si partiziona. Ogni partizione ha il backup su qualche altro server e quindi non appena un server si interrompe, le partizioni ne fanno un'altra copia. E, avendo una cache condivisa, ora queste scatole diventano stateless. Stateless significa che non ci sono dati archiviati nel livello dell'applicazione.

Quindi, quello che dovresti fare quando puoi raggiungere l'obiettivo che il tuo livello dell'applicazione è senza stato, il che significa che puoi disattivare qualsiasi server delle applicazioni senza causare alcuna interferenza. Diciamo che devi applicare una patch, una patch del sistema operativo o un aggiornamento dell'applicazione o qualcosa che puoi semplicemente continuare ad applicarlo qui perché tutti i dati sono nel database o in questo livello, quindi possono essere facilmente corretti.

Casi d'uso della cache distribuita

Quindi, ora che abbiamo stabilito il motivo per cui dovresti usare la memorizzazione nella cache, qual è il vantaggio? Che problema risolve e come risolve quel problema. La prima domanda è per cosa lo usi? Quali sono i casi d'uso? In quale punto dell'applicazione utilizzi una cache distribuita?

Memorizzazione nella cache dei dati dell'app

Il numero uno è la memorizzazione nella cache dei dati dell'applicazione. Questo è il caso d'uso di cui ho già parlato, ovvero che hai un database che ha i dati dell'applicazione che metti nella cache questi dati nella cache in modo da non dover andare al database. Ora, c'è una cosa che devi tenere a mente e tornerò su questo che nella memorizzazione nella cache dei dati dell'applicazione, i dati hanno due copie, una è nel master che è il database e una è nella cache. Ogni volta che hai quella situazione in cui i dati risiedono in due posti, cosa potrebbe andare storto? Sì, le due copie potrebbero diventare incoerenti o non sincronizzate, il che significa che la cache potrebbe diventare obsoleta. Quindi, qualsiasi cache che diventa ancora ti costringe a memorizzare nella cache solo dati statici, dati di sola lettura. E i dati di sola lettura rappresentano solo il 20% dei tuoi dati totali. L'80% è ciò che chiamiamo dati transazionali. Se non riesci a memorizzare nella cache i dati transazionali, quella cache ti limiterà ed è qui che NCache ha alcune funzionalità davvero potenti e ancora tutte open source, tutte funzionalità davvero potenti che ti aiuteranno ad assicurarti che la cache rimanga sempre aggiornata. Va bene e andrò in quel momento.

ASP.NET Core Memorizzazione nella cache specifica

Il caso d'uso numero 2 è che ancora una volta la memorizzazione nella cache dei dati dell'app è per ASP.NET core e anche altre applicazioni ma per ASP.NET core, ci sono almeno altri due usi, uno è le sessioni che puoi ripristinare la tua sessione in una cache distribuita come NCache e non è necessaria alcuna programmazione per farlo, quindi è davvero molto veloce. Se vuoi ottenere il vantaggio più rapido in termini di prestazioni per la tua applicazione e diciamo che la tua applicazione è già attiva o è completata, questo inizia a mostrare le tue sessioni nella cache distribuita come NCache. E, poiché non c'è programmazione, ci sono pochissimi test che devi fare se devi fare, ovviamente alcuni test di sanità mentale di base per assicurarti che tutto funzioni nel tuo ambiente, ma non ci sono sforzi di sviluppo coinvolti. per questo motivo non sono coinvolti programmi di sviluppo e programmi di rilascio in questo. Quindi, molto molto veloce.

Il secondo ASP.NET core la memorizzazione nella cache specifica è il memorizzazione nella cache delle risposte che in ASP.NET era chiamato cache di output, in ASP.NET core in realtà lo hanno reso più basato sugli standard. Quindi ora utilizza le direttive di memorizzazione nella cache basate su HTTP che possono essere comprese da soluzioni di memorizzazione nella cache perimetrale di terze parti, ma essenzialmente stai memorizzando nella cache l'output di una pagina, quindi la prossima volta che viene chiamata quella pagina, se l'output sarà lo stesso, perché eseguire la pagina? Perché non fornire semplicemente l'output? Ora, questo è un bene in quelle situazioni in cui l'output non cambia molto frequentemente che sono molti casi, ma se hai un'applicazione che è molto dinamica, probabilmente non avrai un contatto molto statico, ma anche se puoi averlo per un breve periodo che ti salva comunque. Quindi, ASP.NET core la cache di risposta ha un concetto di middleware e puoi collegare una cache distribuita come NCache come middleware che vive sostanzialmente sullo stesso livello dell'ASP.NET core oppure è lo stesso, ma la cache del middleware potrebbe essere qui ed ecco l'ASP effettivo.NET core applicazione. Quindi, questo è il secondo caso d'uso comune più grande per la memorizzazione nella cache distribuita e entrerò un po 'più in dettaglio di questi, ma ti sto solo dando una panoramica.

Messaggistica Pub/Sub ed Eventi

Il terzo caso d'uso è qualcosa che molte persone non sanno su quale è che puoi fare messaggistica pub/sub ed eventi con una cache distribuita. La messaggistica Pub/Sub consente a più applicazioni o a più istanze dell'applicazione di coordinare il lavoro tra loro condividendo le informazioni sui dati in modo asincrono basato sugli eventi. Quali sono alcuni degli esempi che potremmo collegare a questo? I microservizi, ancora una volta, i microservizi sono servizi disaccoppiati indipendenti ma devono essere coordinati. Voglio dire, un microservizio potrebbe produrre qualcosa che viene utilizzato da altri microservizi, ecco come verrà eseguito il flusso di lavoro, ma non vogliono dipendere l'uno dall'altro direttamente, altrimenti l'intero modello si interrompe. Quindi, quello che fai è pensare a questo come non più una cache per il tuo database, ma pensa a questo, e in realtà lo farò .. dammi un secondo, lo farò girare solo per una foto, pensa a la cache distribuita ora come piattaforma di messaggistica.

Quindi, l'intero cambio di paradigma è che ora hai le applicazioni. Potrebbero trattarsi di più macchine virtuali o contenitori che eseguono i microservizi o qualsiasi altra applicazione e possono comunicare tra loro in modalità pub/sub. Quindi, ci sono argomenti e quindi ci sono editori e abbonati e questo semplifica davvero la tua applicazione.

Ora ci sono altre soluzioni Pub/Sub come i requisiti di accodamento della messaggistica Rabbit e MSMQ. Cosa c'è di così speciale in una cache distribuita NCache? Perché dovresti usare questo su quello? Il motivo per l'utilizzo di una cache distribuita è perché questo è molto molto veloce. È tutto nella memoria. Non ha tutte le caratteristiche che avrà una coda di messaggi perché saranno anche persistenza e memorizzeranno i messaggi per lunghi periodi di tempo ma in molte situazioni non è necessario conservarli per così tanto tempo se tutto è in esecuzione all'interno lo stesso data center ed è davvero un ambiente transazionale, ma lo stai utilizzando di più per il flusso di lavoro, quindi la replica è più che sufficiente. Il fatto che tu abbia tutti i dati conservati su più di un server è più che sufficiente per assicurarti che i tuoi messaggi non vadano persi. Quindi, a differenza della memorizzazione nella cache dei dati dell'applicazione in cui c'erano due copie dei dati, quindi la natura del problema era diversa, è necessario mantenere la cache fresca. Nel secondo e nel terzo caso è l'opposto, c'è solo una copia dei dati che è la cache. Quindi, ora all'interno della cache deve esserci più di una copia coerente ai fini della replica perché se non lo hai, la cache in memoria perderà i tuoi dati. Quindi, non vuoi perdere i tuoi messaggi, le tue sessioni e l'output della tua pagina solo perché una volta che il server è inattivo. Quindi, la messaggistica Pub/Sub negli eventi di solito è un caso d'uso davvero potente per una cache distribuita e di nuovo tutto questo è open source.

Quindi, c'è un'altra caratteristica NCache chiamata query continua che in realtà nessun'altra cache spaziale .NET ha, alcune cache Java ce l'hanno e una query continua ti consente di specificare un tipo SQL di query sulla cache, quindi, ad esempio, potresti dire qualcosa come select clienti in cui customer.city è New York e dici che sono interessato a questo caso, quindi stai chiedendo alla cache, puoi monitorare questo set di dati. Così. qualsiasi oggetto cliente con questo attributo, mai aggiunto, aggiornato o eliminato dalla cache, si prega di avvisare. Quindi, ora non devi guardare tu stesso ogni oggetto che non puoi comunque o è da controllare, la cache lo farà per te. È simile a come SQL Server nella dipendenza SQL. Puoi chiedere al tuo server di monitorare il set di dati e avvisarti quando quel set di dati cambia. Tranne che è una o più righe in una tabella, ma qui sono oggetti in una cache distribuita. Quindi, questi sono i tre casi d'uso comuni.

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

Quindi, penso che il caso d'uso più comune sia la memorizzazione nella cache dei dati dell'applicazione. In realtà, la parola cache distribuita è più una parola dell'ecosistema Microsoft. Sul lato Java, è chiamato in memory data grid. Usiamo tre parole. Usiamo la cache distribuita, usiamo la griglia dei dati in memoria per il vantaggio web della gente Java, anche se siamo nell'ecosistema Microsoft. Quindi, non siamo così tanto e poi c'è l'archivio dati in memoria distribuito. Quindi, la memorizzazione nella cache dei dati dell'applicazione è il caso d'uso della memorizzazione nella cache distribuita.

Interfaccia IDistributedCache

Quindi, se hai intenzione di utilizzare la memorizzazione nella cache dei dati dell'applicazione, ci sono tre modi per farlo. C'è un'interfaccia IDistributedCache ed è disponibile in ASP.NET 4 che è sostanzialmente simile a questa qui.

Interfaccia molto semplice. Microsoft ha finalmente fornito un'interfaccia che ti consente di collegare qualsiasi cache distribuita sottostante. L'unico problema con questo è che è davvero molto semplice. Quindi, non puoi fare molto attraverso questo. Puoi solo fare davvero di base. E l'unica cosa che fa è che ti dà scadenze. È possibile specificare l'opzione di immissione della cache quali sono le scadenze. Quindi sì! NCache implementa questo, quindi se stai programmando tramite l'interfaccia IDistributedCache puoi semplicemente collegarti NCache senza alcuna modifica al codice, qualsiasi ulteriore modifica al codice e hai fatto la programmazione ma non consiglierei di farlo perché se vuoi davvero attingere a una cache distribuita e al vantaggio, allora vuoi capire cosa tutte le altre caratteristiche? Perché non dovresti usarli? Ora andrò con Quello.

Entity Framework Core Cache

Un altro è se stai facendo EF core, di nuovo, se vuoi ridurre al minimo il codice che vuoi scrivere, NCache presente provider di metodi di estensione di base EF, lascia che te lo mostri rapidamente. Quindi, i metodi di estensione di base di EF semplificano davvero il modo in cui useresti la cache. Ancora una volta, proprio come IDistributedCache, le funzionalità non sono così estese.

Quindi, ad esempio, supponiamo che tu voglia vedere la tua tipica query basata su EF Core o EF LINQ, quello che abbiamo fatto è che abbiamo implementato un metodo di estensione della cache della farm e ci sono altri metodi di estensione, non appena dici che quando dietro la squadra questa query verrà prima esaminata e nella cache. Se la cache ce l'ha, lo otterrai dalla cache, altrimenti andrai al database, lo prenderai e lo metti nella cache prima che te lo dia. Quindi, semplifica un po' la tua programmazione. Se è qualcosa che desideri, supponiamo che tu abbia già un'applicazione principale EF e desideri collegarla il più rapidamente possibile, questo è il modo più veloce per ottenere NCache lì dentro come puoi vedere questo è.

NCache API

La terza opzione è usare NCache API che è anche un'API abbastanza semplice. NCache L'API sembra quasi identica all'oggetto ASP.NETcache ma più di quello che abbiamo provato ma siamo usciti molto tempo fa. ASP.NET Core è l'unica interfaccia per l'oggetto in circolazione, quindi abbiamo cercato di mantenerla il più vicino possibile.

Quindi, è un concetto semplice, ti connetti alla cache, ottieni un handle della cache, fai un cache.get, c'è un indice o dimentica, puoi fare contiene, aggiungi, inserisci, rimuovi e sono versioni Async di questi in modo da non dover attendere l'aggiornamento della cache. Ci sono ovviamente più di questo. Quindi, questo tipo di ti dà un'idea di quanto sia semplice usare una cache.

Funzionalità di memorizzazione nella cache dei dati delle app: mantieni la cache aggiornata

Ora, la cosa principale a cui volevo arrivare era questa pagina. Sì, credo di averti detto che ci sono due copie della cache. Se la cache non è in grado di mantenersi aggiornata, limiterai davvero l'uso. È molto importante da capire. Cosa fanno le cache?

Scadenze (assoluta + scorrevole)

La maggior parte delle cache fornisce le scadenze. La scadenza è anche chiamata TTL, Time to live, la chiamiamo scadenza assoluta perché è lì che l'oggetto cache ASP.NET usa quel termine, quindi l'abbiamo mantenuto. Che cosa fa? Stai aggiungendo un oggetto alla cache, stai dicendo di scadere tra cinque minuti o tra dieci minuti perché penso che sia sicuro memorizzarlo nella cache per così tanto tempo. Stai facendo un'ipotesi plausibile che va bene in alcuni casi di dati di riferimento. Ad esempio, hai un catalogo di prodotti. Probabilmente non cambierà ogni 10 minuti. Il prezzo non cambierà lì dentro. Quindi, sono cambiamenti più prevedibili per alcune situazioni. Quindi, va bene usare le espressioni lì. Ma se stai memorizzando nella cache un cliente o un'attività, non sai quando cambierà perché i clienti chiameranno e apporteranno alcune modifiche, quindi potresti non essere in grado di vivere solo delle scadenze. Quindi, è qui che hai bisogno di altre funzionalità nella cache ed è qui che tutte queste funzionalità si trovano nella cache NCache come Open Source.

Sincronizza la cache con il database

Una delle caratteristiche è il NCache può sincronizzarsi con il database. Ora il database può essere SQL Server, potrebbe essere Oracle o potrebbe essere OLEdb in caso di polling ma la sincronizzazione significa che NCache diventa un client, il server cache diventa un client del database. Ora utilizzerà la dipendenza SQL di cui stavo parlando. La stessa cosa di una query continua ma per SQL Server. Utilizzerà una dipendenza SQL e ti mostrerò come funziona.

Quindi, diciamo... Quindi, quando aggiungi, diciamo che stai aggiungendo questo oggetto prodotto alla cache, quindi hai una chiave e hai l'elemento cache che contiene il prodotto. Quello che vuoi fare è specificare un'istruzione SQL che identifichi un prodotto specifico nella tabella del prodotto e ancora questa istruzione SQL è per SQL Server. Stai passando la cache degli eventi, NCache lo passeremo al server SQL. NCache, quando memorizza nella cache questo prodotto, ora notificherà a un registro con SQL Server una dipendenza SQL e manterrà la mappatura. Quindi, se SQL Server invia un evento a NCache dicendo che questo prodotto è stato aggiornato nel database ora NCache sa che è ancora nella cache. Quindi, farà una delle due cose. devi solo rimuoverlo dalla cache. Voglio dire che la tua applicazione non deve fare nulla, è tutto fatto dalla cache o se hai implementato questa funzione chiamata read-through, ricaricherà automaticamente l'elemento. Quindi, verrò al database tra un po'. Quindi, la sincronizzazione del database è una funzionalità molto molto potente. Ti dà la massima tranquillità e memorizza nella cache tutti i dati. Senza il quale, se stai solo facendo le tue esplorazioni, sei limitato ed è così brutto che se parli con una persona normale che conosce la memorizzazione nella cache in modo semplice reagirà alla memorizzazione nella cache, "oh, questo è per i dati di sola lettura". La memorizzazione nella cache è solo per i dati statici. Tutti hanno paura di toccare i dati transazionali e questo a causa di queste cose, perché le scadenze non sono altro che un'ipotesi plausibile, che può essere valida per casi più prevedibili come il catalogo prodotti e altri, ma non è valida per i dati transazionali.

Sincronizza cache con non relazionale

Quindi, lo stesso problema se hai un datastore non relazionale. Potrebbe essere qualcosa nel cloud, potrebbe essere database legacy, potrebbe essere mainframe. Puoi raggiungere lo stesso obiettivo della dipendenza SQL tranne che in quel caso non sei in quella notifica n. Una dipendenza personalizzata è qualcosa che implementi. È il tuo codice che questo è codice lato server, quindi NCache ha questo concetto di codice lato server. Codice che scrivi, che risiede sul server cache.

Read-Thru e Write-Thru

La dipendenza personalizzata è una, il write-through read-through è un'altra. Ho appena parlato dell'essere read-through, che è possibile ricaricare la cosa se in una sincronizzazione del database, se si rimuove l'elemento NCache può andare a ricaricare. Come si può ricaricare? Anche se il tuo codice read-through. Cos'è il Read-through? Sembra che io stia saltando avanti e indietro, ma volevo collegare questi. Ecco perché. Come si fa a... scrivere e leggere è solo un'interfaccia semplice, quindi qui hai un'interfaccia di lettura. Sì, tre metodi c'è un Init che ti consente di connetterti all'origine dati. Dispose è la disconnessione e sono troppo sovraccarichi di LoadFromSource. Quindi, LoadFromSource è una chiave e restituisci un elemento della cache e LoadFromSource ha un sovraccarico in cui puoi restituire un dizionario Quindi, LoadFromSource è qualcosa che NCache chiama il tuo gestore di lettura.

Quindi, supponiamo che la tua applicazione esegua il Cache.Get e quell'elemento non è nella cache e lo dici NCache se non è nella cache, vai e chiedi al gestore di read-through. NCache chiamerà il gestore read-through perché il gestore read-through è il codice che risiede all'interno del cluster di cache. NCache chiamerà questo metodo. Questo metodo è il tuo codice, va al tuo database, alla tua fonte di dati, che potrebbe essere qualsiasi cosa, potrebbe essere un SQL o chiamato mainframe e ottenere i dati e quindi inserirli. Ora che NCache ha la capacità di andare al tuo database, significa che può ricaricare automaticamente. Quindi, questa è la parte della comodità. Quindi, puoi sincronizzarlo con il database relazionale e il database non relazionale.

Memorizzazione nella cache dei dati relazionali

L'ultima cosa è memorizzare nella cache i dati relazionali. Devi tenere la contabilità con l'applicazione dati e tenere traccia di un dato e della relazione con l'altro. Farò solo un esempio di un cliente che ha più ordini. Anche se di solito non elimini un cliente, diciamo solo se lo hai fatto e la cache non lo sa, quindi diciamo che se lo hai eliminato un oggetto cliente dalla cache e aveva dieci ordini nella cache, quegli ordini non sono più validi, non dovrebbero essere mantenuti nella cache. Quindi, ogni volta che hai uno-a-molti, di solito i molti dipendono dall'uno, quindi se ne elimini uno dalla cache, dovresti eliminarne anche molti dalla cache. Ora è qualcosa di cui dovresti tenere traccia ogni volta che ne elimini uno devi andare ed eliminarne molti. Quindi quello che puoi fare invece è che l'oggetto cache ASP.NET fosse collegato al concetto di dipendenza. NCache implementato questo in modo da poter mettere in relazione questi due e quindi se l'oggetto cliente viene mai aggiornato o spostato, tutti gli ordini vengono rimossi automaticamente.

È possibile utilizzare la dipendenza dalla cache per uno di troppo, per uno a uno e anche se si desidera memorizzare nella cache le raccolte e quindi archiviare i singoli oggetti anche separatamente. Quindi, è nella tua raccolta di clienti come un oggetto memorizzato nella cache e alcuni dei clienti sono stati memorizzati anche individualmente nella cache. Perché nella cache puoi conservare più copie. È tutto conservato dalla tua applicazione. Quindi, a differenza del tuo database che deve avere la normalizzazione e l'integrità dei dati e in questo modo la cache può avere più copie perché è tutta una questione di prestazioni. Quando hai più copie e devi essere in grado di ripulire quando una copia viene aggiornata ed è ciò che questa dipendenza dalla cache ti consente di fare. Quindi, questi sono i quattro diversi modi in cui mantieni la tua cache fresca. Sono tutti disponibili come parte di NCache open source.

Funzionalità di memorizzazione nella cache dei dati delle app: lettura e scrittura

Ho di nuovo il read-through write-through, il write-through è lo stesso del read-through, tranne per il fatto che quando aggiorni la cache chiedi alla cache di andare ad aggiornare il database.

Read-through e Write-through

Quindi, il read-through è quando leggi la cache chiedi alla cache di leggere dal database nel caso in cui non abbia i dati. Ora, la lettura e la scrittura consentono di consolidare il codice di persistenza in un unico livello di memorizzazione nella cache. E lascia che la cache diventi più consapevole del tuo database e l'applicazione diventa sempre più semplice.

Scrivi dietro

write-through ha anche un ulteriore vantaggio chiamato write behind che ogni volta che aggiorni il database, l'operazione più lenta nell'applicazione è l'aggiornamento del database. È anche più lento del recupero dei dati dal database e se stai utilizzando una cache per recuperare i dati, quindi non devi andare così tanto al database. Perché non utilizzare la cache per i dati aggiornati se i dati non sono così sensibili. Significa che puoi metterlo in coda per l'aggiornamento asincrono. Se i dati sono molto sensibili, ovviamente non vuoi metterli in coda per l'aggiornamento asincrono, ma molti dei dati sono che puoi metterli in coda per l'aggiornamento asincrono. Quando lo metti in coda e fondamentalmente esegui una funzione di scrittura dietro, chiedi NCache per scriverlo nel database in modo asincrono, man mano che viene creata una coda o richieste di aggiornamento multiple, quella coda viene replicata su più server, nel caso in cui un server si interrompa non sei perso. Inoltre, la tua applicazione accelera sicuramente perché non attende più l'aggiornamento del database. Quindi, il write-through ha il vantaggio in termini di prestazioni. E, scrivi dietro.. La lettura completa ha tutti i vantaggi.

Ricarica automatica degli elementi

Puoi anche ricaricare automaticamente con le scadenze. Quindi, alla scadenza, puoi ricaricare automaticamente quell'articolo. La scadenza sostanzialmente, diciamo, probabilmente cambia nel server del database. Non è più valido nella cache, quindi non lo rimuove perché non lo carichiamo perché ne avrai comunque bisogno. Quindi è probabilmente una sorta di ricerca dei dati, quindi leggila automaticamente. Ancora una volta, la cache assume sempre più lavoro dalla tua applicazione.

Funzionalità di memorizzazione nella cache dei dati delle app - Raggruppamento dei dati

Una volta che sei in grado di mantenere la cache fresca e sei sicuro, ora inizi a memorizzare nella cache molti dati. Quando inizi a memorizzare nella cache molti dati, è davvero bello se puoi cercare dati oltre questa coppia di valori chiave. Ho appena parlato con qualcuno la scorsa notte e hanno dovuto trovare delle tecniche su come formattare le chiavi per trovare diversi tipi di dati. Questo è qualcosa che non devi fare NCache. Puoi assegnare questi meta tag chiamati gruppi e sottogruppi e tag e tag con nome. Si tratta di metadati che puoi assegnare ai tuoi oggetti invece di rinominare le chiavi. Questi potrebbero essere dati migliori e in base a ciò puoi dire dammi tutto ciò che ha questo tag o questi due tag o questi tre tag o dammi tutto ciò che appartiene a questo gruppo. Quello è uno.

In secondo luogo puoi eseguire query SQL. Lascia che te lo mostri. Quindi, ancora una volta, la cache inizia ad assomigliare sempre di più a un database.

Quindi, ad esempio, puoi dire qui, seleziona tutti i prodotti con questo nome, quindi ora stai facendo una ricerca basata su un attributo dell'oggetto prodotto. Ora questo è molto NCache codice in modo da eseguire.reader proprio come SQL Server. È molto simile, ti riavrai un lettore Icache e guardi semplicemente alla tua roba. Ora, questo è di nuovo qualcosa che consente alla cache di fare ovunque sia necessario. Da un lato, metti molti dati nella cache in secondo luogo, ora puoi cercare i dati dalla cache.

ASP.NET Core Archiviazione della sessione

Ho parlato dell'ASP.NET core sessioni. Penso che la cosa principale da tenere a mente che ci sono due modi in cui puoi usarlo.

Archiviazione IDistributedCache

Uno è che ti colleghi NCache. NCache ha implementato un provider IDistributedCache. Quindi, ti colleghi NCache come provider IDistributedCache e ASP.NET core inizia automaticamente a memorizzare le sessioni in NCache. Vedi se ce l'ho qui.

Quindi, ad esempio, ecco un ASP.NET Core applicazione, vai ai servizi di configurazione e aggiungi semplicemente NCache come provider IDistributedCache e ora stai utilizzando il normale ASP.NET core sessione che sanno dipendere da IDistributedCache perché sanno che ora c'è un provider collegato. Quindi, quando lo fai, tutte le sessioni verranno salvate NCache. E ti mostrerò com'è la memorizzazione nella cache. Ti darò solo una vera demo di NCache. Quindi, questo è un modo.

NCache Fornitore di sessioni

Il secondo modo è che tu usi effettivamente NCache come proprio provider di sessione stessa, quindi, invece di andare a IDistributedCache, vai negli stessi servizi di configurazione e dici aggiungi NCache fornitore di sessioni.

Ora, questo provider di sessioni ha più funzionalità rispetto al normale IDistributedCache. Ha più funzionalità specifiche per la sessione. Voglio dire, ti consiglierei di usare il NCache sul proprio provider di sessioni che è stato utile con IDistributedCache. Ma puoi andare su entrambe le opzioni, ASP.NET core ti fornisce questo. Come ho detto, questo non richiedeva altro che quello per la modifica del codice. È tutto. Tutto il resto è automatico. Quindi, se hai intenzione di beneficiare di una cache distribuita come NCache, collegalo come punto di ingresso nella tua applicazione. Devi trarre vantaggio oggi perché la cache degli oggetti nella cache dei dati dell'applicazione richiederà la programmazione, quindi si adatterà ai tuoi programmi di sviluppo e un processo leggermente più lungo di questo. Ma questo è fatto molto molto rapidamente e lo so sicuramente già qui.

ASP.NET Core Memorizzazione nella cache delle risposte

E questa è una configurazione, quindi di nuovo andrò oltre e allo stesso modo la cache delle risposte utilizza una cache distribuita e puoi collegarti NCache a quello e poi funziona automaticamente.

Requisiti architettonici sulla cache distribuita

Permettetemi di entrare rapidamente in alcune delle cose che NCache andrà bene.

Alta disponibilità

Una cache distribuita è qualcosa come un database, vive in produzione con la tua applicazione. Quindi, devi assicurarti che la sua architettura sia flessibile, altamente disponibile.

Quindi, ad esempio, NCache ha un'architettura peer-to-peer ma altri tipi di Redis non ho. Quindi, invece di avere un master slave, vuoi avere un peer-to-peer. Come ho detto, molte delle cache Java che chiamano nella griglia dei dati di memoria hanno un'architettura peer-to-peer. La cosa bella del peer-to-peer è che tutti sono peer, quindi qualsiasi nodo può andare giù e non succede nulla. Probabilmente il padrone schiavo è lo schiavo non può diventare padrone. Se il padrone muore, lo schiavo è ancora uno schiavo. Quindi, richiede un intervento manuale per il tuo ripristino. In caso di peer to peer, si ripristina automaticamente. Quindi, a causa del peer to peer, diventa ciò che chiamiamo cluster dinamico di autoguarigione che si adatta automaticamente. Quindi, questo è il primo aspetto.

Scalabilità lineare w. Replica

Il secondo aspetto è la scalabilità lineare che è il partizionamento e ancora la scalabilità lineare con regolazione dinamica della partizione.

Le cose NCache lo fa automaticamente, diciamo se hai una configurazione a due server e vuoi sommare quelle sono due partizioni e ora vuoi aggiungere un terzo server in modo che sia la terza partizione aggiunta. NCache automaticamente, diciamo che va da , diciamo che hai due server qui con due partizioni. Ogni partizione come backup su un server e una partizione diversi è essenzialmente una raccolta di bucket con distribuzione di mappe hash.

Quindi, diciamo che se hai 1,000 bucket, 500 andranno nella partizione 1, 500 nella partizione mondiale 2, tutto funziona correttamente, ora vuoi aggiungere un terzo server. St una volta perché ancora, aggiungendo un terzo server ora puoi avere tre partizioni, quindi NCache funzionerà automaticamente dietro le quinte mentre l'applicazione è in esecuzione, creerà una terza partizione e sposteremo alcuni dei dati per la partizione 1 e 2 nella terza partizione. Di nuovo, un terzo, un terzo un terzo. Quindi, i secchi si muovono effettivamente e tutto ciò accade dinamicamente. Una volta spostati i bucket, anche le repliche vengono riadattate, ma la replica uno e due non sono più le stesse repliche di prima, hanno rapidamente meno dati e c'è la nuova replica chiamata replica tre. Il server che aveva repliche due non replica più 3, ne avrà tre e la replica tre verrà creata sul terzo server, tutto ciò viene eseguito automaticamente per te.

Quindi, quel dinamismo è ciò che lo rende altamente disponibile. Quindi, quando aggiungi un server c'è un intervento manuale ma devi davvero... Quindi, è ancora molto conveniente se puoi semplicemente andare e farlo. Letteralmente, dici solo aggiungi e tutto è fatto per te. Ma è ancora più importante quando si elimina un server perché l'eliminazione potrebbe verificarsi anche a causa di un arresto anomalo del server. Quindi, quando sei in una configurazione a tre server, ciò dice che il server 3 non funziona, ora la partizione 3 è persa, cosa NCache farà immediatamente la replica tre attiva perché ha una copia della partizione 3. Quindi, ora hai la partizione 1, la partizione 2 e la replica 3 perché la partizione 3, temporaneamente. Quindi, non c'è interruzione. Una volta fatto, allora NCache ora renditi conto che solo due server possono avere solo tre partizioni, unisce la replica 3 nella partizione 1 e 2, tutto in una volta e quindi una volta completata l'unione, ora crea una replica 2 in questo posto qui. Quindi, puoi tornare a questa immagine.

Ora questo è qualcosa che con altre mode non puoi fare automaticamente. Ciò significa che se questa cosa è accaduta e nel mezzo è morto uno dei tuoi reparti IT, le persone dovranno andare manualmente e riadattarsi e fino a quando ciò non accadrà una cache per uno e quella che chiamano funzionalità limitata ma NCache lo fa automaticamente proprio così. Quindi, devi assicurarti che l'alta disponibilità sia davvero presente in una cache.

Cache cliente

Ho già parlato della velocità di InProc.

Wan replica

C'è un'altra funzionalità e ora questa è una funzionalità per Enterprise Edition che è che, se si dispone di più data center in cui sono state spostate molte applicazioni, grazie al cloud è più facile distribuire l'applicazione in più regioni.

Pertanto, se la tua applicazione è incentrata su più dati, potrebbe essere necessario replicare anche la tua cache su più aree e, poiché c'è molta latenza, non puoi davvero avere l'intero cluster che si estende su più regioni. Quindi, avrai un cluster in uno in un cluster e c'è un bridge in mezzo al quale si replica in modo asincrono. Quindi, è un caso di replica bidirezionale di attivo-attivo e il bridge esegue la risoluzione dei conflitti poiché la stessa chiave viene aggiornata per entrambe le posizioni. Ora devi tenerne traccia.

NCache Dimo

Lascia che ti mostri rapidamente cosa NCache sembra. Quindi, ho Azure, quindi ho praticamente acquistato o effettuato il provisioning, se riesco a ottenere il portale, eccolo lì! Quindi, ho... è davvero lento. Dai! Prendendo quattro sì, va bene! Quindi, abbiamo quattro macchine virtuali in questo e ho effettuato l'accesso a una di esse che è il... Quindi, ho fondamentalmente due server cache, sono tutte finestre, un client cache Windows, un client cache che è Linux. Perché è .NET core, posso fare tutto. Anche i server di cache possono essere vivi ma NCache come ho detto è .net core quindi puoi semplicemente andare, quando visiti il nostro sito Web, Just, puoi effettivamente scaricare .msi o Tar.gz a seconda delle tue preferenze. Puoi installare Windows o Linux. In realtà, puoi scaricare open source anche da qui. La nostra azienda è costruita sulla base del nostro open source, quindi siamo proprietari dell'open source e di uno aziendale.

Crea una cache raggruppata

Quindi, fammi rapidamente ora, scusa per questo, creerò un cluster di cache a 2 nodi, ancora una volta, questo strumento non è open source ma tutte queste cose che puoi fare in open source. Non è così carino. In realtà, questo sarà uno strumento basato sul Web ora. Quindi, vado solo avanti. Questo è il mio primo server cache. Questo è il mio secondo server cache. Quindi, farò un cluster di cache di due server. Prenderò tutte le altre impostazioni predefinite così come sono. Andrò avanti e aggiungerò due client, uno sono io stesso che è il client Windows e il secondo aggiungerò il client 10.0.0.7 e il client Linux. Iniziamo la cache. Voglio dire, questo è quanto è veloce per te creare e configurare le cache.

Simula lo stress e monitora la cache

Inizierò le mie prime statistiche su questo. NCache viene fornito con questo programma chiamato strumento di stress test che consente di simulare il carico NCache. Quindi, è come un programma. Ottiene input da solo. Ho PowerShell aperto qui, quindi eseguirò il test di stress e inserirò il nome della cache che è il nome della cache che ho appena dato qui, scrivi qui e ho proprio ora questa scatola, questa è la prima. Quindi, vado alla casella del cliente, quindi eseguirò questo e vedi che all'improvviso inizia l'attività qui. Quindi, sto facendo circa 500 operazioni al secondo per scatola in questo momento, ok? Quindi, diciamo, voglio aumentare il mio carico, voglio testare come NCache funzionerà nel mio ambiente, quindi andrò avanti e avvierò un'altra istanza dello stesso sulla stessa scatola. Improvvisamente, vedrai che il mio carico è quasi raddoppiato e ora ho due box Linux, come puoi vedere qui è Linux, questo è il . sette box che è proprio qui. Quindi, per prima cosa avvierò PowerShell qui, voglio semplicemente copiare rapidamente questo modulo e farò la stessa cache demo di stress test e non appena lo farò vedrai che all'improvviso sta per avere 60 anni...

Quindi, ogni volta che lo faccio, vengono aggiunte circa 500 operazioni al secondo per scatola. Ne farò un altro e poi avremo finito con quello. Aggiungerò... Quindi, puoi continuare ad aggiungere sempre più carico fino a quando non vedrai che inizieranno a raggiungere il massimo e quindi aggiungi un terzo server. E, ovviamente, devi anche aggiungere più clienti. Tutto questo è perf-mon che puoi facilmente monitorare, anche con strumenti di terze parti. Questo è così semplice. Questi sono elementi memorizzati nella cache che stai aggiungendo.

Puoi accedere al download del nostro sito Web, sia open source, quindi è disponibile l'open source, c'è anche un programma di installazione MSI in modo da scaricare l'open source. Quindi, puoi scegliere l'open source o se sei davvero sicuro di volerlo utilizzare in un ambiente di supporto, vai avanti e scarica subito enterprise. Diciamo che se vengo all'open source, così puoi scaricare il programma di installazione, in questo modo non devi essere fatturato per il codice sorgente. Ancora una volta, sebbene tutto il codice sorgente sia su GitHub.