Parla al Live 360 Orlando 2016
Ridimensionamento di applicazioni .NET con cache distribuita
Di Iqbal Khan
Presidente ed evangelista tecnologico
Le tue applicazioni .NET potrebbero riscontrare colli di bottiglia nel database o nell'archiviazione a causa dell'aumento del carico delle transazioni. Scopri come rimuovere i colli di bottiglia e ridimensionare le tue applicazioni .NET usando la cache distribuita. Questo discorso copre:
- Panoramica rapida dei colli di bottiglia della scalabilità nelle applicazioni .NET
- Descrizione della cache distribuita e di come risolve i problemi di prestazioni
- Dove puoi utilizzare la cache distribuita nelle tue applicazioni
- Alcune caratteristiche importanti in una cache distribuita
- Esempi pratici utilizzando una cache distribuita
Cos'è la scalabilità
Quindi, iniziamo con alcune definizioni. Sono sicuro che molti di voi lo sanno già, ma lo esamineremo solo per motivi di completezza. La prima definizione è la scalabilità. Allora, cos'è la scalabilità? Le persone spesso confondono la scalabilità con le prestazioni. Le prestazioni sono tempi di risposta davvero rapidi per applicazione, ma potrebbero essere solo con cinque utenti e se si passa da cinque utenti a cinquemila o 50,000 utenti e le prestazioni rimangono buone, l'applicazione è scalabile. Questa è la sintesi di ciò che stiamo cercando di ottenere.
In qualunque applicazione tu abbia, se puoi ottenere le stesse prestazioni che avevi con cinque utenti o un carico di transazioni davvero basso, se puoi ottenere le stesse prestazioni con un carico di transazioni elevato, allora sei scalabile. Se non hai buone prestazioni con cinque utenti, hai altri problemi.
Scalabilità lineare
La scalabilità lineare è più una definizione di infrastruttura, ovvero se l'applicazione è progettata in modo tale da aggiungere più server alla distribuzione, sia che si tratti di aggiungere più server di applicazioni o server di database o altro, se ciò può aumentare la capacità di transazione in modo lineare fashion allora hai un'architettura applicativa linearmente scalabile.
Tuttavia, se non sei in grado di farlo, se l'aggiunta di più server non aggiunge alcun valore, c'è qualcosa di fondamentalmente sbagliato e non sei in grado di ridimensionare l'applicazione in modo lineare. L'obiettivo qui è, ovviamente, essere in grado di scalare in modo lineare.
Scalabilità non lineare
Non lineare sarebbe dove, aggiungendo più server si vede aumentare ma ad un certo punto dopo non c'è più aumento, infatti, c'è un calo delle prestazioni anche se si aggiungono più server perché l'architettura dell'applicazione e la distribuzione ci sono dei colli di bottiglia che proprio non sei in grado di superare.
Quali applicazioni necessitano di scalabilità?
Di solito si tratta di applicazioni web.
Quindi, questi sono ASP.NET for.NET gente, servizi web, back-end per l'Internet delle cose che è uno spazio emergente molto forte e l'elaborazione di big data. L'elaborazione di big data è più comune sul lato Java. Non molte persone lo fanno sul lato .NET, ma anche l'elaborazione di big data è un altro spazio. E, qualsiasi altra applicazione server, questa potrebbe essere la tua applicazione di elaborazione batch. Potresti essere una società di servizi finanziari e avere milioni di clienti che chiamano e cambiano indirizzo o forse stanno trasferendo fondi da un conto all'altro e poiché hai determinati requisiti di conformità che entro il cuore della notte o qualcosa che hai per completare quelle elaborazioni e ci sono alcune elaborazioni batch in corso nel back-end, in un flusso di lavoro, in un certo modo. Pertanto, qualsiasi altra applicazione server soggetta a vincoli di tempo per eseguire un determinato numero di transazioni, necessita di scalabilità.
Problema di scalabilità
Allora, dov'è il problema della scalabilità? Abbiamo parlato di scalabilità lineare e non lineare. Quindi, il problema della scalabilità è che il livello dell'applicazione si ridimensiona in un modo lineare molto piacevole. Se si dispone di un'applicazione Web o di servizi Web, il livello dell'applicazione, è sufficiente aggiungere più server, nessun problema. È l'archiviazione dei dati che è il collo di bottiglia. E, quando dico la parola archiviazione dei dati, intendo database relazionali e dati legacy del mainframe. non intendo NoSQL database. NoSQL databasesono fantastici. Abbiamo anche un NoSQL prodotto chiamato NosDB ma nessun database SQL non è sempre la risposta. Sono una risposta se puoi spostare più dati a cui ti sposti NoSQL database è la più di una soluzione di scalabilità che ottieni. Ma il problema è che non puoi spostare tutti i dati in NoSQL. Ci sono molti dati che devono rimanere relazionali per motivi sia tecnici che aziendali.
Quindi, i database relazionali sono qui per restare. Non stanno andando da nessuna parte in termini di questo problema. Quindi, devi aggirare questa realtà o lavorare con questa realtà che lavorerai con database relazionali e devi comunque risolvere questo problema. E il motivo per cui devi risolvere questo problema è che hai tutte quelle applicazioni che ho menzionato che richiedono scalabilità.
Distribuzione cache distribuita
E, naturalmente, la risposta è avere una cache distribuita collegata tra il livello dell'applicazione e il livello del database.
Quindi, una cache distribuita è, essenzialmente, un concetto molto potente e tuttavia molto semplice. Hai due o più server a basso costo e sono raggruppati insieme e quel cluster raggruppa la memoria e le risorse della CPU di tutti i server insieme in un'unica capacità logica. il collo di bottiglia e la scalabilità si trovano in tre aree. Uno è la memoria, il secondo è la CPU, il terzo è la scheda di rete.
Quindi, se hai, diciamo, un server di database qui e hai 20 caselle di livello dell'applicazione che un server di database puoi occupare in termini di potenza dell'hardware, puoi aggiungere più memoria, molte più CPU, ma c'è un limite a questo. Quindi, la risposta è, per poter avere sempre più server che non sono di fascia alta, infatti, non dovrebbero essere di fascia alta per definizione. E quello che abbiamo visto negli ultimi 10 anni o più in questo modo è che la configurazione più comune è un tipo quad-core a doppia CPU di un equivalente. Quindi, diciamo, una scatola a 8 core e una scatola a 16 core è in realtà una configurazione di fascia alta per un server di memorizzazione nella cache. 8 core è praticamente il comune.
Memoria, ovviamente, hai bisogno di molta memoria perché e la memoria è economica, quindi non è un fattore importante. Hai bisogno di molta memoria, perché perché la cache è un archivio in memoria, quindi memorizza tutto in memoria e, una configurazione tipica sarebbe di circa 16-32 giga di memoria in ciascun server cache e 2 server cache è il minimo che dovresti avere per motivi di ridondanza. Quindi, avendo questa architettura, ora ti trovi in una situazione in cui aggiungi più server nel livello dell'applicazione. Aggiungi più server proporzionalmente nel livello di memorizzazione nella cache. Quindi, di solito, è un rapporto 4 a 1 o 5 a 1 quello che abbiamo visto come il più pratico. In alcuni casi, puoi andare molto più di 5 a 1. Significa 5 server delle applicazioni per 1 server di memorizzazione nella cache ma non c'è limite al numero di server che puoi avere. Puoi averne 2, puoi avere 4, 10, 20, 30 server ma per avere 20 server qui, probabilmente avrai bisogno di un centinaio di server nell'ambiente del bilanciamento del carico.
Quindi, a un certo punto, diventa praticamente una fascia alta di qualsiasi applicazione che abbiamo visto nel web o nell'e-commerce nello scenario aziendale online. Quindi, aggiungendo più server qui, questo non è più il collo di bottiglia. Quindi, la memorizzazione nella cache distribuita sta effettivamente diventando una best practice. Se hai la scalabilità come necessità. Perché ora non solo hai un database che è lì per il suo scopo, hai bisogno della persistenza permanente dell'archivio dati per tutti i dati dell'applicazione, ma hai anche questa infrastruttura davvero molto veloce e scalabile che ora fa parte dell'architettura della tua applicazione. Quindi, quando stai programmando, non stai più solo programmando per il database. Stai sempre pensando a una cache perché la cache ora farà in modo che la tua applicazione non rallenti mai anche con carichi di picco. Anche se il database non è stato progettato per scalare allo stesso modo. Quindi, questa è un'immagine tipica.
Circa l'80% del traffico verrà intrappolato o sarà l'80% delle volte che andrai alla cache, il 20% delle volte andrai al database e quel 20% sono per lo più aggiornamenti e, naturalmente, alcune letture perché tu è necessario inserire i dati nella cache, ma puoi anche pre-popolare la cache e ci sono molti altri modi per farlo. Tuttavia, riducendo così drasticamente il traffico nel livello di database, è così che ottieni prestazioni e scalabilità.
Quindi, questo è il caso dell'utilizzo di una cache distribuita. Perché è necessario mantenerlo come parte dell'architettura dell'applicazione.
Casi di uso comune
Quindi, ora che abbiamo in qualche modo presentato il caso per l'utilizzo di una cache distribuita, la prossima domanda è: come la usi? Dove lo usi? che tipo di utilizzo dovresti avere di una cache distribuita?
Memorizzazione nella cache dei dati dell'applicazione
Bene, l'uso più comune è la memorizzazione nella cache dei dati dell'applicazione. È qui che, come stavo appena parlando, qualunque dato tu abbia nel database, lo metti nella cache. In modo da non dover andare al database. La cosa da tenere a mente e che esaminerò questo punto in modo più dettagliato nelle diapositive di follow-up è che in un caso d'uso di memorizzazione nella cache dei dati di un'applicazione, i dati esistono in due punti. Uno è nel database che è dove deve sempre essere e il secondo è la cache. Quindi, ogni volta che i dati esistono in due posti, qual è il primo problema che viene in mente? Sincronizzazione! Sì.
Quindi, qualsiasi cache che non sia in grado di gestire quella situazione, ti costringe a memorizzare nella cache i dati di sola lettura, dati che sai non cambieranno mai. In effetti, la maggior parte delle persone quando si parla di cache, il pensiero istintivo che viene loro in mente è perché è per i dati di sola lettura? Non voglio davvero memorizzare nella cache i miei clienti e account e dati che cambiano ogni 30 secondi. Ma la ricerca mostra che l'uso più grande di una cache è nei dati transazionali e una volta memorizzati nella cache probabilmente ne avrai bisogno nei prossimi uno o due minuti, qualunque sia l'attività, qualunque sia la finestra mobile del tuo utilizzo. È allora che hai bisogno di nuovo degli stessi dati e se riesci a ottenerli dalla cache stai riducendo quei viaggi al database e moltiplicandoli per milioni di transazioni che stanno accadendo nella tua applicazione e diventa una spinta piuttosto significativa. Quindi, tieni presente questo problema mentre andiamo avanti che qualsiasi buona cache deve gestirlo in modo molto molto efficace.
Memorizzazione nella cache specifica di ASP.NET
Il secondo caso d'uso è che, se si dispone di un'applicazione ASP.NET, sono presenti molti dati temporanei. Transitorio significa temporaneo e che puoi mettere nella cache e questi dati non appartengono davvero al database. Ad esempio, un database è lì per permanente. È un negozio permanente. Questo è il tuo record principale. Quindi, un stato della sessione, probabilmente devi conservarlo solo per tutto il tempo in cui l'utente ha effettuato l'accesso forse 20 minuti dopo, lo sai. Allora, perché tenerlo nel database? Il database non è così veloce. I database relazionali non sono stati progettati per archiviare BLOB e le sessioni vengono in genere archiviate come BLOB. Quindi, c'è un grande impatto sulle prestazioni quando si archiviano le sessioni nel database. Quindi, lo stato della sessione è un ottimo caso d'uso per ASP.NET per inserirlo nella cache distribuita.
E, se non stai utilizzando il framework MVC, c'è anche lo stato di visualizzazione che è un pezzo di dati piuttosto pesante che scorre dal server Web al browser per un solo scopo, per tornare al browser in un postback. Quindi, è un viaggio piuttosto lungo, per niente come si suol dire. Quindi, sarebbe molto più bello se lo mantenessi sul lato server e invii semplicemente una piccola chiave. Quindi, questo è un ottimo caso d'uso per la memorizzazione nella cache.
Il terzo caso d'uso è l'output della pagina, molte delle tue pagine il loro output non cambia ogni volta. Quindi, se non sta cambiando, perché eseguire la pagina perché quando esegui la pagina stai consumando la CPU, la memoria e tutte le altre risorse. Perché non prendere l'output dell'ultima esecuzione e visualizzarlo. Quindi, Microsoft o ASP.NET hanno un framework della cache di output in cui è possibile collegare una cache distribuita. Quindi, ora in questo caso d'uso, in questi tre casi d'uso in ASP.NET, la natura del problema è completamente cambiata. Non è più la sincronizzazione tra la cache e il database. Come mai? Perché non esiste un database. La cache è il database.
La natura del problema ora è... quindi la cache è in memoria, va bene? È così che ottieni tutte le prestazioni. Quindi, quando tieni i dati in memoria e questo è l'unico archivio, qual è la preoccupazione più grande che hai? Potresti perderlo! E se quella scatola si riavvia? È noto che Windows riavvia o ricicla i processi di lavoro. E se e intendo, anche se una scatola Linux dovesse riavviarsi, ma cosa succede se la tua scatola si riavvia? Sei pronto a perdere quei dati? E se tu fossi una compagnia aerea e quel cliente fosse nell'ultima pagina di inviare un valore di $ 5,000 avesse quel biglietto per le vacanze in famiglia che stavano per acquistare per le Hawaii e all'improvviso dice: scusa, devi ricominciare tutto da capo! Sai e hanno esaminato tutti i tipi di ricerche di volo e tempi di controllo e hanno anche fatto voli su Google e hanno visto quali corrispondevano e tutte le altre cose, quindi non è stata una bella esperienza.
Come azienda, non vuoi perdere il cliente, il carrello, non vuoi perderlo. Quindi, la risposta è una cache distribuita. Dovresti mantenere le sessioni al suo interno o tutti quei dati transitori solo se può garantire l'affidabilità, se assicura che non perderai mai quei dati, se assicura che esegua la replica. Quindi, una buona cache distribuita esegue una replica dei dati su più server. Ora la replica è in realtà una perdita di tempo, è una cosa extra che fare solo per quella contingenza di cui stiamo solo parlando. Quindi, il lato negativo della replica è che ha un calo delle prestazioni. Quindi, se una cache non lo fa in modo intelligente e molti di loro non lo fanno, vedrai un calo delle prestazioni quando accendi la replica.
Condivisione dei dati di runtime tramite eventi
Quindi, tieni a mente questi due punti e il terzo caso d'uso è ciò che la maggior parte delle persone non sa in realtà che una cache distribuita, una volta che hai quell'infrastruttura nel tuo ambiente, è una piattaforma di condivisione dei dati basata sugli eventi molto potente. Pertanto, potresti avere più applicazioni che devono condividere i dati in un flusso di lavoro. Potresti avere un tipo pub/sub di una situazione, per cui probabilmente utilizzerai un bus di messaggi, un bus di servizio aziendale o una coda di messaggi per esso. Una cache distribuita è una piattaforma molto potente per questo. Dal momento che lo hai già in casa, in realtà è più veloce e più scalabile rispetto alle altre opzioni perché è stato progettato per le prestazioni mentre le altre applicazioni sono state progettate più per la sola condivisione.
Quindi, tipo pub/sub guidato da eventi di una condivisione tra più applicazioni. Un'applicazione produce alcuni dati, li inserisce nella cache, attiva un evento. Ci sono altre applicazioni che hanno registrato interesse per quell'evento, che voglio utilizzare questi dati ogni volta che sono disponibili per me. Quindi, ricevono l'evento e di nuovo un'applicazione potrebbe essere qui, un'applicazione potrebbe essere qui, questo diventa un motore di eventi scalabile molto molto potente a cui tutti possono attingere.
Quindi, questo è un terzo caso d'uso. Anche nel caso in cui, nella funzionalità di condivisione dei dati di runtime o nel caso d'uso, la maggior parte dei dati sia transitoria. Sebbene sia derivato da dati permanenti e potrebbe probabilmente ricrearlo da quei dati permanenti, ma è un sacco di lavoro per farlo e quei dati sono solitamente temporanei, perché la natura di questi utilizza temporanei. Di solito non lo è, non è necessario salvarlo nel database. Ha solo bisogno di essere consumato. Quindi, la cache è ancora una volta l'unico negozio che sarà e quindi, proprio come le sessioni e altri, i problemi sono gli stessi che l'affidabilità deve dare inizio. Quindi, questi sono i tre modi comuni in cui useresti una cache distribuita.
Quindi, la cosa bella di questi tre casi d'uso è che non è necessaria alcuna programmazione per farlo perché l'ASP.NET framework ti consente di collegare un provider di terze parti. Quindi, per le sessioni ad esempio, se dovessi averti ti mostrerò rapidamente un rapido esempio in cui tutto ciò che fai è andare alla configurazione web e, naturalmente, nell'ASP.NET core, quel paradigma cambierà leggermente ma l'idea è la stessa.
Configurazione della memorizzazione nella cache della sessione ASP.NET
Quindi, se vai su Web.config, questa è solo una semplice applicazione ASP.NET. Vai su Web.config, devi prima aggiungere l'assembly di qualsiasi cache che utilizzerai in caso di NCache, eseguirai solo l'aggiunta dell'assieme sul file NCache provider del negozio di sessione e tu fai semplicemente copia incolla e la seconda cosa che devi fare davvero è apportare modifiche qui.
Quindi, c'è un tag di stato della sessione nel Web che configura in cui è necessario assicurarsi che la modalità sia personalizzata e che il timeout sia qualunque sarà il timeout. E, in caso di NCache, quindi devi semplicemente aggiungere questa riga e un sacco di altri parametri che puoi specificare che non ho intenzione di approfondire, ma uno di questi è solo il nome della cache. In caso di NCache, tutte le cache sono nominate e in realtà ti fornirò anche una demo di questo, ma. Quindi, devi solo specificare il nome della cache. La cache è già stata creata. È come una stringa di connessione che ti dice a quale cache connetterti perché potresti avere più cache, una per le sessioni, una per i dati dell'applicazione e questo è tutto. Voglio dire, apporti quella modifica e fai solo un test di integrità, esamini tutti i casi d'uso comuni della tua applicazione e la tua applicazione è improvvisamente pronta per archiviare le sessioni in un cache distribuita come NCache. Quindi, il modo più semplice per trarre vantaggio e il guadagno più grande in realtà sono le sessioni.
Quindi, questo è tutto ciò che devi fare per l'utilizzo dello stato della sessione in una cache distribuita come NCache o qualsiasi altro e lo stesso vale per la cache di output dello stato di visualizzazione. È tutto il cambiamento basato sulla configurazione. Non ho intenzione di entrare in ognuno di loro. Volevo solo mostrarti questo come esempio.
Memorizzazione nella cache dei dati dell'app
Quindi, veniamo al cuore di una cache distribuita e dico cuore perché è lì che passerà la maggior parte del tuo tempo. Se scegli di incorporare una cache distribuita, farai la maggior parte del tuo tempo eseguendo la memorizzazione nella cache dei dati dell'applicazione. Quindi, che aspetto ha una tipica API?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");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");Se conoscete l'oggetto cache ASP.NET, NCache cerca di imitarlo il più vicino possibile anche se siamo un superset quindi c'è di più. Ogni cache ha la sua API. Questo è ciò che un NCache L'API sembra. Ti connetti con la cache, è una cache denominata. Ottieni un handle di cache, mantieni quel handle di cache in giro e all'interno dell'applicazione mantieni solo Cache.Get. Ottieni, Contiene, Aggiungi, Inserisci, Rimuovi, c'è anche aggiungi Async, Inserisci Async. Inserisci significa aggiungere se non esiste o aggiornare se esiste già. Questa è la stessa terminologia dell'oggetto cache ASP.NET che usi, ecco perché lo abbiamo anche usato. E il metodo Async significa fondamentalmente che non devi attendere il completamento dell'operazione. Puoi effettivamente, c'è un terzo parametro che è che puoi specificare un callback. Quindi, la tua richiamata verrà chiamata nel caso qualcosa vada storto oppure puoi praticamente presumere che tutto sia andato bene.
Mantieni la cache fresca
Quindi, quando eravamo qui, abbiamo parlato della memorizzazione nella cache dei dati delle applicazioni, la più grande preoccupazione è che devi mantenere la cache fresca. Quindi, una buona cache distribuita deve consentirti di farlo perché in caso contrario, ti costringe a memorizzare nella cache i dati di sola lettura. I dati di sola lettura sono comunque circa il 10-15% dei tuoi dati. Quindi, come trarrai davvero vantaggio da questa cache se stai memorizzando nella cache solo dal 10 al 15% di ciò che dovresti memorizzare nella cache? Quindi, quello che vuoi fare è memorizzare nella cache tutti i dati, praticamente tutti i dati, pochissimi pezzi di dati sarebbero dove dici che non ha davvero senso memorizzare nella cache. Ma quasi tutti i dati. Alcuni dei dati verranno memorizzati nella cache per un breve periodo. Quindi, una volta memorizzati nella cache quei dati, si tratta di tutti i dati dell'applicazione, la cache più difficile assicura che la cache sia fresca nei diversi modi in cui può farlo, il numero uno sono le scadenze.
Utilizzo delle scadenze basate sul tempo
La scadenza è una scadenza assoluta e c'è una scadenza scorrevole. Hanno 2 significati molto diversi anche se entrambi sono scadenze. La scadenza assoluta è ciò che dovresti fare per mantenere la cache fresca perché stai facendo l'ipotesi che stai dicendo, sto salvando questo oggetto cliente nella cache. Penso che sia sicuro memorizzare nella cache a cinque minuti. Stai solo facendo un'ipotesi basata su, è un'ipotesi plausibile ma è un'ipotesi. Entro cinque minuti speri che nessuno lo modifichi nel database, ma se lo fa, la tua cache non sarà coerente con il database. La scadenza scorrevole, d'altra parte, non ha nulla a che fare con il mantenimento della cache sincronizzata. Ha a che fare con lo sfratto o ha a che fare con la pulizia automatica della cache.
Quindi, sessioni, stai dicendo che quando nessuno ha effettuato l'accesso, dopo 20 minuti di inattività rimuovi la sessione. Quindi, stai facendo come una pulizia. Stai dicendo che la cache per favore puliscila, puliscila per me. Non voglio dover tenere traccia di tutto questo. L'ho messo nella cache, ho specificato per quanto tempo dovrebbe rimanere nella cache anche se nessuno lo sta toccando, dopodiché ripuliscilo. Quindi, obiettivi molto diversi che hai da permanente a scadenza assoluta rispetto a scadenza scorrevole. Quindi, scadenza scorrevole, utilizzeresti per le sessioni per i dati transitori. Scadenza assoluta, da utilizzare per i dati permanenti.
Un altro termine che voglio usare è i dati di riferimento rispetto ai dati transazionali. I dati di riferimento sono dati che non cambiano molto frequentemente, ma cambiano, non sono di sola lettura. è, è la tua tabella dei prodotti il cui prezzo potrebbe cambiare ogni giorno o ogni settimana o qualcosa del genere ma non è così frequente come un oggetto cliente o come oggetto attività o qualcosa o un oggetto ordine. Quindi, i dati transazionali sono ciò che vogliamo memorizzare nella cache. Naturalmente, i dati di riferimento sono un dato di fatto che vogliamo memorizzarli nella cache, ma anche i dati transazionali sono qualcosa da cui otterremo tutti i dati. Quindi, se la scadenza non è sufficiente per garantire che la cache rimanga aggiornata, è necessario disporre di più funzionalità.
Utilizzo delle dipendenze del database
Quindi, la caratteristica successiva, una caratteristica molto potente che deve avere una buona cache distribuita è che dovrebbe essere in grado di sincronizzare la cache con il database senza coinvolgerti, senza dover monitorare le cose. Quindi, dovresti essere in grado di dire alla cache che sto memorizzando nella cache questo oggetto. Questo è correlato a questo set di dati nel database. Quindi, si prega di monitorare questo set di dati nel database. Vedi se cambia, per favore vai e fai una o due cose, rimuovi questo elemento dalla cache, la rimozione significa che la prossima volta che l'applicazione lo vuole, non lo troverà nella cache. Cosa succede quando non lo trovi nella cache? Lo ottieni dal database. Quindi, è come ottenere una nuova copia o un secondo potrebbe semplicemente ricaricare automaticamente una nuova copia. Il ricaricamento di una nuova copia richiede automaticamente un'altra funzionalità chiamata read-through di cui parlerò.
Quindi, tornerò su questo ma sincronizzazione del database è una caratteristica molto molto potente. Questo è ciò che ti dà tranquillità per assicurarti che la tua cache rimanga fresca. Che non dovrai preoccuparti di tutti i dati che stai memorizzando nella cache e ci sono diversi modi per sincronizzare la cache con il database. La più comune è la dipendenza SQL che in realtà è una caratteristica del server ADO.NET o SQL NCache utilizza.
Quindi, ad esempio, ti mostrerò effettivamente il codice che avrei dovuto. Quindi, fammi rapidamente.. Ti mostrerò rapidamente come appare il codice. Dov'è finito? Quindi, se hai un'applicazione .NET, supponiamo che lo sia NCache, ovviamente, faresti riferimento a due di NCache librerie. NCache.Runtime e NCache.Ragnatela. Quindi, come di nuovo, abbiamo provato a nominarlo il più vicino possibile allo spazio dei nomi degli oggetti della cache ASP.NET NCache.Ragnatela. Quando siamo usciti nel 2005, l'oggetto cache ASP.NET era l'unica cache in circolazione, quindi siamo i più vecchi nello spazio, ecco perché abbiamo scelto quel nome per renderlo più facile per le persone. Quindi, all'interno dell'applicazione dovresti includerne un paio NCache spazi dei nomi. Quindi, ti connetteresti con la tua cache, ottieni un handle di cache e ora hai un handle di cache, quindi, diciamo, crei il tuo oggetto e vuoi fare Cache.Add. Quindi, Cache.Add prende una chiave. Notare che la chiave è in realtà una stringa, quindi l'abbiamo seguita. Bene, questo non sta seguendo quella convenzione di denominazione ma di solito è Customer:CustomerID: qualunque fosse l'ID per quel cliente, quindi fai Cache.Add dopo e poi, in questo caso, stai specificando la scadenza assoluta di un minuto. Come dire, non fare alcuna scadenza scorrevole e tutte le altre cose. Quindi, è solo per darti un'idea di come appare una cache.
API molto facile da usare, molto semplice, molto più semplice che fare ADO.NET o qualsiasi altra programmazione.
Che aspetto ha una cache?Lasciami in realtà, lascia che ti mostri effettivamente l'aspetto di una cache ma con una cache reale. Quindi, ho queste macchine virtuali e Azure. Quindi, ho la demo 1 e 2 due. Questi sono due server cache che userò. Queste sono VM cache e avrò il mio server delle applicazioni. Lo chiamerò semplicemente client demo. Quindi, la mia applicazione verrà eseguita sul client demo. Bene! Quindi, ho Desktop remoto in questo. Lo farò in caso di NCache Eseguirò questo strumento chiamato NCache manager, in realtà ce l'ho qui. E andrò avanti e creerò. Fammi solo assicurarmi rapidamente che non ci sia già una cache con quel nome. Bene! Quindi, andrò avanti e creerò una nuova cache. Chiamerò la mia cache demo cache. Prenderò tutto il resto come predefinito. Sceglierò una topologia di memorizzazione nella cache. Non entrerò nei dettagli, ma questa topologia di memorizzazione nella cache esegue sia il partizionamento che la replica contemporaneamente. Quindi, quando esegui questa topologia, la tua cache sarà simile a questa.
Quindi, questi sono i tuoi server cache. Quindi, alcuni dei dati, questo 1 2 3 4 sono gli elementi dei dati. Quindi, alcuni dei dati si trovano nella partizione 1, alcuni dei dati si trovano nella partizione 2 e viene eseguito il backup di ogni partizione su un server diverso. Quindi, se avessi 3 server qui.
Diciamo che avresti la partizione 1 2 e 3, il server 2 ha la replica per la partizione 1, il server 3 ha una replica della partizione 2 e il server 1 ha la replica di una partizione 3. Quindi, la cache in realtà è un server. In realtà è più di un server, che si trova in un cluster. Si conoscono e ora ti riporterò rapidamente a questo. Quindi, diciamo che ho scelto una topologia di replica della partizione. Sceglierò la demo 1 come primo server cache. Perché è così lento? Demo 2 come il mio secondo server cache. Penso che probabilmente sia perché Internet è lento, forse. Non lo so. Quindi, ho un cluster di cache a due nodi. Quindi, la demo uno e due ora si conoscono. Quindi parleranno tra loro su questo porto. Sulla porta 7802 che potrei cambiare. Perché è così lento? Assicurarsi.
Bene! Quindi, il prossimo specificherò quanta memoria dovrebbe avere la cache. Quindi, ha un concerto, probabilmente avrai, come ho detto, 13 concerti o qualcosa del genere. E poi specificherò la politica di sfratto che è stata utilizzata meno di recente. Risparmierò il 15%... Mi dispiace sfrattare il 5% della cache. Questo è davvero lento, non so cosa sta succedendo. L'intera scatola è lenta, anche un clic lo è, anche la CPU no, sì! Sembra così. Si lo è!
Bene! Quindi, in pratica, hai un cluster di server che logicamente sono chiamati cache e li conosci solo da una cache demo. Sulla tua casella, diciamo, sulla tua casella del server delle applicazioni, diciamo NCache è installato qui. Avrai un file di configurazione che avrà quel nome di cache e un elenco di server che lo rappresentano. Quindi, questo è solo un punto di partenza, ma ancora una volta saprai che l'intero cluster è solo un nome di cache e ti connetti ad esso e quindi l'API client si connetterà a tutti i server di cache in questa immagine. In caso di repliche di partizioni, ogni client parla con tutti i server in modo che possa andare direttamente dove si trovano i dati, la parte di partizionamento.
Andrò avanti e aggiungerò un client per questo che è il mio client demo. Andrò avanti e farò clic sull'assistente cache, impiegando molto tempo per fare clic, e dirò di avviare la cache. Quindi, solo dicendo che la cache verrà avviata su entrambe le caselle. NCache è una cache basata su Windows, quindi ha tutte le funzionalità facili da usare di un buon prodotto basato su Windows. Quindi, puoi fare tutto questo da una posizione centrale, tutto questo puoi farlo anche attraverso lo scripting.
Sincronizzazione database - DemoQuindi, lascia che ti mostri come appare la sincronizzazione del database. Quindi, ad esempio, quello che fai è, ancora una volta è lo stesso tipo di applicazione, hai la cache e quando provi ad aggiungere un dato alla cache, diciamo che stai facendo Cache. Aggiungi qui e questo è Certo NCache code, specifichi una dipendenza della cache SQL che è un NCache class ma esegue il mapping sul back-end alla classe di dipendenza SQL del server SQL. E gli passi una stringa SQL che viene quindi utilizzata da NCache per connettersi al database e il server cache ora diventa un client del tuo database. Quindi, ad esempio, se la tua applicazione è qui, diciamo, il tuo codice è in esecuzione qui, hai appena emesso questa chiamata. Oops scusa! Hai appena emesso questa chiamata di cache quell'annuncio e passi questa dipendenza dalla cache SQL. Il client invia tutto questo al server cache.
Quindi, uno dei server cache o più. E il server cache ora apre una connessione al database perché hai specificato una stringa di connessione anche qui. E, questa forza di connessione è ovviamente il pool. Così. se più volte specifichi la stessa stringa di connessione, c'è un pool di connessioni sul back-end. Quindi, un'altra cache ora è diventata un client del tuo database. Monitorerà il tuo database in modo che il database avviserà il NCache server che questi dati sono cambiati che mi hai chiesto di monitorare e il NCache il server in quel momento può decidere se rimuovere quell'elemento dalla cache o ricaricarlo dal database. E, per ricaricarlo, devi effettivamente passare attraverso la funzione di lettura.
Bene! Quindi, questo è un modo per farlo. È davvero potente. È guidato dagli eventi. Non appena si verifica la modifica, il database notifica la cache, la cache esegue immediatamente l'azione. Tuttavia, c'è un sovraccarico su questa estremità del server di database perché ogni volta che si esegue una dipendenza dalla cache SQL, è necessario creare una struttura di dati all'interno del server SQL per monitorare quel set di dati. Ora, se ne avessi 1 milione, posso garantirti che il tuo server SQL andrà in crash. Quindi, ancora una volta, dal momento che stiamo parlando di scalabilità, devi pensare in termini di numeri davvero grandi. Quindi, se ne hai migliaia o decine di migliaia, nessun problema. Ma se ne hai centinaia di migliaia o milioni, una strategia diversa sarebbe una strategia migliore.
Dipendenza dal databaseUn'altra strategia è chiamata dipendenza da DB che è la nostra NCache caratteristica che è una dipendenza basata sul polling. Abbiamo implementato questo dove. C'è una tabella speciale e ti chiediamo di modificare i trigger in modo da poter aggiornare il flag in quella tabella per quella riga corrispondente e quindi ogni volta che esegui una dipendenza DB dalla cache, la cache crea una voce in quella tabella e quindi in un recupero , la cache può recuperare migliaia di righe in cui il flag è true, l'aggiornamento è avvenuto. Quindi, è come il nostro modo di tenere traccia. È basato su polling, quindi non è istantaneo. Per impostazione predefinita, un ritardo di circa 15 secondi, ma puoi riconfigurarlo. Non vuoi nemmeno tirare troppo frequentemente. Quindi, questo è l'altro, ma anche lì hai dei limiti, e se avessi 1 milione di righe in quella tabella con un flag di vero e falso, l'indice sembrerebbe piuttosto grande, giusto? C'è un vero e c'è un falso indice, quelli sono i due nodi di un albero. Quindi, la dipendenza da DB è più efficiente della dipendenza da SQL ma non in tempo reale, ma ha anche dei limiti.
Procedure CLRIl terzo sono le procedure CLR in cui puoi effettivamente chiamare una procedura CLR da un trigger nel database, quindi ogni volta che un elemento viene aggiunto, aggiornato o eliminato, chiami la procedura. La procedura effettua una chiamata Async alla cache. Dice per favore aggiungi o aggiorna o elimina questo elemento dalla cache. Il motivo per cui Async è fondamentale è perché non si desidera ritardare la transazione, la transazione del database. In caso contrario, comincerà a scadere. Quindi, una chiamata Async ritornerà immediatamente e almeno la transazione del database può essere confermata e la cache può essere aggiornata. Quindi, la sincronizzazione della cache con il database è una caratteristica fondamentale.
Sincronizza cache con non relazionale
Devi avere quello e la stessa cosa se hai non relazionali o potresti avere mainframe o legacy o qualsiasi altra fonte di dati, potresti avere un'origine dati cloud, potresti voler effettuare chiamate a un metodo Web per verificare anche se quei dati è aggiornato o meno e NCache ti consente di avere questa funzione di dipendenza personalizzata in cui è il tuo codice che può monitorare NCache, chiama il tuo codice ogni piccolo intervallo, vai a monitorare la tua fonte di dati per vedere se quei dati sono cambiati, se ti ha avvisato NCache ed NCache rimuoverà o ricaricherà di nuovo allo stesso modo.
Trattamento dei dati relazionali
Quindi, mantenere la cache fresca è fondamentale. Qualsiasi cache che non ti permetta di farlo, limita la tua capacità di trarne vantaggio. Salterò la gestione dei dati relazionali anche se, anche se non lo è e cosa, lasciatemelo dire rapidamente, avete relazioni uno-a-molti, relazioni uno-a-uno. Quindi, se hai un elemento nella cache e molti elementi anche nella cache, quando rimuovi un elemento nella cache logicamente anche i molti elementi dovrebbero essere rimossi perché cosa succede se lo hai eliminato dal database. Quindi, la cache dovrebbe essere in grado di tenere traccia di tutto questo. Potresti farlo nella tua applicazione ma complica solo il credito dell'applicazione perché ora stai facendo molta contabilità per la cache. È come se stessi compilando la sincronizzazione del database o il codice di integrità dei dati all'interno dell'applicazione che non è il lavoro della tua applicazione. Non lo fai per il database. Il database lo fa per te, quindi anche la cache dovrebbe farlo per te.
Read-thru e Write-thru
Quindi, read-through, write-through è un'altra funzionalità molto potente che dovrebbe avere la tua cache. La lettura è fondamentalmente, ancora una volta, il concetto è molto semplice.
Si implementa un'interfaccia, in caso di NCache implementi un'interfaccia chiamata provider read-through, proprio qui. Puoi vedere che?
Sì e ha tre metodi. C'è un Init che viene chiamato all'avvio della cache in modo da poterti connettere all'origine dati. C'è uno smaltimento quando la cache si ferma, puoi fare la tua pulizia e la maggior parte delle volte chiamerai questo carico dal sorgente. Quindi, passa la tua chiave. La chiave è la tua chiave per sapere quale elemento nell'origine dati recuperare e quindi restituirlo, in caso di NCache un elemento della cache del provider. E puoi specificare le scadenze e risincronizzare alla scadenza, tutti i tipi di flag qui e poi passarlo a NCache. NCache lo memorizza nella cache.
Quindi, come funziona il read-through? Il modo in cui lavoriamo è che la tua applicazione chiede sempre la cache. Dice Cache.Get. Se la cache non ha i dati, invece di dire che non li ho, va a prenderli dal database. Quindi, la tua applicazione diventa improvvisamente molto più semplice. Gran parte del codice di persistenza l'hai appena rimosso dalla tua applicazione. Quindi, un vantaggio del read-through è che hai in qualche modo semplificato il codice, hai incapsulato tutto nel livello di memorizzazione nella cache. Il livello di memorizzazione nella cache ora ha sempre più livello di persistenza. Non tutto il codice può essere eseguito tramite read-through, ma molto può esserlo.
Ricarica alla scadenza
Il secondo vantaggio del read-through è quello di cui ho parlato prima, ovvero la funzione di ricarica. Ora immagina, se hai un'applicazione di e-commerce e il tuo prezzo cambia e ogni volta che cambia il prezzo quegli articoli devono essere rimossi dalla cache e ricaricati ma è davvero un traffico intenso, quindi mentre vengono rimossi, molte richieste dei clienti verranno soddisfatte la banca dati. Il primo lo recupererà e lo metterà nella cache, ma fino a quel momento la cache ha improvvisamente molto traffico non necessario e se continua a succedere, se succede molto, il database riceverà molti hit non necessari che avresti potuto evitare se avessi detto di ricaricare alla scadenza. Quindi, ricarica una scadenza, cosa fa? Non rimuove l'articolo alla scadenza. Lo ricarica semplicemente in modo che quando si verifica la scadenza, la cache chiamerà il read-through e andrà a prenderlo dall'origine dati e si aggiornerà. Quindi, c'è solo un'operazione di aggiornamento in corso. Non ci sono operazioni di rimozione e aggiunta e per questo motivo i dati o l'elemento sono sempre nella cache. Quindi, la cache ora diventa improvvisamente. Può prendersi cura di se stesso e può ricaricarsi ogni volta che i dati devono essere ricaricati.
Scrivere attraverso
Quindi, questa è una capacità di lettura davvero potente. Quindi, quando lo combini con la scadenza e puoi farlo anche con la sincronizzazione del database. Quando si verifica la sincronizzazione del database, di nuovo, perché rimuoverlo? Basta ricaricare. L'altra caratteristica è il write-through che funziona proprio come un read-through tranne per la scrittura. C'è un'altra cosa che fa, può anche scrivere in blocco. E il motivo per cui scrive in blocco lo spiegherò tra un po'. Quindi, allo stesso modo c'è un Init, c'è un'eliminazione e ora c'è una scrittura nelle origini dati. La scrittura non significa solo aggiungere o inserire. Potrebbe anche essere eliminato in modo che la scrittura abbia un tipo di operazione che può quindi essere aggiunta, aggiornata o rimossa. E questo dipende da quale era l'operazione di cache. E poi puoi anche farlo in blocco. Quindi, il write-through ha gli stessi vantaggi del read-through in termini di semplificazione del codice, ma ha ancora un vantaggio in più. Quindi, il read-through ha il vantaggio di ricaricare il write-through ha il vantaggio di poter scrivere dietro.
Scrivi dietro
E il write-behind è una funzionalità molto molto potente. Come mai? Perché gli aggiornamenti del database sono un collo di bottiglia. Ancora una volta, il database è quel male necessario con cui devi convivere. Non puoi vivere senza di esso, ma sta causando ogni sorta di collo di bottiglia nella tua applicazione. Quindi, meno puoi dipendere da esso, migliore è la tua applicazione. Il fatto che non puoi vivere senza di esso devi ancora averlo. Quindi, cosa fa un write-behind? Dice che aggiorni la cache che è super veloce, almeno dieci volte più veloce del database se non di più, e quindi la cache si occupa dell'aggiornamento del database. Quindi, c'è un write-through asincrono, che è un write- behind. Quindi, andrai ad aggiornare la cache, tornerai e continuerai le tue cose e la cache andrà ad aggiornare il database.
Naturalmente, ci sono molti problemi che la cache deve affrontare. Non appena dici che la cache deve aggiornare il database, cosa succede se il server della cache si arresta in modo anomalo? Cosa succede a quella coda? Quindi, in caso di NCache, la coda stessa viene replicata su più server se un server si interrompe non si perde la coda. Poi ci sono anche i tentativi. Cosa succede se l'aggiornamento non riesce, puoi riprovare. Puoi anche eseguire l'aggiornamento in batch. Quindi, ce ne sono un sacco che puoi eseguire un aggiornamento in blocco. Quindi, può ottimizzare ulteriormente le cose. Quindi, write-through e read-through sono funzionalità molto molto potenti. Questo è chiamato codice lato server. Questo è il tuo codice che risiede nel cluster di cache. Vive qui e mantenere quel codice sul server semplifica la tua app. Quindi, più codice si spinge verso il basso, più semplice diventa l'applicazione.
Raggruppamento di dati
Bene! Ora che, diciamo, sei convinto che dovresti usare la memorizzazione nella cache. Hai i diversi casi d'uso in cui ora sei sicuro di memorizzare nella cache molti dati. Quindi ora, la cache ha iniziato ad assomigliare al database. sta iniziando ad avere molto, Avrai milioni di elementi nella cache. Quindi, quando hai milioni di elementi nella cache, è utile leggere semplicemente le cose in base a una chiave? No! se l'unico modo per leggere gli elementi dalla cache in base alla chiave, la tua applicazione sarebbe molto molto impegnativa rispetto a se potessi fare cose, beh, dammi tutte le cose in base a questi criteri di ricerca.
Quindi, la ricerca e il raggruppamento diventano un'esigenza molto potente o un'esigenza molto importante di una cache. Ancora una volta, come ho detto, lo scopo è che tu capisca quali sono i vantaggi. Il vantaggio è se puoi memorizzare nella cache sempre più dati. Più dati si memorizzano nella cache, più è necessario vederli o disporre di più funzionalità del tipo di database. Una di queste caratteristiche è essere in grado di creare metadati. Nel database puoi avere indici su molti attributi diversi. Qui puoi fare tag, tag con nome e effettivamente quando metti nella cache gli oggetti, in caso di NCache ti permette anche di creare indici. Quindi, puoi indicizzare un oggetto. Supponiamo che un cliente possa essere indicizzato sull'attributo della città perché cercherai sulla città, quindi dovrebbe essere indicizzato. Se non è indicizzato, la ricerca sarà davvero dolorosa. Immagina milioni di articoli che devi prima deserializzare per ispezionare ogni oggetto solo per sapere quali clienti a Orlando. Non è una bella foto, non è una bella vista.
Quindi, raggruppare di nuovo i tag di sottogruppi e i tag del nome da una prospettiva di codifica molto semplice. Ti mostrerò rapidamente questo. Dal punto di vista della registrazione molto facile da usare. Aggiungi un mucchio di oggetti e gli assegni dei tag e poi, mi dispiace! gruppo e sottogruppo, gruppo sottogruppo e poi dici ottieni i dati del gruppo oppure puoi anche eseguire una ricerca SQL e dire dammi tutto l'oggetto prodotto in cui il nome del gruppo è l'elettronica. Quindi, anche il raggruppamento e il sottogruppo di tag e tag sono qualcosa che AppFabric fornito, tra l'altro AppFabric verrà interrotto a febbraio. Abbiamo più minuti per accelerare.
Trovare i dati
Ancora una volta, la ricerca dei dati è correlata al raggruppamento dei dati che desideri essere in grado di cercare i dati in base a SQL, quindi penso di... dov'è il linguaggio di query degli oggetti? Eccolo. Quindi, in pratica, ho un sacco di dati e potrei emettere un'istruzione SQL e posso specificare più attributi e passare parametri e otterrò un record impostato in caso di NCache e proprio come il server SQL, anche se è un sottoinsieme dell'SQL completo. Non esegue giunzioni ma invece di unire puoi raggruppare e contrassegnare ed è così che puoi raggruppare più oggetti insieme.
Quindi, nel caso di LINQ, NCache ha implementato un provider LINQ in modo che l'interfaccia Iqueryable. Vai a prendere quella collezione da NCache e quindi esegui una query LINQ proprio come fai con qualsiasi altra raccolta di oggetti e andrà avanti e ti restituirà una raccolta di questi oggetti, gli oggetti del prodotto. Quindi, se LINQ è la tua zona di comfort in termini di ricerca, usa LINQ per cercare. Quando emetti questa query, andrai al cluster in cui la stessa query verrà inviata a tutti i server e i risultati verranno e verranno uniti e quindi mostrati. Quindi potrebbe, anche se qui sembra molto semplice, dietro le quinte c'è molto lavoro da fare NCache.
Quindi, abbiamo SQL e LINQ. Abbiamo anche bulk e, come ho detto, puoi fare l'indicizzazione.
Condivisione dei dati di runtime
Sto solo andando molto velocemente... ci sono eventi basati su chiavi, ci sono eventi a livello di cache, ci sono eventi secondari pub, c'è una query continua.
La query continua è una funzionalità simile a una funzionalità di dipendenza SQL, tranne per il fatto che si trova nella cache. Stai chiedendo alla cache di monitorare un set di dati per te. Quindi, proprio come stavamo usando la dipendenza SQL e chiedendo al server SQL di monitorare questo set di dati e dicendo se questo set di dati cambia, per favore avvisami. Ora, stai chiedendo NCache, dicendo per favore, ecco la mia istruzione SQL, seleziona i clienti in cui Customer.City è uguale a New York e stai dicendo se un cliente che corrisponde a questi criteri viene aggiunto, aggiornato o eliminato dalla cache, avvisami e potrebbe essere qualsiasi posto su la rete, qualsiasi punto del cluster di cache e potresti essere qualsiasi altro client. Sarai avvisato. Quindi, avendo questi tipi di funzionalità ora puoi monitorare improvvisamente cosa sta succedendo alla cache ed essere avvisato invece di eseguire il polling delle cose ed è quello che stavo dicendo che la cache diventa una piattaforma di condivisione dei dati di runtime davvero potente.
Alta disponibilità
Bene! Salterò anche questo. Voglio dire, qualsiasi cache che usi deve avere dinamica. Deve fornire un'elevata disponibilità che in caso di NCache, ha un'architettura peer-to-peer.
Cache cliente
C'è una funzione che voglio che tu sappia che si chiama cache del cliente. Alcune persone lo chiamano vicino alla cache.
Questa è in realtà una cache che si trova localmente nella casella del server delle applicazioni. È come una cache autonoma, tranne per il fatto che non è autonoma. Quindi, può anche essere InProc. Può essere all'interno del processo di applicazione che significa che stai effettivamente recuperando le cose come nell'heap degli oggetti. Il tuo heap ha dati in forma di oggetto. Niente batte quella performance, giusto? Se puoi semplicemente ottenere quei dati dall'heap anziché andare in una casella locale della cache OutProc perché quando attraversi i processi deve passare tramite IPC, deve eseguire la serializzazione, la deserializzazione, quando attraversi la rete è ancora di più, quando vai al database è incredibilmente costoso, comparativamente.
Quindi, questa è una cache locale all'interno del processo di applicazione o localmente sulla scatola. Ma rimane sincronizzato. Non si esegue alcuna programmazione API speciale per la cache del client. Basta effettuare le chiamate alla cache, in caso di NCache, si collega semplicemente alla modifica della configurazione e intercetta le chiamate e qualsiasi cosa tu stia recuperando ne conserva una copia in locale. Quindi, la prossima volta che lo recuperi, lo riceverà automaticamente dalla cache locale. Enorme aumento delle prestazioni. Questo è qualcosa che solo NCache ha sul lato .NET. Sul lato Java, ci sono altri prodotti che hanno la cache del client ma su .NET ha detto che questo è solo. È come una cache sopra una cache e questo è il motivo per cui molte persone, quando passano dalla cache InProc standalone a una cache distribuita, si lamentano, le mie prestazioni sono effettivamente diminuite, la mia applicazione è più lenta, pensavo che la cache distribuita fosse dovrebbe aumentare le mie prestazioni e diciamo loro di no, dovrebbe aumentare la scalabilità. Niente corrisponde a una cache InProc locale, nessuno può. Voglio dire, questo non è qualcosa che possiamo inventare e fare qualcosa. Stai attraversando processi, questo è un costo in quanto necessario.
Quindi, diciamo bene, un modo per superare questa sfida è utilizzare una cache client. Quindi, una cache client è di nuovo un sottoinsieme. Di solito, avresti da 16 a 32 giga in ciascun server cache. Quindi, se hai da tre a quattro server, hai potenzialmente circa cento giga di dati memorizzati nella cache e la cache del client forse un giga, forse due giga, forse tre o quattro giga, massimo ciascuno e dipende da quanti lavoratori elabora avere. Se hai un solo processo di lavoro, fallo quattro giga. Se hai otto processi di lavoro, che molti dei nostri clienti di fascia alta hanno nel loro livello Web, non vuoi avere quattro per otto solo nella cache del client. Quindi, forse, è bene avere una cache di processo da quattro giga fuori produzione che è comunque meglio che passare al livello di memorizzazione nella cache. È ancora più veloce oppure puoi avere un gig più piccolo o meno di un gig cache che è InProc. Ora ne hai otto copie, ma sono anche sincronizzate. Quindi, sicuramente una cache client è qualcosa che devi considerare di utilizzare se hai intenzione di ottenere il valore da una cache.
Ora, il mio obiettivo e questo non è di venderti alcuna funzionalità di cache, ma di dire cosa deve avere una buona cache e molte di queste funzionalità troverai sul lato Java. Java è un mercato molto più maturo dal punto di vista della memorizzazione nella cache. Usano la parola griglia dati in memoria invece di cache distribuita, ma qualunque sia la funzione con cui vedi NCache, ne vedrai molti anche sul lato Java, ma sul lato .NET NCache è l'unico.
Replica WAN
Un'altra caratteristica è che, se disponi di più data center, vorresti che il tuo database venisse replicato, quindi perché non la cache? Che cosa hai intenzione di fare? Ricostruirai l'intera cache? E il carrello? E le sessioni? Quindi, più data center sono una realtà e il cloud lo ha reso ancora più semplice perché non c'è nessuno sforzo da parte tua. Devi solo dire regione uno e regione due e hai due data center, giusto? Ma il problema di fondo non scompare, ovvero se utilizzi una cache distribuita che non supporta la replica WAN, sei bloccato. Non puoi avere una soluzione attiva-attiva o anche attiva-passiva, multi data center senza che la cache venga replicata, quindi una caratteristica molto importante.
NCache ovviamente ha questo. Ti ho già dato la demo pratica. NCache è la cache .NET più vecchia sul mercato. Siamo stati lanciati nel 2005, molto più vecchi.
NCache vs Redis
Quindi, vado rapidamente oltre NCache Redis, livello molto molto alto e questo perché Redis è un sacco di persone che vengono e ci chiedono come ti confronti Redis dal momento che Microsoft li ha scelti per Azure.
Redis, è un ottimo prodotto. È super veloce. Viene principalmente dal lato Linux. Non ha molte funzioni. Non vince sulle funzionalità. Vince solo per il fatto che proveniva dal lato Linux e Microsoft voleva conquistare il mercato AWS in modo da non poter adottare una soluzione .NET. Hanno dovuto adottare, multipiattaforma. Quindi, la loro versione Linux è molto stabile, molto buona, ma la porta Windows che Microsoft ha fatto da sola è una specie di porta orfana. Microsoft non lo usa da soli. Quando sei in Azure e usi Redis, non stai utilizzando la porta Windows di Redis, stai usando la versione Linux. Quindi, se non sei su azzurro e utilizzerai la porta di Windows di Redis, attenzione. Voglio dire, nessuno lo possiede. Redis labs, se visiti il loro sito Web, non hanno nemmeno un download di Windows. Voglio dire, hanno solo download di Linux di cui è il creatore Redis. Microsoft, come ho detto loro stessi, non ha messo i soldi dove erano le loro bocche in termini di utilizzo dell'impegno.
Così, NCache è l'unica opzione praticabile per te ed è open source, quindi se non hai i soldi, scegli la versione open source gratuita. Se il tuo progetto è importante e desideri supporto e più funzionalità, quali sono le funzionalità aziendali. L'impresa NCache è costruito sulla base dell'open source. Non è come una cosa separata. L'open source non è orfano. Voglio dire, lo possediamo, lo manteniamo e l'impresa è costruita in cima. Quindi, l'open source deve essere stabile, ma se desideri supporto e più funzionalità, acquista l'Enterprise Edition.
Siamo .NET nativi. Abbiamo sviluppato in c-sharp e abbiamo la certificazione Windows Server 2012 r2. Presto avremo anche il prossimo. Quindi, intendiamo dire che non siamo in cima al gioco per quanto riguarda Microsoft. Siamo praticamente .NET, ecco cosa siamo. Abbiamo un client Java ma quasi tutti i nostri utilizzi Java da parte dei clienti che acquistano NCache per .NET e poiché lo hanno internamente lo usano anche da Java. Quindi, il nostro pane quotidiano, la nostra intera sopravvivenza è su .NET. Quindi, saremo sempre gli ultimi e i più grandi, i primi e i più facili.