Campo del codice di Boston 27
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
Mi chiamo Iqbal Khan. Sono un evangelista della tecnologia presso Alachisoft. Siamo una società di software con sede nella Baia di San Francisco. Sono personalmente residente a Tampa ma abbiamo chiamato questo prodotto NCache. È una cache distribuita .NET. Oggi parlerò di come è possibile ridimensionare le applicazioni .NET con la memorizzazione nella cache distribuita. Non si tratta di un discorso NCache, si tratta del problema della scalabilità e di come risolverlo con la cache distribuita. Cosa dovresti fare? Come dovresti usarlo? Quali sono alcune delle migliori pratiche? Se avete domande, sentitevi liberi di fermarmi. In modo che possiamo avere una discussione più interattiva. Fammi iniziare.
Che cos'è la scalabilità?
Quindi, togliamo alcune definizioni di mezzo. Il numero uno è la scalabilità. La scalabilità non è prestazioni. Potresti avere un'applicazione che funziona davvero bene con cinque utenti, ma è scalabile solo se funzionerà allo stesso modo con 5,000 o 50,000 o 500,000 utenti. Quindi, la scalabilità è davvero ad alte prestazioni con carichi di picco. Se la tua applicazione non funziona bene con 5 utenti, devi partecipare ad altri colloqui.
Scalabilità lineare e scalabilità non lineare
La scalabilità lineare è più un concetto di distribuzione dell'applicazione. Quando distribuisci la tua applicazione, se puoi aggiungere più server alla distribuzione e aggiungendo più server se puoi aumentare la capacità di transazione in modo lineare, l'architettura dell'applicazione è scalabile linearmente, altrimenti è scalabile non lineare.
Ciò significa che dopo un certo numero di server, l'aggiunta di più server in realtà peggiora le cose, ciò significa che ci sono alcuni colli di bottiglia da qualche parte nell'applicazione che non vengono risolti semplicemente aggiungendo più server. Sicuramente non vuoi la scalabilità non lineare e vuoi sicuramente la scalabilità lineare nella tua applicazione.
Che tipo di applicazioni necessitano di scalabilità?
Che tipo di applicazioni necessitano di scalabilità? Queste sono applicazioni ASP.NET. Questi sono servizi web. Questi sono back-end IOT che sono ancora per lo più servizi web. Queste sono applicazioni di elaborazione di big data, che non sono così comuni in .NET, sempre più vengono eseguite in Java, ma comunque queste sono le applicazioni che richiedono anche scalabilità e qualsiasi altra applicazione server. Ad esempio, potresti lavorare per una grande banca che ha milioni di clienti e loro, sai, i clienti chiamano per apportare modifiche all'indirizzo o forse vogliono che venga emessa una nuova carta o forse stanno trasferendo fondi da una conto all'altro e tutte queste transazioni devono essere elaborate entro un periodo di tempo predeterminato ai fini della conformità. Quindi, devi ancora gestire milioni di richieste in un lasso di tempo che potresti non essere in grado di fare da un singolo computer. Quindi, devi essere in grado di ridimensionare anche in quel caso. Quindi, se hai una di queste applicazioni che necessita di scalabilità, allora questo è il discorso giusto, a cui sei arrivato.
Il problema della scalabilità
Quindi, definiamo anche il problema della scalabilità. Qual è il problema della scalabilità? Bene, il livello dell'applicazione si ridimensiona in modo lineare. Potresti avere un'applicazione web ASP.NET o servizi web. Avrai davanti un sistema di bilanciamento del carico che indirizzerà il traffico in modo uniforme a tutti i server. Puoi aggiungere più server, nessun problema. Tutto funziona perfettamente bene. Stavo parlando con qualcuno in precedenza del fatto che il database stava diventando un collo di bottiglia e non erano d'accordo con me. Quindi, penso che questa sia una buona opportunità per avere quella discussione.
Quindi, il database stesso funziona in modo super veloce. Non ci sono problemi con le prestazioni. I database sono molto intelligenti, eseguono molto la memorizzazione nella cache nel proprio server, ma la scalabilità è qualcosa che non possono ottenere in base alla progettazione perché puoi aggiungere, ad esempio, puoi aggiungere 10, 20, 30, 40, 50 server a questo livello. Abbiamo clienti con 50 o più server nel loro livello applicazione perché hanno così tanti utenti. Immagina di essere una grande banca o una compagnia aerea. Hai milioni di persone che stanno visitando il tuo sito web. Hai fatto questa importante promozione per un biglietto per le Hawaii o qualcosa del genere. Verranno tutti, faranno la ricerca del volo, vogliono comprare i biglietti. Puoi aggiungere più server qui senza problemi. Il database funzionava in modo super veloce e il software è eccezionale, ma in base alla progettazione il database non è un database distribuito. È tenuto in un posto. Forse puoi avere un cluster di due server, attivo-attivo, attivo-passivo, ma sono più per l'affidabilità che per la scalabilità, in realtà.
Quindi, non puoi davvero avere 10 server qui, a meno che non sia un NoSQL database, allora puoi. Ma per un database relazionale qualcuno di loro potrebbe essere SQL Server, Oracle, Db2, MySQL, sono super veloci. Potrebbero anche fare molto nell'elaborazione della memoria, ma diventeranno il collo di bottiglia poiché è necessario ridimensionare sempre di più. E fondamentalmente, quando hai migliaia o più utenti simultanei o simultanei, inizi a notare problemi di prestazioni e man mano che aumenti da 1,000 a 5,000, da 5,000 a 10,000, è qui che inizi a vedere di più. Quindi, quello che abbiamo visto è, sai, quando se hai 1000 utenti puoi o meno usare la memorizzazione nella cache ma man mano che cresci fino a 5,000, 10,000, 15,000 utenti, senti sicuramente il dolore e finisci con queste scalabilità colli di bottiglia.
Ora i database relazionali o i database legacy mainframe hanno questo problema. È uno dei motivi NoSQL databaseIl movimento iniziato è stato per quello. Tuttavia, ha anche altri vantaggi e abbiamo un prodotto. Vorrei solo venire rapidamente a scopo di riferimento. Quindi, abbiamo un prodotto di memorizzazione nella cache ma abbiamo anche a NoSQL banca dati dei documenti. Proprio come document DB è un database open source.
Così, NoSQL database sicuramente non ha problemi di scalabilità. Ma non è sempre la risposta. Perché? Perché perché sia una risposta, a NoSQL database vuole che tu memorizzi tutti i dati al suo interno. Quindi, a meno che non memorizzi i tuoi dati in a NoSQL database il che significa che smetti di utilizzare il database relazionale per almeno quella parte dei dati, non risolverà il tuo problema. Quindi, in molti casi puoi spostare alcuni dati, molti dati in a NoSQL database ed è quello che sta guidando il NoSQL movimento. Ma i database relazionali, i dati mainframe legacy, sono qui per restare. Non sono qualcosa che puoi semplicemente desiderare sia per motivi tecnici che di lavoro. Quindi, qualunque sia il problema di scalabilità che devi risolvere, devi risolverlo con i database relazionali nell'immagine. Ecco perchè NoSQL database non è sempre la risposta.
La soluzione: cache distribuita in memoria
E il modo in cui risolvi questo problema è che si tratta di una nuova best practice emersa negli ultimi cinque o dieci anni circa, che è la cache distribuita in memoria. Alcune persone chiamano anche quella griglia di dati in memoria. Microsoft chiamava il data fabric. Anche se continuano a cambiare le loro definizioni. Ma è un archivio chiave-valore distribuito in memoria ed è ora una parte essenziale della tua architettura. Se vuoi un'applicazione scalabile, devi programmare, devi sviluppare le tue applicazioni pensando a una cache distribuita. In questo modo puoi assicurarti che l'applicazione non diventi mai un collo di bottiglia.
Ora che cos'è una cache distribuita? Si tratta essenzialmente di due o più server a basso costo. Questi non sono server di database di fascia alta, sono scatole di tipo server web. Di solito una doppia CPU, una configurazione a 8 core è piuttosto tipica. 16 giga di RAM sono praticamente nella media. Vediamo da 16 a 32 giga come il punto debole della memoria. Più di 64 giga, non lo consigliamo nemmeno ai nostri clienti. Diciamo di aggiungere un'altra scatola invece di rendere questa scatola più forte. Perché, se aggiungi più di 64 giga, un'applicazione .NET ha questa cosa chiamata Garbage Collector che richiede molta potenza di elaborazione. Quindi, più memoria hai, più veloce deve essere la CPU affinché il Garbage Collector sia in grado di raccogliere tutta quella memoria.
Quindi, è meglio avere più server che avere pochi server davvero di fascia alta. Minimo 2 ovviamente, perché vuoi affidabilità. Nel caso in cui un server si interrompa ma poi dopo quel rapporto 4 a 1 o 5 a 1, quindi, di solito avresti, diciamo, 2, 3, 4 o 5 server nel livello dell'applicazione. Il più comune che vediamo è tra 4 e 10 e poi ovviamente ci sono molti clienti che usano più di 10, ma 4 e 10 è praticamente quello che vediamo come questo punto debole. E per questo usi un cluster di 2 server. Man mano che cresci più di 10 o 12, ne aggiungi un terzo o un quarto e così via. E, poiché una cache distribuita è un archivio di valori chiave, è distribuita. Replica i dati su più server in modo intelligente, in modo da ottenere affidabilità ma allo stesso tempo non dedicare molto tempo alla replica. Ad esempio, se ogni pezzo di dati dovesse essere replicato su tutti i server, sarebbe un'enorme quantità di elaborazione aggiuntiva che non sarebbe necessaria. Quindi, è quel tipo di replica intelligente che deve fare. A volte, è necessario avere la replica in quel modo, ma si tratta di casi specializzati. Quindi, una cache distribuita quando è presente, ci andrai circa l'80% delle volte. Tutte le letture verranno eseguite da esso e tutti gli aggiornamenti e alcune letture verranno eseguiti sul database e anche sulla cache. Quindi, se riesci a intrappolare circa l'80% del traffico del tuo database nella tua cache, improvvisamente il tuo database è molto leggero. Non ha molto da fare. Quindi, qualunque cosa debba fare, lo farà molto più velocemente. Quindi, le prestazioni miglioreranno così come la scalabilità.
Questa cache di distribuzione in memoria, indipendentemente dal fatto che sia NCache, se è così Redis sul lato .NET, sul lato Java ci sono più giocatori, qualunque prodotto tu scelga, la cache distribuita è praticamente una best practice data ora. Devi incorporarlo nella tua architettura.
Qualche domanda su questo finora, prima di andare avanti? Quindi, sì, una cache logica può estendersi su più server. In caso di NCache puoi avere più cache sugli stessi server. Pertanto, ogni cache diventa il proprio contenitore a fini di isolamento, ma qualsiasi cache può estendersi su tutti e cinque i server. Quando dico span, significa che alcuni dati si trovano su un server, alcuni sugli altri, sai, e quindi la replica è una parte separata di esso che può essere eseguita o meno a seconda delle tue preferenze. Ma sì, tutti i server vengono utilizzati per archiviare quella cache e la cache deve essere coerente. Deve essere sempre corretto o puoi dire che alla fine deve essere corretto ma abbastanza vicino ad essere sempre corretto. Qualunque cosa memorizzi nella cache, se aggiorni, non ti interessa dove si trovano i dati, probabilmente non sai nemmeno dove si trovano. Tutto quello che sai è che questo cluster ha i miei dati e ogni volta che recupero, potrei averlo archiviato da questo server e sto cercando di leggerlo qui subito dopo e dovrei essere in grado di ottenere la stessa copia. Se posso farlo, diventa una cache coerente o coerente. Quindi, l'integrità dei dati per gli aggiornamenti garantisce sempre.
Questa è la tua preferenza e ne parlerò più in dettaglio in termini di come usi effettivamente la cache. Quindi, una cosa che dovresti ... Voglio dire, l'obiettivo principale di fino ad ora è convincerti che se vuoi la scalabilità devi averla come parte della tua architettura.
Usi comuni della cache distribuita
Quindi, ora che abbiamo, diciamo, siamo d'accordo sul fatto che hai bisogno di una cache distribuita, la prima domanda che ti viene in mente è come la usi? Dove lo usi? Per cosa lo usi? Quali dati sono conservati al suo interno e tutte le questioni relative a tali dati.
Memorizzazione nella cache dei dati dell'applicazione
Quindi, ci sono tre casi d'uso di alto livello. Il numero uno è l'Application Data Caching, di cui stavo parlando, ovvero hai dati nel database, li prendi e li metti nella cache. Quindi, nella memorizzazione nella cache dei dati dell'applicazione l'obiettivo è... ma ho appena detto che non si desidera accedere così tanto al database, si desidera ridurre il traffico del database in modo che l'applicazione si ridimensioni. Ma i dati ora esistono in due posti. Esiste nella cache ed esiste nel database. Quindi, ogni volta che i dati esistono in due posti, qual è la prima preoccupazione che viene in mente? Sincronizzazione tra i due. Quindi, è coerente? Perché, se i dati non saranno coerenti, sarai limitato a utilizzare la cache per i dati di sola lettura. In effetti, la maggior parte delle persone quando chiedi loro, per cosa usi una cache? La reazione istintiva è dati di sola lettura. Sai, non mi sento a mio agio nell'usare la cache per i dati che cambieranno davvero, sai, in tempo reale o in fase di esecuzione. Ma, se non puoi utilizzare la cache per i dati transazionali che uso il termine per i dati che cambiano frequentemente, quei dati sono probabilmente dall'80% al 90% dei tuoi dati. Quindi, ciò significa che dall'80% al 90% delle volte non puoi nemmeno usare la cache e se non puoi nemmeno usare la cache, diventa proprio come un NoSQL database. Non è sempre la risposta, lo sai. E vuoi che sia la risposta, quindi sai, quindi una buona cache distribuita deve darti la certezza che qualunque cosa tu metta nella cache sarà coerente con il database. In caso contrario, quella cache non è la cache giusta per te. Quindi, questa è la prima cosa, questo è il primo caso d'uso.
Memorizzazione nella cache specifica di ASP.NET
Il secondo caso d'uso è, se si dispone di applicazioni ASP.NET.
- Memorizzazione nella cache della sessione ASP.NET
Puoi memorizzare le tue sessioni nella cache. Sai, le sessioni sono qualcosa che hanno quasi tutte le applicazioni ASP.NET. Vengono mantenuti in modalità In-Proc o in modalità SQL Server. Il server SQL non è il posto giusto per mantenere le sessioni per due motivi, uno ovviamente che, il primo motivo è che più si conservano i dati nel database, maggiore è il collo di bottiglia della scalabilità. Il secondo è che le sessioni vengono mantenute come BLOB e i database relazionali non sono stati realmente progettati per i BLOB. Sono stati progettati per dati più strutturati che puoi indicizzare e cercare. Considerando che, una cache distribuita il valore della chiave, il valore è sempre un BLOB. Quindi, queste sessioni si adattano molto bene a una cache distribuita.
- ASP.NET View State Caching
Il secondo tipo di dati ASP.NET è che, se non stai utilizzando il framework MVC che molte delle applicazioni ASP.NET esistenti non lo sono ancora, allora hai questa cosa chiamata a Visualizza stato e uno stato di visualizzazione non è altro che una stringa crittografata che viene conservata e inviata dal server Web al browser, solo per tornare al server Web e può diventare piuttosto grande. Può essere di 100 kilobyte facilmente e quindi consuma molta larghezza di banda extra. Ci vuole più tempo per viaggiare. Quando lo moltiplichi per milioni di richieste che stai elaborando, anche il costo del consumo di larghezza di banda aumenta leggermente. Quindi, è un caso ideale per la memorizzazione nella cache sul lato server e inviare solo una piccola chiave. Quindi, la prossima volta che si suppone che lo stato di visualizzazione venga utilizzato, la chiave viene restituita e lo stato di visualizzazione viene recuperato dalla cache.
- Cache di output ASP.NET
Il terzo esempio di memorizzazione nella cache specifica di ASP.NET è l'output della pagina. Fa parte dell'ASP.NET framework è chiamata cache di output che ti consente di memorizzare nella cache l'output di una pagina se non cambierà e puoi utilizzare una cache distribuita per memorizzarla nella cache invece di tenerla in ogni server web separatamente che quindi diventa più copie che devono essere sincronizzate. Quindi, questi tre casi d'uso o tre esempi sono per il caso d'uso di memorizzazione nella cache specifico di ASP.NET.
Ora, a differenza della memorizzazione nella cache dei dati dell'applicazione, qui la natura del problema è molto diversa. Qui i dati esistono solo nella cache. Voglio dire, tutti questi dati non vengono più archiviati da nessun'altra parte. Quindi, non viene archiviato nel database. Quindi, non hai più quel problema di sincronizzazione tra il database e la cache. Ma ora hai un altro problema. Se hai una cache in memoria, questo è l'unico archivio dei tuoi dati. Qual è la preoccupazione più grande? Cosa potrebbe andare storto in questo? Scompare. Sì, può andare via. Se un server si interrompe e i server si interrompono, Windows incluso. Quindi, quando un server si interrompe perdi dati e soprattutto alcuni dei, intendo per View State e Session State, intendo la cache di output sicura anche se la perdi, riesegui semplicemente la pagina ma questi due. Ad esempio, Session State, hai appena avuto questo cliente di una compagnia aerea che ha eseguito tutti i tipi di ricerche di voli e sta per effettuare l'ordine e il server si arresta in modo anomalo e la sua sessione è persa, deve effettuare il login reale. Sai, potresti perdere quel cliente. Quindi, non vuoi assolutamente perdere. Quindi, non vuoi che questi dati scompaiano. Quindi, in questo, la sincronizzazione era il grosso problema qui è l'affidabilità.
Quindi, l'affidabilità viene gestita attraverso la replica. Qualsiasi cache che non esegue la replica non può archiviare sessioni al suo interno. La cosa bella della memorizzazione nella cache specifica di ASP.NET è che non è necessaria alcuna programmazione. Si inserisce completamente all'interno dell'ASP.NET framework. Sfortunatamente devi fare la programmazione per la memorizzazione nella cache dei dati dell'applicazione. Sul lato Java non è necessario o in realtà stanno emergendo più standard. C'è uno standard chiamato JCache che se lo programmi, una qualsiasi delle cache di terze parti si collega semplicemente ad essa e quindi non devi attenerti a nessuna cache. Ancora di più, se usi un motore di mappatura OR come Hibernate o in caso di .NET NHibernate, puoi collegare una cache. Entity Framework fino a quando il core EF o fino a prima del core EF non consentiva il collegamento automatico di una cache di terze parti. Sebbene avessimo implementato un provider ADO .NET per EF6. Si trattava più della memorizzazione nella cache a livello di ADO.NET, quindi stavi memorizzando nella cache le query che è meglio che non memorizzare nella cache ma non è potente come la memorizzazione nella cache a livello di entità in cui puoi anche tenere traccia degli aggiornamenti.
Entity Framework o EFCore Caching
Il nuovo EF7 o EF Core ha un'architettura molto più flessibile. Ti consente di collegare una cache di terze parti. Quindi, quando passi a EF Core sarai in grado di collegare una cache distribuita come NCache senza alcuna programmazione. Quindi, stavi solo facendo la tua programmazione standard e i plug-in della cache. Ma a parte questo devi. Ma anche in quel plugin non puoi usare tutte le funzionalità di cui parlerò. In ASP.NET specifico almeno questa è la vittoria più semplice. Quando si inserisce una cache, poiché non è necessaria alcuna programmazione, è sufficiente eseguire alcuni test di integrità di base e l'applicazione vede improvvisamente un notevole aumento delle prestazioni e della scalabilità.
Qualche domanda, prima di andare avanti? In termini di applicazione o in termini di cache? In termini di cache. Una cache è proprio come un database. Proprio come fai le chiamate al database e poi hai la gestione delle eccezioni. Se qualcosa va storto nella cache, la cache genererà un'eccezione, la catturerai e quindi dovrai intraprendere le azioni appropriate. Tuttavia, a differenza di un database in cui un aggiornamento può non riuscire sull'integrità dei dati perché potresti avere vincoli di controllo o altri vincoli di integrità referenziale, nessuno di questi vincoli esiste nella cache. Una cache accetterà tutti i dati che gli fornisci. L'unica volta in cui un aggiornamento della cache o un'operazione non riesce è quando qualcosa va storto con il sistema. Sì, qualcosa di catastrofico. Quindi, non devi preoccuparti che la cache non aggiorni le tue cose durante un'operazione normale.
Sicurezza
Quindi, questo dipende dal prodotto cache che usi. NCache ha tutte queste funzionalità integrate. Puoi attivare problemi di, quindi, ogni utente che utilizza la cache deve essere autenticato/autorizzato. Ha anche molte altre misure di sicurezza come la crittografia integrata. Quindi, se l'applicazione che hai è molto sensibile, puoi crittografare i dati prima che vengano memorizzati nella cache e tutto ciò viene fatto automaticamente dalla cache senza che tu faccia alcuno sforzo aggiuntivo. Perché, come dicevo, uno dei maggiori utilizzatori di NCache è il settore dei servizi finanziari. Perché hanno un sacco di servizi bancari online. Lì si verificano molti e-business e i loro dati sono molto sensibili. Quindi, dipende dal prodotto che scegli.
Condivisione dei dati di runtime tramite eventi
Il terzo caso d'uso è condivisione dei dati di runtime tramite eventi. Proprio come usi le code di messaggi, MSMQ è uno, RabbitMQ è un altro. Hanno molte più funzionalità in termini di messaggistica per un ambiente distribuito in più di una posizione. Se la tua applicazione è tutta in un datacenter e devi farlo Pub / Sub tipo di condivisione dei dati, una cache distribuita è molto più scalabile di qualsiasi altra coda di messaggi. Potrebbe non avere tutte le funzionalità che hanno, ma potresti non aver bisogno di tutte quelle funzionalità. Ma è molto più veloce e molto più scalabile e questo è vero per NCache questo vale anche per altre cache distribuite che forniscono questa funzionalità. Perché, ancora una volta, l'intero cluster diventa un bus di messaggi. Quindi, sai, se stai facendo molte attività, gli eventi si propagano molto rapidamente perché sono più di un server per gestire quegli eventi e puoi aggiungere più server man mano che il carico aumenta.
Quindi, molte di queste applicazioni server in questi giorni hanno flussi di lavoro integrati, sai. Dove un'applicazione fa qualcosa e una volta fatto, altre applicazioni fanno qualcos'altro. Ecco da dove arriva il concetto Pub/Sub o produttore/consumatore. C'è una funzionalità di notifica degli eventi. NCache ha questa funzione chiamata interrogazione continua che è una funzionalità molto potente, che esiste anche sul lato Java ma nessuna delle altre cache .NET ce l'ha.
Quindi, anche la condivisione dei dati di runtime è qualcosa che dovresti considerare fortemente di fare attraverso una cache distribuita, rende la tua vita molto più semplice invece di incorporare più altri prodotti. Anche qui, la natura del problema è solitamente la stessa di questo, ovvero che i dati che stai cercando di condividere esistono solo nella cache. Potrebbe esistere nel database ma in una forma diversa, perché l'hai costruito, l'hai prodotto, sai, hai riunito molti dati e in questa forma finale o intermedia stai condividendo con qualcuno altro. Quindi, se perdi quei dati devi rifare tutto. Quindi, anche se non è male come le sessioni, ha comunque molte implicazioni sulle prestazioni. Quindi, non vuoi perdere quei dati. Quindi, anche qui la preoccupazione è assicurarsi che la cache sia affidabile.
Quindi, questi sono i tre casi d'uso di alto livello forniti da una cache distribuita. Come ho detto, una cache distribuita è essenzialmente un database in memoria distribuito, un archivio di valori chiave.
Demo pratica
Prima di passare a dettagli più specifici su come eseguire queste operazioni, ti mostrerò rapidamente che aspetto ha una cache distribuita? Quindi, puoi vedere come sarà se dovessi usarlo nella tua applicazione. Ovviamente lo userò NCache come l'esempio. NCache è una cache open source. Quindi, puoi usarlo senza acquistarlo se non hai i soldi o non hai il budget. Se il tuo progetto è più sensibile al business, ovviamente acquista l'Enterprise Edition. Quindi, ho configurato alcune macchine virtuali in Azure che userò. Utilizzerò un cluster di cache a 2 nodi, quindi ho "demo1" e "demo2" come server di cache e "demo-client" è la mia casella del server delle applicazioni. Quindi, questa è la tua casella del server ASP.NET. Quindi, un NCache client è davvero il tuo server delle applicazioni.
Ho effettuato l'accesso, diciamo, al client demo. Quindi, la prima cosa che farò è creare una nuova cache. Quindi, userò questo strumento chiamato NCache direttore. Quindi, è uno strumento in stile esploratore. Dirò solo di creare una nuova cache in cluster. In NCache tutte le cache sono nominate.
Sceglierò una strategia di archiviazione o di replica.
Vado solo avanti e specificherò il mio primo server cache qui. Specifica il mio secondo.
Continuerò e dirò che ecco quanta memoria dovrebbe consumare il mio server. Nel tuo caso, sarà molto di più. Ho appena specificato un concerto.
Quindi, se quella memoria viene consumata, puoi specificare le politiche di eliminazione. Quindi, diciamo, almeno una politica utilizzata di recente significa sfrattare alcuni degli elementi che sono stati utilizzati meno di recente.
Quindi, l'ho appena ricevuto. Andrò avanti e aggiungerò un nodo client, che è la mia casella e andrò avanti e avvierò la cache.
Allora, su che macchina lo stai configurando? Questo è un azzurro. Quindi, questi due sono i miei demo1 e demo2. Quindi, in realtà ho effettuato l'accesso a questa casella e sto usando NCache manager qui e sto creando un cluster di demo1 e demo2 qui.
Quindi, ora che ho iniziato, posso andare avanti e posso visualizzare le statistiche. Quindi, posso vedere alcune attività di contatore di PerfMon. Posso anche avviare questo strumento di monitoraggio di NCache che mi consente di vedere le cose e quindi eseguirò rapidamente questo strumento chiamato Stress Test Tool. Ti consente di testare rapidamente la cache nel tuo ambiente per vedere come funzionerà.
Quindi, quello strumento è come la tua applicazione. Puoi usarlo per simulare diversi tipi di carico, diversi tipi di operazioni. Ad esempio, sto facendo circa 600 richieste al secondo qui e circa, beh, da 700 a 800 ciascuna.
Fammi eseguire un'altra istanza di Stress Test Tool, proprio qui. Quindi, vedrai che quel carico raddoppierà. Quindi, mentre continuo ad aggiungere sempre più istanze dell'applicazione, il carico sulla cache aumenterà fino a un punto in cui questi due server raggiungeranno il massimo e quindi ne aggiungerai semplicemente un terzo.
E puoi farlo tutto in fase di esecuzione senza interrompere nulla. Quindi, improvvisamente la tua infrastruttura ... Pensa a questo, se il tuo database inizia a soffocare, puoi davvero aggiungere un altro server e uscire da quel problema? Non puoi. Perché, data la natura di ciò e non si tratta di un database specifico, sono tutti database relazionali. Ma, nel caso di una cache, aggiungi un altro server e ora la cache funziona.
Quindi, ecco come appare una cache. È così facile da usare e configurare come puoi vedere. Voglio dire, l'unica cosa che non ho fatto è l'installazione. Che era solo un programma di installazione di Windows che, sai, non richiede molto tempo. Quindi, a parte questo, per capire un cluster a due nodi, mi ci sono voluti circa cinque minuti.
E, ora che ho configurato tutto questo, posso effettivamente specificare questo nome della cache sulle applicazioni in esecuzione su questa casella. Quindi, se avessi più caselle client, continuerei ad aggiungerle qui.
Nel tuo caso per questi due probabilmente ne hai 8 o 10. Quindi, li aggiungeresti tutti e poi una volta che fai questa cache demo, la cache è disponibile lì e poi vai e aggiorni la tua cosa.
Quindi, ora che sappiamo che aspetto ha una cache, lasciami passare rapidamente all'argomento successivo. Quindi, come ho detto, il modo più semplice per utilizzare la cache è utilizzarla per le sessioni. Come lo faccio? Quindi, ho l'applicazione ASP.NET. Vorrei entrare e aprire il web.config e farò due cose. Per prima cosa andrò ad aggiungere l'assieme.
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=1448e8d1123e9096" />
</assemblies>
</compilation>
...In caso di NCache questo è l'assemblea che implementa il Provider dello stato della sessione ASP.NET. Quindi, ecco come NCache si collega all'ASP.NET framework. Qualsiasi cache di terze parti dovrebbe farlo. Quindi, aggiungi semplicemente quella riga negli assembly e in secondo luogo vai semplicemente al tag delle sessioni e specifichi questo specifico per la cache distribuita che scegli.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...In caso di NCache copialo e ci sono un paio di cose di cui devi assicurarti. Per prima cosa devi assicurarti che la modalità sia "personalizzata". Quindi, perché personalizzato significa archiviazione di terze parti. E poi 'timeout' assicurati che sia quello che vuoi che sia e tutto il resto che puoi mantenere come predefinito e basta specificare un nome cache qui, proprio lì. Quindi, dovrebbe essere solo "demoCache". Non appena si apporta questa modifica e si esegue di nuovo l'applicazione o in realtà non appena si salva questa modifica, si sa che il processo di lavoro ASP.NET viene riciclato. Riprenderà NCache configurazione e improvvisamente vedrai che ogni sessione sarà un conteggio. Quindi, tutti quelli, sai, quel conteggio in cui stavamo vedendo NCache in questo PerfMon qui.
Quindi, queste sarebbero 540 sessioni archiviate e ovviamente man mano che aggiungi più sessioni aumenterà il conteggio.
Quindi, con questo piccolo sforzo puoi dare immediatamente una spinta importante alla tua applicazione. La stessa cosa vale con lo stato di visualizzazione. Con la cache di output è necessaria un po' più di configurazione, ma lo stato di visualizzazione e la sessione possono essere eseguiti in pochi minuti, senza alcuno sforzo e improvvisamente le applicazioni utilizzano un enorme boost.
Panoramica della memorizzazione nella cache dei dati dell'applicazione (API)
Quindi ora, passiamo alla memorizzazione nella cache dei dati dell'applicazione, che è ciò di cui tratta la maggior parte di questo discorso. Quindi, se è necessario utilizzare la cache per la memorizzazione nella cache dei dati dell'applicazione, è necessario programmare sulla sua API. Questo perché non esiste ancora un'API standard. Quindi, quello che abbiamo fatto è che abbiamo scelto la nostra API per essere il più vicino all'oggetto cache ASP.NET.
Connessione cacheCache 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");NCache è in circolazione dal 2005, quindi sono quasi 11 anni e mezzo ormai. Ma sembra molto simile all'oggetto cache ASP.NET. Ci sono alcune cose in più, quindi diciamo che ti connetti alla cache con un nome di cache. Ottieni un handle di cache. Quindi quell'handle della cache è ciò che usi per fare cache.Get. Get contiene Aggiungi, Inserisci, Rimuovi e c'è una versione Async di esso, il che significa non attendere l'aggiornamento della cache e, ovviamente, quando chiami Async, puoi specificare un callback. Quindi, la tua richiamata viene chiamata nel caso qualcosa vada storto.
Lascia che ti mostri come appare in una grafica, come in un'applicazione corretta. Quindi, se dovessi avere un... Questa è un'applicazione console standard. Dovresti fare riferimento all'Assemblea della tua cache. In caso di NCache, sono solo questi due assiemi, Alachisoft.NCache.Tempo di esecuzione, Alachisoft.NCache.Ragnatela. Specificare gli stessi spazi dei nomi qui e quindi all'inizio dell'applicazione che nel caso di ASP.NET sarà probabilmente nel globale.asax nel metodo Init o nel metodo di avvio dell'applicazione. Ma, qui diciamo, ti connetti con la cache in base al nome della cache e al nome della cache, come sai, è così, almeno in NCache è così che viene riconosciuta la cache e ottieni un handle di cache. Quindi crei i tuoi oggetti e fai a cache.Aggiungi. Tu specifichi la chiave. Questa non è una buona chiave. dovrebbe avere più unicità in esso. Ma, diciamo, che specifichi la chiave ed ecco il tuo valore l'oggetto reale.
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...Scadenza dei dati
E, in questo caso NCache sta facendo questa cosa chiamata scadenza assoluta. Quindi lasciami, vengo a quello. Quindi, abbiamo parlato della memorizzazione nella cache dei dati dell'applicazione che desidera mantenere la cache fresca. Quindi, se non riesci a mantenere la cache fresca, costringi a usarla per i dati di sola lettura. Quindi, come mantieni la cache fresca? Ci sono più di un modo. Il primo modo in cui è presente praticamente ogni cache è chiamato scadenza assoluta. Qui è dove specifichi per quanto tempo vuoi tenerlo nella cache. Quindi, dici alla cache che mi sento a mio agio solo per un minuto che non penso che questi dati dovrebbero rimanere nella cache per più di un minuto perché, penso che se fossero tenuti nella cache per più di un minuto qualcun altro lo aggiornerà e la cache diventerà obsoleta. Quindi, stai facendo un'ipotesi plausibile su quanto tempo la cache dovrebbe avere i tuoi dati. E, naturalmente, per ogni dato memorizzato nella cache, dovresti avere una sorta di scadenza. Più o meno... Voglio dire, alcuni dati che puoi praticamente presumere che non scadranno mai, quindi puoi dire di non avere scadenza. Tuttavia, il 99% dei dati o qualcosa in più del 90% dei dati deve avere scadenze. Quindi, la scadenza assoluta è ciò che mantiene la cache fresca sulla base di un'ipotesi plausibile.
C'è un'altra scadenza chiamata scadenza scorrevole. Il suo scopo è completamente diverso. Sebbene utilizzi lo stesso nome di scadenza della chiamata. La scadenza scorrevole dice che scade se nessuno tocca questo oggetto per così tanto tempo, diciamo per 10 minuti, per 20 minuti. E questo viene utilizzato per dati più transitori. Quindi, questo viene utilizzato per più dati specifici di ASP.NET, dove in realtà stai solo ripulendo. Stai dicendo, sai, nessun altro ne ha più bisogno. Quindi, se un utente non utilizza più la sessione per 20 minuti, stai dicendo che questo utente si è disconnesso comunque, quindi rimuovi la sessione. Quindi, questa è una scadenza per la pulizia. Quindi scadenza assoluta che è uno scopo di sincronizzazione. Lo scopo della scadenza assoluta è la sincronizzazione. E ancora puoi farlo, puoi far scadere le cose in 10 secondi, 15 secondi, 1 minuto, 5 minuti, 10 minuti. La scadenza più comune sarà probabilmente un minuto o due minuti.
Ma c'è un problema con la scadenza. È che stai facendo un'ipotesi. Stai dicendo che penso che vada bene memorizzarlo nella cache per così tanto tempo. Ma non c'è alcuna garanzia. In alcuni casi può esserci, ma in molti casi non c'è alcuna garanzia. Cosa succede se c'è un'altra applicazione che sta accedendo allo stesso database e aggiornano quei dati. Potrebbero esserci degli script in esecuzione. Quindi, ogni volta che accade qualcosa del genere, le scadenze non sono sufficienti. Ed è qui che hai bisogno della cache per avere questa capacità di monitorare le modifiche nel database.
Se puoi specificare un'associazione tra tutto ciò che è nella cache e qualsiasi dato corrispondente sia nel database e puoi dire alla cache di monitorare questo set di dati. Se questo set di dati cambia, vai avanti e rimuovi quell'elemento dalla cache.
Dipendenza dal database
Lascia che ti mostri come si fa. Quindi, c'è una funzione chiamata Dipendenza SQL in ADO.NET quello NCache usi. Che permette NCache per diventare un cliente del tuo database. E questo potrebbe essere un database SQL, questo potrebbe essere Oracle. Poi NCache dice al database di notificarlo quando quel set di dati cambia e quel set di dati è un'istruzione SQL che hai specificato. La maggior parte delle volte corrisponderà a una o più righe in una tabella che sono state utilizzate per costruire questo oggetto memorizzato nella cache. Quindi, ad esempio, qui, quindi, se dovessi passare alla cosa della dipendenza SQL, di nuovo la stessa cosa. Hai un handle di cache e poi quando aggiungi, questo cache.Aggiungi, ora stai specificando, in caso di NCache questa cosa chiamata elemento cache che è una sorta di struttura che contiene il valore più alcuni altri metadati. Uno dei metadati che contiene è chiamato dipendenza dalla cache SQL, che è un NCache classe che esegue il mapping alla dipendenza della cache SQL di ADO.NET sul lato server. Gli passi una stringa di connessione e le passi un'istruzione SQL.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}Quindi, dici qualcosa come "Seleziona alcune colonne dai prodotti in cui l'ID prodotto è qualunque sia il valore". Quindi, questo è un prodotto su cui stai mappando questo. Quindi, stai dicendo di NCache utilizzare questa istruzione SQL, utilizzare questa stringa di connessione e monitorare quel set di dati o chiedere al server SQL di monitorare quel set di dati. In realtà, questo codice è in esecuzione qui, giusto. Perché, è lì che il NCache è.
Quindi, questo ha quindi parlato con il cluster di cache e il server di cache quindi effettua effettivamente la chiamata ADO.NET e il server di cache ora parla con il database e diventa un client. E il server cache è quello che riceve la notifica. Inoltre, il server cache è quello che rimuove effettivamente quell'elemento dalla cache, se il database gli notifica che questi dati sono cambiati. Quindi, avendo quella funzione integrata, hai improvvisamente la flessibilità di poter mantenere i dati nella cache che non puoi nemmeno prevedere quando potrebbero cambiare, lo sai. Ma sai solo che potrebbe cambiare in modo imprevedibile, quindi puoi usare specificare la dipendenza SQL.
Questa è una caratteristica davvero potente. Questa è la funzione che consente a una cache di memorizzare nella cache i dati transazionali. Anche quando non hai sempre il controllo sugli aggiornamenti e per questo memorizzerai nella cache tutti i tipi di dati perché quella cache diventerà effettivamente utile. E questo può essere fatto in diversi modi se il database sottostante supporta la notifica del database, come nel caso di SQL Server e Oracle, utilizzerà la dipendenza SQL o la funzione di dipendenza Oracle, in caso contrario, il NCache almeno ha un meccanismo di polling integrato in cui può anche consentirti di specificarlo. ... C'è un meccanismo in cui specifichi una tabella speciale NCache lo monitora e tutte le righe che cambiano in esso c'è un elemento della cache corrispondente che quindi rimuove.
E, una terza opzione è che in realtà effettui chiamate cache dall'interno di una procedura CLR. Quindi, ogni volta che un dato cambia, c'è un trigger di database che chiama la procedura, che chiama la cache. E ciò può aggiungere dati, aggiornare dati o rimuovere dati dalla cache. L'unica cosa con la procedura CLR è che non vuoi fare ... Voglio dire, vuoi fare chiamate Async. Perché, qualunque cosa tu abbia chiamato, in realtà è il tuo database che ora è diventato un client della cache come l'indietro, giusto. Quindi, sta cercando di aggiornare qualcosa che andrà qui e quindi potrebbe replicarsi. Quindi, tutto ciò sta accadendo all'interno di una transazione di database e, come sapete, le transazioni di database scadono abbastanza rapidamente. Quindi, effettuando chiamate asincrone è possibile effettuare immediatamente la chiamata cache e quindi restituire il controllo.
Quindi, questi sono i tre modi in cui puoi assicurarti che una cache venga mantenuta sincronizzata con il tuo database relazionale. Naturalmente la stessa logica si applica al non relazionale. E se i tuoi dati fossero in un cloud, da qualche parte? Oppure è nel mainframe. Sai, hai una chiamata al metodo web per andare a recuperarla sempre. Poi, in caso di NCache almeno, puoi avere una funzione di dipendenza personalizzata in cui il tuo codice è registrato nel cluster di cache, NCache lo chiama ogni, diciamo, 15 secondi e dice di andare avanti e controllare l'origine dati e vedere se quei dati sono cambiati. In tal caso, attiva un evento e quindi si attiva la stessa logica.
Quindi, di nuovo mantieni la cache fresca è la cosa più importante in una cache distribuita. Se non riesci a mantenere la cache fresca, il suo utilizzo è molto limitante.
Read-Through e Write-Through
C'è un'altra funzione chiamata Read-Through e Write-Through. Read-Through è una funzionalità che è di nuovo una funzionalità molto utile e molto potente. È essenzialmente di nuovo il tuo codice che viene eseguito sul server cache. Dov'è? Qui. Quindi, diciamo, implementi un'interfaccia di lettura in caso di NCache. Ora read-through/write-through è un concetto implementato da NCache. È anche implementato da molti lettori Java ma sul lato .NET NCache è l'unico che ce l'ha. Quindi, l'interfaccia di lettura è essenzialmente il tuo codice. Ha un metodo Init, un metodo Dispose, quindi Connect and Disconnect e quindi il metodo Load.
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...Ti dà una chiave e in base alla chiave dovresti capire dove andare e ottenere i dati. E non solo restituisci i dati, ma restituisci anche alcuni dei metadati, come le scadenze e altre cose. Qual è il valore della lettura? Quindi, ancora una volta questo codice è qualcosa che implementi e ti registri sul ... Quindi, è questo codice che viene eseguito qui sul server cache. Quindi, abbiamo parlato di una dipendenza personalizzata. Quindi, se si dispone di un'origine dati personalizzata, si tratta di un codice che viene eseguito sul server della cache e anche il read-through è qualcosa che viene eseguito sul server della cache.
A cosa serve la lettura? Perché dovresti usare un read-through? Ci sono due o tre vantaggi. Numero uno, stai consolidando tutto il tuo codice di persistenza in un unico posto. Quindi, se hai più applicazioni che usano la cache, diciamo, hai più applicazioni, sai, non devono implementare quel codice più e più volte. Quindi, viene mantenuto all'interno del server cache stesso. Questo è il primo vantaggio. Il secondo vantaggio è che quando scadi qualcosa, diciamo, scadi qualcosa a causa delle scadenze o della sincronizzazione del database, invece di rimuovere quell'elemento dalla cache perché non ricaricarlo. Perché, se lo rimuovi, la prossima volta che l'applicazione lo desidera, lo ricaricherà comunque. Quindi, puoi avere il read-through mappato con questo e dire dove la cache dice che va bene se questo elemento scade o se arriva ... se è la sincronizzazione automatica e devo rimuoverlo, chiamerò semplicemente il read-through. Allora, perché è bene chiamare il read-through? Voglio dire, qual è il problema? Perché non ricaricarlo semplicemente dall'applicazione? Bene, se hai un'applicazione ad alto traffico, è probabile che molti utenti chiederanno gli stessi dati. Hai centinaia di migliaia di questi articoli e tutti continuano a scadere a proprio piacimento. Quindi, per ogni scadenza di un articolo, avresti centinaia se non migliaia di richieste che colpiscono il database per lo stesso articolo. E tutto andrà ad aggiornare di nuovo la cache. Quindi, molto traffico non necessario va al database. Che, se avessi un read-through, non lascerebbe mai la cache. Rimarrà sempre nella cache e ad un certo punto verrà aggiornato. Pertanto, il traffico verso il database non si verifica mai.
La seconda caratteristica è il write-through che funziona esattamente come il read-through tranne ovviamente per la scrittura. Quindi, lascia che te lo mostri. Ad esempio, di nuovo qui, hai Init, hai Dispose, ma ora hai un Write e ti dà l'oggetto reale e quindi la scrittura potrebbe essere aggiunta, aggiornamento o rimozione, a destra. Quindi, tutti e tre sono chiamati scrivi. Quindi, in base a qualunque sia il tipo di operazione, vai ad aggiornare il tuo database o la tua origine dati.
#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
bool result = false;
OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
Customer value = (Customer)operation.ProviderCacheItem.Value;
if (value.GetType().Equals(typeof(Customer)))
{
result = sqlDatasource.SaveCustomer((Customer)value);
}
if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
return operationResult;
}
public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
throw new Exception("The method or operation is not implemented.");
}Ora, il write-through ha un altro vantaggio. Ha lo stesso vantaggio del read-through in termini di comunanza di codice. Il secondo vantaggio del write-through è chiamato write-behind. Che è quello, puoi aggiornare. Quindi, esiste una funzionalità chiamata write-behind in cui è possibile aggiornare la cache immediatamente in modo sincrono ma gli aggiornamenti del database avvengono in modo asincrono. Perché è una buona cosa? Bene, perché quel database è lento. Quindi, se sai, se sei sicuro che l'aggiornamento del database verrà eseguito in tempo utile... è prevedibile perché non metterlo in coda. Viene messo in coda e la cache esegue effettivamente questa operazione in background. Quella coda viene anche replicata su più di un server. Quindi, se un server va inattivo, la coda non viene persa.
Penso che tutto ciò che devi vedere nel contesto della scalabilità. Qualunque cosa sia veloce, anche se si tratta di un database in memoria, è tutto su un server. Quindi, più aggiornamenti vengono inviati, più letture vengono inviate, più carico viene inserito nel database, più lento diventa. Proprio come un singolo punto di errore. Questo è tutto. Questa è la vera ragione, perché tutto questo esiste e quindi nel contesto di tutto questo esistente ottieni tutti i vantaggi aggiuntivi. Se avevi una funzione di write-behind, improvvisamente la tua applicazione deve solo aggiornare la cache in modo sincrono. Perché, una volta aggiornata la cache, la cache si occuperà dell'aggiornamento del database in modo asincrono. E quella coda ha la sua ottimizzazione. Può eseguire aggiornamenti in blocco, può replicare. Quindi, il write-behind ha le prestazioni, la parte relativa alla velocità di cui hai parlato è più rilevante per il write-through e il write-behind che per il read-through.
Il read-through è anche qualcosa che, sai, in alcuni casi potrebbe essere più veloce dell'accesso dell'applicazione, ma in write-behind è sicuramente sempre più veloce.
Qualsiasi domanda? Ho solo pochi minuti a disposizione. Parlerò di un'altra caratteristica e poi andrò fino alla fine. Quindi, le persone che sono abituate a eseguire la memorizzazione nella cache in memoria In-Proc standalone, come l'oggetto cache ASP.NET, quando si spostano su una cache distribuita, molti dei nostri clienti ci chiamano e dicono, sai, stavi promettendo che la cache lo farà effettivamente migliorare le mie prestazioni. La mia performance è effettivamente diminuita. Perché? Qualcuno può indovinare? Perché in realtà rallenta, non appena si passa a una cache distribuita rispetto a una cache In-Proc. Latenza di rete. La latenza di rete è una. Un problema più grande è la serializzazione e la deserializzazione che è un costo enorme.
Client Cache o Near Cache
Quindi, cosa sta facendo parte della cache distribuita incluso NCache, implementano questa cosa chiamata a cache del cliente, alcuni lo chiamano vicino alla cache. È un sottoinsieme di questa cache, che viene conservata all'interno del server delle applicazioni. Potrebbe anche essere In-Proc o può essere OutProc. Ma molte volte è In-Proc. Quindi, ti offre lo stesso vantaggio di una cache In-Proc standalone, tranne per il fatto che è sincronizzata con questa.
E questo è un sottoinsieme più piccolo, quindi diciamo che potrebbero essere 16 giga per server, questo potrebbe essere solo un giga. Ed è una finestra mobile, giusto? Quindi, tutto ciò che stai memorizzando nella cache viene conservato e poi, mentre vai avanti, gli elementi più vecchi scadono o vengono eliminati e quindi i nuovi dati vengono memorizzati nella cache.
Quindi, una cache client ti offre le prestazioni reali. Mantiene i dati in un modulo oggetto all'interno del processo di candidatura. Quindi, se lo stai recuperando centinaia di volte o decine di volte, la prima volta ovviamente devi recuperarlo dalla cache distribuita. Forse, la prima volta che lo recupererai dal database. Va alla cache distribuita, quindi va alla cache del client, ma una volta eseguita questa operazione, tutte le ulteriori letture vengono eseguite all'interno del proprio heap, il che è super veloce. Quindi, questa è una funzionalità davvero potente. Sicuramente vuoi approfittarne.
Quindi, ci sono alcune cose che devi assicurarti. Una cache distribuita, proprio come un database, viene eseguita nel tuo datacenter nel tuo ambiente di produzione. Quindi, deve soddisfare alcuni dei requisiti architettonici. Deve avere un'elevata disponibilità. Deve fornire affidabilità e scalabilità dei dati. Quindi, deve eseguire una replica intelligente.
Non entrerò nei dettagli di questo. Puoi guardarlo. Puoi fare la ricerca online. Ad esempio, se disponi di più data center, ti aspetti che il tuo database venga replicato, perché non la cache? Sai. Perché anche la cache non dovrebbe essere disponibile in modo sincronizzato su più... Quindi, sì, dovrebbe esserlo una buona cache.
Opzioni di memorizzazione nella cache distribuita .NET
Se stai facendo applicazioni .NET, in questo momento, sai, ci sono praticamente due opzioni che hai per la memorizzazione nella cache. Uno è Redis che Microsoft ha messo su Azure. L'altro è NCache. Dal lato Java, come ho detto, ci sono un certo numero di giocatori che sono abbastanza bravi.
Quindi, voglio solo fare un confronto davvero di alto livello.
NCache è la cache .NET più vecchia. È sul mercato dal 2005. È .NET nativo. È anche open source, proprio come Redis. È disponibile anche su Azure o su Amazon entrambi. Redis … Quindi, ci sono due versioni di Redis, uno sviluppato da Redis Labs, che funziona solo su Linux. Infatti Microsoft usa quella versione in Azure. E, la versione che Microsoft ha portato su Windows, non la usano nemmeno da soli. In realtà, abbiamo sentito molte lamentele da parte dei clienti. Non è molto stabile. Ma, al di fuori di Azure, l'unica versione che hai per Windows è quella che ha portato Microsoft, MS Open Tech. Ma, a parte questo, se ci vai Redis ti daranno solo la versione Linux. Su Azure stesso ci sono due differenze tra NCache e Azzurro che è quello NCache in realtà ti dà un server cache come VM. Quindi, puoi eseguire tu stesso tutto quel codice lato server, monitorare le cose. Redis ti dà la cache come servizio. Quindi, la cache è una scatola nera. Hai solo un'API molto semplice che chiami. E il limite è che non ottieni tutte le funzionalità di cui abbiamo appena parlato. Come si esegue la sincronizzazione del database? Read-through write-through. In realtà, non sono nemmeno entrato nella ricerca SQL, perché non avevamo tempo. Quindi, questi sono i due modi in cui puoi farlo. Se vuoi saperne di più su questo, puoi venire sul nostro sito Web e abbiamo un completo documento di confronto dettagliato. Quindi, se dovessi entrare Redis vs NCache qui puoi vedere un documento in piena regola. Puoi anche scaricarlo. È una funzionalità per confronto delle funzionalità basata sulla loro documentazione e la nostra e quindi puoi vedere quale soddisfa le tue esigenze. Qualsiasi domanda? Questa è la fine del mio discorso. Grazie.
C'è qualche dipendenza da? .NET Core Framework o puoi usarlo con .NET 4.0? Buona domanda. Così, NCache server supporta .NET frameworkS. È 4.0 o successivo. Il NCache Il cliente per impostazione predefinita è .NET framework Certo. Stiamo per rilasciare il .NET …. Quindi, supportiamo ASP.NET Core. Così il .NET Core che può essere eseguito su Linux, non lo supportiamo ancora perché ha dei limiti. Ma il .NET Core che gira su ASP.NET framework, sotto solo su Windows, in particolare ASP.NET Core NCache lo sosterrà. Grazie mille ragazzi.