DEVintersezione 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

Panoramica

Ciao a tutti. Mi chiamo Iqbal Khan. Sono un evangelista della tecnologia presso Alachisoft. Siamo una società di software con sede nella Baia di San Francisco. NCache è il nostro prodotto di punta che è una cache distribuita e questo è il mio argomento oggi. Il mio argomento non riguarda NCache oggi, la sua memorizzazione nella cache in generale. NosDB è un altro prodotto che abbiamo, è un open source NoSQL database per .NET. Userò Azure per dimostrare la cache distribuita in modo che voi ragazzi possiate vedere come viene effettivamente utilizzata.

Quindi, l'argomento di oggi è il ridimensionamento delle applicazioni .NET per la memorizzazione nella cache distribuita. Preferisco avere una discussione più interattiva. Quindi, mentre sto parlando, se avete una domanda per favore alzate la mano. Quindi, possiamo parlarne proprio a quel punto invece di aspettare fino alla fine. Trovo che questo renda la conversazione molto più significativa.

Allora, fammi iniziare. Bene! Quindi, esamineremo alcune definizioni. Sono sicuro che molti di voi lo sanno già, ma questo è a scopo di completamento.

Scalabilità

La prima definizione è la scalabilità. La scalabilità è un'elevata prestazione dell'applicazione con carichi di picco. Quindi, se hai, diciamo un'applicazione ASP.NET o qualsiasi applicazione .NET che funziona in modo super veloce, con, diciamo, cinque utenti, non è necessariamente scalabile. Ovviamente, se non funziona velocemente con cinque utenti, hai altri problemi oltre a questo. Ma la maggior parte delle applicazioni funziona in modo super veloce con cinque utenti, ma è quando si passa a 5,000 o 50,000 o 500,000 utenti che è quando le cose iniziano davvero a peggiorare. Quindi, se vuoi che la tua applicazione sia scalabile, deve funzionare con carichi di picco.

Scalabilità lineare

Scalabilità lineare significa che l'architettura dell'applicazione, la strategia di distribuzione, se è eseguita in modo tale che l'aggiunta di più server ti dia una capacità incrementale di gestire più transazioni di quanto tu sia linearmente scalabile.

Ciò significa che se avessi due server e se aggiungi, diciamo mille utenti con tre server, dovresti avere 1500 utenti o qualcosa del genere.

Scalabilità non lineare

Ma se la tua app, se la tua architettura o distribuzione non è linearmente scalabile, assomiglierà più a una curva logaritmica che va su e giù, il che significa che dopo un certo punto non importa se aggiungi più server.

Rallenta le cose. Se hai più transazioni non puoi uscire. Non puoi riscattarti da quel problema. Quindi, non vuoi solo scalabilità ma scalabilità lineare.

Quali applicazioni necessitano di scalabilità?

Le seguenti applicazioni sono quelle che di solito presentano questi tipi di problemi. Queste sono applicazioni Web ASP.NET, questi sono servizi Web, questi sono back-end IOT Internet che di solito sono anche servizi Web, potresti avere un'elaborazione di big data che di solito non è così comune in .NET ma anche l'elaborazione di big data è qualcosa che deve essere ridimensionato o qualsiasi altra applicazione server. Potresti essere un istituto finanziario che ha un requisito di conformità per elaborare un determinato numero di transazioni.

Quindi, potresti avere un'applicazione server che ha un requisito di conformità, diciamo, se sei un'applicazione di bonifico bancario, devi trasferire i fondi per il giorno lavorativo successivo o entro una certa ora. Quindi, devi essere in grado di elaborare sempre più transazioni. Quindi, se hai una di queste applicazioni, sei arrivato al discorso giusto.

Il problema della scalabilità

Quindi, definiamo il problema della scalabilità. La maggior parte di voi sa che le architetture delle applicazioni oggi, se si dispone di un'applicazione ASP.NET o di servizi Web, l'architettura delle scale del livello dell'applicazione varia in modo lineare. Quindi, puoi aggiungere più server, di solito non ci sono problemi. Il problema è davvero con l'archiviazione dei dati e, quando uso la parola archiviazione dei dati, intendo database relazionali e mainframe. Ci sono dati legacy. Qualsiasi archivio dati che hai utilizzato tradizionalmente e che diventa un collo di bottiglia e quando diventa un collo di bottiglia, hai questo problema. Il NoSQL databases, avrei dovuto dire che non sono sempre la risposta. Ma NoSQL movimento è iniziato in parte a causa di questo. Poiché i database relazionali non erano scalabili, così NoSQL databases sono scalabili ma non vanno bene in tutte le situazioni perché, sai, richiedono che tu sposti tutti i tuoi dati dal tuo database esistente in un NoSQL database cosa che puoi fare per molti nuovi dati, ma i dati aziendali tradizionali, i tuoi clienti, i loro account, tutti quei dati devono rimanere in relazione sia per motivi commerciali che per motivi tecnici. Le ragioni tecniche ovviamente sono che un database relazionale ha un ecosistema che non è eguagliato da nessuno NoSQL database e le ragioni d'affari sono ovviamente della stessa natura.

Così, la NoSQL database non è sempre la risposta e anche se abbiamo NoSQL database si chiama prodotto che vendiamo NosDB, che viene utilizzato solo come ampliamento dei database relazionali. Quindi, non puoi uscire dai database relazionali. I database relazionali sono qui per restare. Quindi, devi convivere con quella realtà. Quindi, è necessario risolvere la scalabilità con i database relazionali ancora presenti.

La soluzione di scalabilità

La soluzione ovviamente è che dovresti usare una cache distribuita in memoria. NCache è una di queste soluzioni. È una cache distribuita open source. Siamo la più antica cache distribuita .NET sul mercato. Siamo stati in giro per gli ultimi 10 anni, in realtà 11 ora. E siamo l'unica cache .NET veramente nativa.

La maggior parte di voi ne ha sentito parlare Redis, Giusto? Quindi, più di 2 anni fa, non ne abbiamo mai sentito parlare Redis perché non erano davvero concentrati su quello. Non è stato fino a quando Microsoft ha stretto una partnership con loro per Azure.

Distribuzione cache distribuita

Il vantaggio di una cache distribuita in memoria è che puoi usarla con i tuoi database esistenti. Quindi, puoi risolvere quel problema che i tuoi database relazionali ti stanno fornendo attraverso una cache distribuita in memoria. Allora, come risolvi quel problema? Risolvi quel problema, vediamo questa immagine qui.

Quindi, hai un livello dell'applicazione che è le tue applicazioni Web, il tuo servizio Web, qualsiasi altra applicazione server e puoi aggiungere più server qui. Per l'applicazione web e i servizi web di solito c'è un sistema di bilanciamento del carico lassù che non ho disegnato in questo. Quindi, puoi aggiungere più server a questo livello. Non è possibile aggiungere più server a livello di database. Sì! Puoi aggiungere più server in NoSQL livello, ma, come ho detto, non è sempre la risposta. Quindi, devi risolvere queste due scatole. Quindi, inserisci una cache distribuita in memoria tra il livello dell'applicazione e il database.

La cache distribuita di solito forma un cluster. Quindi, non tutte le cache distribuite formano un cluster. Memcached non ha mai formato un clustering anche se era una cache distribuita. Redis forma un grappolo, NCache sicuramente forma un cluster. Una cache distribuita forma qui un cluster di due o più server. Il motivo per cui ne dico due è per scopi di ridondanza e per la replica e per molti altri e anche per motivi di scalabilità. Se hai bisogno di un solo server cache, probabilmente non hai bisogno di una cache distribuita. Quindi, dovresti avere un minimo di due server cache qui e questo cluster di cache effettivamente raggruppa la memoria e le risorse della CPU da tutti i server cache in un'unica capacità logica. Ciò significa che aggiungendo più server si ottiene più memoria, più elaborazione della CPU e più capacità della scheda di rete. Questi sono i tre colli di bottiglia alla scalabilità; memoria, CPU e scheda di rete. Le schede di rete in questi giorni sono... un gigabit o dieci gigabit sono praticamente standard. È piuttosto difficile per un massimo di una scheda gigabit o dieci gigabit a meno che le dimensioni dell'oggetto non siano grandi. Ma se le dimensioni dei tuoi oggetti sono grandi, grandi significa centinaia di kilobyte per oggetto, allora è abbastanza facile massimizzare una scheda di rete se hai molto traffico. Ma se hai più server e ovviamente ci sono più schede di rete e la memoria è allo stesso modo.

Il motivo per cui è una cache distribuita in memoria è perché la memoria è molto più veloce del disco e questo è ciò che aggiunge davvero il valore. È più veloce, è più scalabile. Quindi, l'obiettivo qui è quello di acquisire circa l'80% dell'accesso all'applicazione che va alla cache distribuita. Quindi, solo il 20% sarà lasciato per andare al database.

Molte persone inizialmente vedevano la memorizzazione nella cache come un aumento delle prestazioni. Sì! È un aumento delle prestazioni perché la memoria in-memory è più veloce di così. Ma soprattutto è un'esigenza di scalabilità perché non puoi scalare senza qualcosa di simile nella tua infrastruttura. In effetti, sempre più aziende stanno quasi rendendolo uno standard che, proprio come avranno un database nel loro ambiente applicativo, avranno anche una cache distribuita. Alcune persone lo chiamano griglia di dati in memoria che si trova sul lato Java, questo è un termine. Alcune persone lo chiamano un po' di data fabric, ma la cache distribuita è il nome più comune per l'ecosistema .NET. Quindi, questa è un'infrastruttura. Una volta installato, puoi usarlo come uno strumento davvero potente. Il rapporto tra i server delle applicazioni e il livello di memorizzazione nella cache è in genere di circa 4:1, 5:1, supponendo che si tratti di server piuttosto caricati in termini di transazioni. Puoi andare più di 5:1 anche a seconda della natura di questi. Inoltre, un tipico server cache ha una memoria compresa tra 16 giga e 32 giga e un tipo di configurazione quad core con doppia CPU. Quindi, non una scatola di fascia alta. In effetti, non vuoi una scatola di fascia alta in questo livello. Vuoi più scatole di poche scatole di fascia alta. Se aggiungi più memoria puoi arrivare fino a 128 o 256 giga di memoria, ma più memoria significa che devi avere una CPU più potente. Perché? Perché, se hai più memoria, il tuo heap è più grande, la tua garbage collection sarà un'attività molto più grande e la garbage collection non è la cosa più veloce in .NET e consumerà la tua CPU. Quindi assomigli sempre di più a un database. Quindi, è meglio avere da 16 a 32 giga è un buon punto debole per server cache. Qualche domanda fino ad ora?

NCache Numeri di scalabilità

Ecco i numeri di scalabilità di NCache. Cache diverse avrebbero numeri diversi, ma l'obiettivo è di avere questo come scalabile. Quindi, le letture scalano in questo modo le scritture lo stanno ridimensionando. Le letture sono più lente delle scritture perché la replica avviene con le letture. Parlerò di queste capacità.

Il motivo per cui è necessaria la replica è perché la memoria è volatile. Quindi, se un server si interrompe, perderai quei dati. Quindi, non vuoi perdere quei dati in molti casi.

Usi comuni della cache distribuita

L'obiettivo del discorso fino ad ora era quello di mostrarti perché hai bisogno della memorizzazione nella cache distribuita. E, ora che abbiamo stabilito il caso, parliamo di cosa utilizzerai una cache distribuita.

Memorizzazione nella cache dei dati dell'app

Il caso d'uso più comune è quello di cui stavo parlando, ovvero la memorizzazione nella cache dei dati dell'applicazione. Metti nella cache i dati che esistono nel tuo database, proprio qui. Quindi, memorizzi nella cache il più possibile e quindi migliori le prestazioni e la scalabilità.

La cosa principale da notare nel caso d'uso della memorizzazione nella cache dei dati dell'applicazione è che i dati esistono in due posizioni. Uno nel database, uno nella cache. Ogni volta che ciò accade, qual è la prima preoccupazione che ti viene in mente che cosa potrebbe andare storto se esistesse in due posti? Sì, coerenza!

Quindi, è davvero importante che una buona cache distribuita lo gestisca. Perché, se una cache non è in grado di gestire il fatto che i dati devono essere coerenti in entrambi i punti, sei costretto a memorizzare nella cache più dati di sola lettura. I dati di sola lettura sono circa dal 10% al 15% o il 20% dei dati. La maggior parte dei dati è ciò che io chiamo dati transazionali. Questi sono i tuoi clienti i tuoi account. Sono dati che stanno cambiando. Potrebbe cambiare ogni pochi secondi, anche se la maggior parte delle volte potrebbe cambiare ogni due minuti. Quindi, anche se potessi memorizzarlo nella cache per un minuto o 30 secondi, avresti comunque il vantaggio di leggerlo più volte e se lo moltiplichi per il numero totale di transazioni che si verificano in un determinato giorno, hai milioni di transazioni che non vanno più al database. Quindi, è davvero importante che per la memorizzazione nella cache dei dati dell'applicazione, una buona cache distribuita debba gestire questa coerenza e esaminerò quelle funzionalità che sono davvero importanti per avere quella coerenza. Quindi, la memorizzazione nella cache dei dati dell'applicazione memorizza nella cache i dati permanenti. Dati permanenti significa che esiste nel tuo database in modo permanente.

Memorizzazione nella cache specifica di ASP.NET

Il secondo caso d'uso è, se si dispone di un'applicazione ASP.NET, questo ovviamente si applica anche ad altre applicazioni Web, ma mi sto concentrando su .NET. Puoi memorizzare nella cache lo stato della sessione, lo stato di visualizzazione, se non stai utilizzando il framework MVC e puoi memorizzare nella cache il tuo output, l'output della pagina. Tutti questi dati sono di natura temporanea. Non è permanente. Tutti i dati che non sono permanenti non dovrebbero esistere realmente nel database. È un dato transitorio.

Quando i dati sono transitori, quando sono temporanei e non sono presenti nel database, esistono solo nella cache, qual è la preoccupazione più grande che viene in mente che cosa potrebbe andare storto? Persistenza... o mancanza di esso. Quindi, se non persisti, perdi dati. Che cosa succede se questo server cache si interrompe e tu hai questo carrello della spesa o qualsiasi altra cosa e diciamo che sei una compagnia aerea e questo tuo cliente ha appena fatto questa ricerca di volo e comprerà 10 biglietti o quattro biglietti del valore di almeno $ 5,000 e l'ultima pagina che dicono invia o qualunque sia l'ultima pagina e all'improvviso la sessione è sparita perché il server della cache è andato in crash e devono ricominciare tutto da capo. L'intera attività è persa. Potresti perdere quel cliente. Non è un'esperienza molto positiva.

Quindi, tutto ciò che viene memorizzato nella cache che è transitorio, la cache deve replicarsi. Qualsiasi cache che non esegue la replica, non è una cache valida. Inoltre, la replica ha un costo, quindi la cache deve eseguire una replica efficace ed efficiente. Lo stato della sessione è un caso d'uso molto comune per una cache distribuita perché le sessioni sono molto comuni in ASP.NET.

Condivisione dei dati di runtime tramite eventi

Il terzo caso d'uso comune o terzo che in realtà non è molto noto è chiamato condivisione dei dati di runtime. Questo è, se hai più applicazioni che devono essere condivise. Un'applicazione produce qualcosa o aggiorna qualcosa che deve essere utilizzata da un'altra applicazione o da un'altra istanza di tale applicazione. Di solito utilizzeresti le code di messaggi per questo tradizionalmente o inserirai semplicemente quei dati nel database e l'altra applicazione eseguirà il pull. Ma una cache distribuita è molto buona per quel caso d'uso. Non è lì per sostituire le code di messaggi. Le code di messaggi hanno un altro uso, ma se l'applicazione è in esecuzione nello stesso data center, tutte le istanze e hanno bisogno di condividere i dati, questa è una piattaforma di condivisione dati o dati molto più scalabile perché tutte le applicazioni sono connesse alla stessa piattaforma e questo la piattaforma può attivare eventi, in un modello Pub/Sub. Pub significa che un'applicazione è l'editore, pubblicano qualcosa e attivano un evento. Tutti gli abbonati di ciò verranno avvisati e consumeranno quei dati.

Ci sono anche altri tipi di notifiche. Quando alcuni articoli vengono modificati, la tua applicazione può mostrare interesse per determinati articoli e se questo articolo cambia avvisami. Oppure c'è un interrogazione continua caratteristica che NCache ha che è come a Dipendenza SQL funzione in SQL Server, dove NCache ti consente di pronunciare un tipo SQL di query che dice SELEZIONA Clienti DOVE Customers.City = "New York". Quindi, se un cliente con questi criteri ha mai aggiunto, aggiornato o rimosso dalla cache, notificato.

Quindi, è un modo molto più intelligente per monitorare le modifiche alla cache. Quindi, tutte queste cose ti consentono di condividere i dati tra le applicazioni in modo molto veloce e scalabile in fase di esecuzione. E anche questi sono dati transitori, sebbene molti di questi dati esistano nel database ma la forma in cui li stai condividendo probabilmente non lo è. Quindi, è transitorio. Quindi, anche questo deve essere replicato. Qualche domanda fino ad ora? O voi ragazzi conoscete già questa roba completamente o io sono super bravo.

Panoramica della memorizzazione nella cache dei dati dell'app

Quindi, esaminiamo e vediamo un po' di codice sorgente in termini di come... quali sono le funzionalità che dovresti usare e come usarle. lo userò NCache come l'esempio, ma come ho detto il mio focus è più sulle caratteristiche reali.

Ecco un modo tipico in cui useresti qualsiasi cache.

Customer Load(string customerId)
{
    // Key format: Customer:PK:1000
    string key = "Customers:CustomerID:" + customerId;
    
    Customer cust = (Customer) _cache[key];
    
    if (cust == null)
    {
        // Item not in cache so load from db
        LoadCustomerFromDb(cust);
        // Add item to cache for future reference
        _cache. Insert(key, cust);
    }
    return cust;
}

Dovresti caricare un cliente da un database. Prima di accedere al database, controllerai la cache e utilizzerai la chiave, una chiave basata su stringhe. Diciamo Clienti: ID cliente e l'ID cliente effettivo potrebbe essere 1000 o qualcosa del genere e tu dici di controllare la cache. Se ce l'hai nella cache non c'è bisogno di andare al database, ce l'hai. Se non lo hai nella cache, vai al database, carichi quel cliente e lo metti nella cache. Quando lo metti nella cache, la prossima volta che verrai, tu o chiunque altro verrai, lo troverai nella cache. Quindi, questo è un paradigma molto semplice. Una volta fatto questo, tutti troveranno cose che valgono più della cache.

Ovviamente ci sono molte altre funzionalità che puoi precompilare nella cache con molti dei dati che ritieni siano comunque necessari. In questo modo salverai in anticipo molti dei risultati del database e continuerai comunque ad aggiungere in modo incrementale dati alla cache che non si trovano nella cache. Ad esempio, ecco un progetto di uno studio visivo. Se dovessi usare NCache collegheresti due di questi assiemi. Uno è NCache.Durata e uno è NCache.Ragnatela. Utilizzerai due degli spazi dei nomi qui in modo simile NCache.Durata ed NCache.Web.Caching. Abbiamo chiamato i nostri spazi dei nomi in modo che fossero abbastanza vicini alla cache ASP.NET. Quindi, sai, quando NCache è uscito ASP.NET cache era l'unica cache disponibile. Quindi, hai questo e all'inizio della tua applicazione, questa è un'applicazione console ovviamente, la tua sarà diversa. Ti connetterai alla cache e otterrai un handle della cache. Ogni cache ha un nome e hai un handle di cache e quindi aggiungi i tuoi oggetti alla cache. Quindi, diciamo, hai appena aggiunto, lo fai cache.Aggiungi qui. Tu specifichi la tua chiave. Anche se questo probabilmente non dovrebbe essere David Jones, dovrebbe essere un ID cliente di qualche tipo e quindi hai l'oggetto reale e quindi hai specificato le scadenze. E specifichi le scadenze assolute di un minuto. Stai dicendo che dopo un minuto scadono questo elemento dalla cache. Tutto il resto l'hai mantenuto come predefinito. E poi puoi farlo cache.Get e ottenere lo stesso cliente da un altro posto. Quindi, solo semplici operazioni di cache.

using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;

namespace BasicOperations
{
    public class BasicOperations
    {
        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");
            ...

Demo pratica

In caso di NCache, tutte le cache sono nominate. Ora ti mostrerò rapidamente che aspetto ha una cache e poi torneremo al codice. Ho configurato un gruppo di macchine virtuali in Azure. Quindi, puoi correre NCache in Azure, in Amazon, un locale. In tutti i casi, i server cache stessi sono solo macchine virtuali. Si tratta solo di VM Windows 2008, 2012. Il client cache in Azure può essere una macchina virtuale, potrebbe essere un ruolo Web, potrebbe essere un ruolo di lavoro, potrebbe essere un sito Web.

Crea una cache raggruppata

Ho effettuato l'accesso al client demo, proprio qui. Ora andrò rapidamente a creare una cache. Quindi, posso mostrare come appare la cache. Usa questo strumento chiamato il NCache direttore, strumento grafico e ti permette... Vengo qui e dico che crea una "Nuova cache raggruppata".

Tutte le cache in NCache sono nominati. Quindi, ho solo intenzione di nominare la mia cache. Prenderò tutto il resto come predefinito in questo momento.

Sceglierò una topologia per la replica partizionata. Ne parlerò rapidamente alla fine di questo discorso. Replica partizionata è la mia topologia.

Userò la replica asincrona.

Sceglierò il mio primo server cache che è demo2. Quindi, quelli sono due miei nodi di cache.

Premerò Avanti. Prenderò tutte le impostazioni predefinite. Specifico quanta memoria voglio allocare a questa cache. Quindi, in questo modo la cache non consumerà più memoria di questa. Ho appena dato un concerto, ma ovviamente il tuo sarà molto più grande. Questa è la dimensione di una partizione.

Quindi, una volta che la cache utilizza quella quantità di memoria, la cache è piena. Quindi, o rifiuterà tutti i nuovi articoli o eliminerà alcuni degli articoli esistenti. Quindi, sto per dire, sfratta il 5% della cache su questo e dirò che l'uso meno recente è l'algoritmo da usare e ho appena creato la cache.

Vado avanti e aggiungo un cliente a questo.

Quindi, ho appena creato una cache e avvieremo la cache.

Simula lo stress e monitora le statistiche della cache

Sceglierò le statistiche, quindi posso usare alcune statistiche PerfMon. Monitorerò anche il cluster. Quindi, ho appena avviato la cache. Questa cache è chiamata cache demo. Lo proverò rapidamente. Quindi, ho appena eseguito uno strumento di stress test in dotazione NCache e ti consente di testare rapidamente la cache nel tuo ambiente.

Quindi, questa cache ora funziona. Quindi, quello che sta succedendo è che, sulla casella del client, e il client significa che nella loro casella del server delle applicazioni ho un file di configurazione, proprio qui. Quindi, ho appena creato la cache e ora sa quali sono i server di cache. Ora, permettetemi di tornare al codice. Quindi, quando in realtà ho scelto questo nome di cache, questo è ciò che è effettivamente successo, la mia applicazione ora si è collegata a tutti i server di cache nel cluster e mi ha fornito un handle di cache, in modo che quando eseguo un cache.Aggiungi, in realtà lo aggiungerà nella posizione appropriata nella cache e eseguirà anche la replica per me, tutto ciò è fatto.

Quindi, l'API nasconde tutti quei dettagli, ma volevo mostrarti come appare quella cache dietro le quinte e quanto è facile usare il NCache in quella situazione. Quindi, torniamo al nostro principale. Ecco come sarebbe l'API.

• Connessione cache

  ICache cache = CacheManager.GetCache(“myDistributedCache”);
  cache.Dispose();

• Recuperando i dati

  Employee employee = cache.Get<Employee>("Employee:1000"); 
  bool isPresent = cache.Contains("Employee:1000");

• Scrittura di dati

  cache.Add("Employee:1000", employee);
  cache.AddAsync("Employee:1000", employee);
  
  cache.Insert("Employee:1000", employee);
  cache.InsertAsync("Employee:1000", employee);
  
  Employee employee = (Employee) cache.Remove("Employee:1000");
  cache.RemoveAsync("Employee:1000");

tu fai un cache.Get, cache.Contains, cache.Add, Inserisci, Rimuovi. Inserisci significa aggiungere se non esiste altrimenti aggiorna.

Funzionalità di memorizzazione nella cache dei dati dell'app

OK, ora che abbiamo un'idea di come appare una cache, cos'è una semplice API. Veniamo alla funzione di cui abbiamo parlato. Che sono importanti per una cache distribuita.

Mantieni la cache fresca

Quindi, la prima cosa che abbiamo detto è che una cache distribuita deve mantenere i dati freschi, la cache fresca. Quindi, ci sono quattro modi in cui può farlo. Il numero uno lo è scadenza, che molte cache hanno quasi tutte le cache ti consentono di far scadere le cose.

Quindi, c'è un Scadenza assoluta e c'è un Scadenza scorrevole. Absolute Expiration è ciò che ti ho appena mostrato, ovvero, dice che la scadenza di questo articolo è tra cinque minuti, indipendentemente da ciò che accade. E il motivo per cui lo dico è perché, come ho detto, questi dati esistono nel database e posso fidarmi solo per cinque minuti che non verranno modificati nel database. Non voglio tenerlo per più di quello nella cache perché potrebbe cambiare nel database. Quindi, stai facendo un'ipotesi sulla natura dei dati. Alcuni dati possono essere memorizzati nella cache per ore e giorni. Sai, questa potrebbe essere la tua tabella di ricerca. Potrebbero essere le tue modifiche ai prezzi una volta al giorno o qualcosa del genere. Quindi, puoi memorizzarlo nella cache per 24 ore.

Altri dati sono i tuoi dati transazionali. Puoi memorizzarlo nella cache solo per forse 30 secondi o un minuto perché è tutto il tempo che ti senti a tuo agio. Quindi, la scadenza assoluta è per i dati permanenti ed è un modo per stimare o indovinare per quanto tempo è sicuro conservare i dati nella cache. È molto importante. Distinzione che voglio fare tra le scadenze assolute e lo scivolamento.

La scadenza scorrevole in pratica dice di rimuovere questo elemento dalla cache quando nessuno lo sta più toccando, per questo intervallo. Toccare significa recuperare o aggiornare. Quindi, ad esempio, uno stato di sessione. Quando ti disconnetti, lo stato di una sessione non viene più toccato da nessuno. Quindi, dopo circa 20 minuti, deve essere rimosso dalla cache.

La scadenza scorrevole viene solitamente utilizzata per i dati transitori. È più un'operazione di pulizia. Non ha nulla a che fare con il mantenimento dei dati aggiornati. Ha a che fare con l'eliminazione di esso perché non ne hai più bisogno. Ma la scadenza assoluta è ciò di cui hai bisogno per mantenere aggiornati i dati. In secondo luogo, sai, le scadenze sono una cosa molto importante. Ogni cache deve averlo e la maggior parte di esse lo fa, infatti penso tutte, almeno a scadenza assoluta.

Sincronizza la cache con il database

La seconda caratteristica è qualcosa che la maggior parte di loro non fa. Ed è qui che vuoi sincronizzare la cache con il database.

Utilizzo delle dipendenze del database

Dici, sai, non posso davvero prevedere con quale frequenza o quando verrà aggiornato nel database. Non so quando i dati verranno aggiornati nel database. Perché ho più applicazioni che lo stanno aggiornando. Potrebbero essere altre persone che toccano direttamente i dati. Quindi, voglio solo che la cache controlli il database. Quindi, e la cache dovrebbe essere a conoscenza di questa modifica nel database. Questa è una caratteristica che NCache ha. Si chiama dipendenza SQL. In realtà, utilizza una funzionalità del server SQL chiamata dipendenza SQL, dove NCache diventa un cliente del database.

Lascia che ti mostri rapidamente che aspetto ha. Quindi, se ho una cache qui. Quindi, ancora una volta, allo stesso modo in cui abbiamo fatto le librerie e poi ti connetti alla cache. Ora, quando aggiungi l'elemento alla cache, proprio qui. Se vengo qui e poi dico 'AggiungiProductToCacheWithDependency', vai alla definizione. Quindi, qui stai dicendo a questa cache, ecco la mia istruzione SQL.

private static void AddProductToCacheWithDependency (Product product)
{
// Any change to the resulset 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.ProductID);

//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);
}

private static string GenerateCacheKey (Product product)
{
string cacheKey = "Product#" + product.productID;
return cachekey;
}

Quindi, la tua istruzione SQL di solito riflette quella riga nella tabella. Quindi, se aggiungi un prodotto, dovrebbe essere che l'istruzione SQL con l'ID prodotto sia uguale a questo. Quindi, stai creando questa istruzione SQL per SQL Server. Perché questo è ciò che passi come parte della dipendenza SQL a SQL Server. Lo passerai a NCache. Quindi, tu sulla casella del cliente lo stai passando NCache. Quindi, lo stai specificando come istruzione SQL. Stai creando un oggetto "elemento della cache" e all'interno dell'elemento della cache viene specificata la "dipendenza SQLServer". Così, SQLCacheDependency è una classe di NCache, in realtà. Questo non è lo stesso della dipendenza del server SQL. Questo ha lo stesso nome tranne la dipendenza dalla cache SQL. Ciò mantiene quell'istruzione SQL, la specifichi e aggiungi l'elemento alla cache. Quindi, l'hai fatto e in questo momento sei seduto su questa scatola, proprio qui.

Quindi, passa questo a NCache. Va a uno dei server cache. Questo server cache diventa ora un client del database. Perché hai specificato anche le informazioni sulla stringa di connessione. Da qualche parte qui, specifichi la stringa di connessione. Così, NCache il server diventa un client del tuo database. Ora quel database potrebbe essere un server SQL, potrebbe essere Oracle e NCache stabilirà una connessione di dipendenza SQL. Il server SQL creerà una struttura dati all'interno del server SQL che monitorerà il set di dati.

Quindi, proprio come NCache aveva quella funzione di query continua di cui ho parlato per la condivisione dei dati in fase di esecuzione, dove NCache stava monitorando tutti i clienti, dove Cliente. Città = “New York”. Ora il server SQL sta monitorando questo set di dati all'interno del server SQL e se una riga che corrisponde a tali criteri viene aggiunta, aggiornata o rimossa dal database SQL, il server SQL invia una notifica al server della cache. Il server cache ora sa che questi dati sono cambiati nel database. Quindi, ha due opzioni. Può rimuoverlo dalla cache, che è il comportamento predefinito, oppure ricaricare una nuova copia.

Utilizzo di Read-Through/Write-Through

Il modo in cui ricaricherà una nuova copia è, se usi un altro futuro di NCache detto lettura. Salterò questo e dovrò tornare su questo. Quindi, c'è una funzione chiamata read-through che è il tuo codice. Implementi un gestore di read-through e ti mostrerò il gestore di read-through. Quindi, ecco un IReadThrough fornito.

{
    // <summary>
    // Contains methods used to read an object by its key from the master data source.
    // </summary>

    public class SqlReadThruProvider : Alachisoft.Ncache.Runtime.DatasourceProviders. IReadThruProvider
    {
        private SqlDatasource sqlDatasource;
        // <summary>
        // Responsible for loading the object from the external data source.
        // Key is passed as parameter.
        // <param name="key">item identifier; probably a primary key</param>
        // <param name="exh">Current expiration hint; you can modify the value and attach a new hint</param>
        // <param name="evh">Current eviction hint; you can modify the value and attach a new hint</param>
        // <returns></returns

        public void LoadFromSource(string key, out ProviderCacheItem cacheItem)
        {
            cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
            cacheItem.ResyncItemonExpiration = true;
            cacheItem.ResyncProviderName = sqlDatasource.ConnString;
        }
        // <summary>
        // Perform tasks like allocating resources or acquiring connections
        // </summary>
        ...

Tu implementi questo. Ha un metodo Init che lo inizializza. Un metodo Dispose e in realtà come un metodo Get. Quindi, il get ti passa la chiave e gliela restituisci l'elemento della cache. Quindi, vai alla tua fonte di dati e caricherai quell'elemento, specifichi la scadenza o qualsiasi altra cosa e lo ripassi a NCache. Questo tuo codice viene eseguito sul server cache. Questa è una cosa importante da tenere a mente.

Quindi, il read-through in realtà viene eseguito sul server cache stesso. In realtà, ho un altro diagramma.

Quindi, il read-through viene eseguito sul server cache stesso. Quindi, il server cache deve essere sviluppato in .NET affinché il tuo codice .NET possa essere eseguito su di esso, giusto? Quindi, se il tuo negozio .NET, se la tua applicazione è in .NET, il motivo per cui ho detto che l'intero stack del tuo dovrebbe essere .NET per tutti questi vantaggi.

Quindi, venendo a, per esempio Redis, Redis è una cache basata su Linux. Quindi, è un'ottima cache, non ho nulla contro di loro, ma se sei un negozio .NET devi fare tutte queste cose e il tuo codice deve essere eseguito sul server cache affinché la cache sia in grado di sincronizzarsi con il database e ricaricare automaticamente quell'elemento dal database. Quindi, il tuo gestore di lettura è ciò che viene chiamato quando viene attivata una dipendenza SQL, se lo desideri in questo modo. Se non lo vuoi, rimuoverà semplicemente quell'elemento dalla cache. E, quando viene rimosso dalla cache, la prossima volta che l'applicazione lo cerca, non lo troverà e andrà a recuperarlo dal database. Ora, in alcuni casi, ad esempio, è un catalogo di prodotti che hai memorizzato nella cache e hai appena aggiornato il prezzo. Perché rimuovere il prodotto dalla cache, hai appena aggiornato il prezzo? Perché ora l'applicazione deve avere la logica per andare a prenderla dal database. È meglio ricaricare automaticamente.

Quindi, molti dei dati se pensi che saranno necessari più e più volte o alla scadenza o quando si verifica la sincronizzazione del database, è meglio ricaricarli piuttosto che rimuoverli. Perché quindi l'applicazione non deve farlo. Più è la cache, più facile diventa l'applicazione. Quindi, un altro modo in cui la cache può sincronizzarsi con il database. Quindi, se non hai SQL Server o Oracle, diciamo, hai MySQL o DB2, quindi queste due funzionalità che esistono, puoi usare la dipendenza DB, che è un'altra caratteristica di NCache quello dove NCache raggruppa una tabella specifica e modifichi i trigger del database per aggiornare il flag in quella riga. NCache lo prende e dice che questo articolo è cambiato. Quindi, ho bisogno che tu lo rimuova o lo ricarichi.

Utilizzo delle stored procedure CLR

Le procedure CLR sono un altro modo per sincronizzare la cache con il database. Dove in realtà scrivi a procedura CLR. Lo chiami dal trigger del tuo tavolo. Quindi, diciamo, se hai un trigger Aggiungi o Aggiorna o Elimina. Tu chiami questa procedura CLR, chiama NCache oppure chiama la cache.

In caso di procedura CLR è necessario assicurarsi che la cache supporti metodi asincroni quali NCache fa. Quindi, puoi effettuare in una cache come una chiamata asincrona di inserimento e il controllo torna immediatamente a te. Perché, se non esegui la chiamata asincrona, le transazioni del database iniziano a scadere. Perché, stai aggiornando più server nella cache, stai attraversando la rete che non è ciò che una transazione di database è progettata per loro. Quindi, devi avere una chiamata asincrona.

Quindi, questi sono i tre modi in cui puoi sincronizzare la cache. Quindi, qualsiasi cache che hai pagato devi assicurarti di poter mantenere i dati aggiornati. Questi sono i due modi.

Sincronizza la cache con il non relazionale

Allo stesso modo se hai un'origine dati non relazionale, diciamo, hai i tuoi dati nel cloud o in qualsiasi altro posto. Puoi anche voler effettuare una chiamata al metodo web. Puoi effettivamente implementare una dipendenza personalizzata che è di nuovo il tuo codice che si registra e viene eseguito sui server di cache e NCache lo chiama e dice per favore vai a controllare la tua fonte di dati se è cambiata o meno. Si controlla l'origine dati, se è cambiata si avvisa NCache quei dati e l'origine dati sono cambiati. Così, NCache può rimuoverlo o ricaricarlo.

Quindi, sempre con un database relazionale NCache fa tutto per te. In caso di non relazionale, devi fare una dipendenza personalizzata.

Gestire i dati relazionali

L'ultimo aspetto di mantenere la cache fresca sono le funzionalità di dipendenza. Diciamo, se hai una relazione uno-a-molti tra un cliente e un ordine e li stai memorizzando entrambi nella cache. Cosa succede se l'oggetto cliente viene rimosso dalla cache? Gli ordini devono rimanere nella cache o no? Cosa succede se hai effettivamente eliminato il cliente dal database. Bene, di solito non elimini i clienti, quando dico uno a molti. Diciamo, cosa succederebbe se l'unico lato rimosso dalla cache significasse davvero che potresti averlo rimosso anche dal database. Ciò significa che il lato dei molti non è più valido. Quindi, chi dovrebbe tenere traccia di tutto questo? Se la cache può farlo per te, allora ti rende la vita molto più semplice.

Ad esempio, l'oggetto cache ASP.NET ha questa funzionalità chiamata dipendenza dalla cache. NCache lo ha implementato e per quanto ne so, nessun'altra cache .NET ha questa funzionalità. Ma, in pratica, registri la relazione tra gli articoli e dici che questo dipende da questo articolo, se questo articolo viene mai aggiornato o rimosso, rimuovilo automaticamente. Quindi, la cache fa la pulizia per te.

Più la cache fa per te, meglio è per te perché puoi essere certo che i tuoi dati saranno aggiornati. Una volta che hai questa sicurezza, puoi memorizzare nella cache praticamente tutti i dati. È solo una questione di quale strategia utilizzerai per mantenere aggiornati i dati.

Trovare i dati

Quindi, ora che hai la certezza che i dati siano freschi, inizierai a memorizzare nella cache molti dati. Bene, una volta che inizi a memorizzare nella cache tutti i dati, la prossima cosa che arriva è che la cache ora inizia a sembrare sempre più simile a un database. Non è un database, è sempre un archivio temporaneo. Ma, soprattutto molti di quei dati di riferimento, memorizzi praticamente l'intero set di dati nella cache. Quando ciò accade, vuoi essere in grado di cercarlo. Invece di trovarlo sempre in base alle chiavi, è molto scomodo. Trovare qualsiasi elemento in base alla chiave non è sempre conveniente. Vuoi essere in grado di cercarlo con altri mezzi.

Un modo è fare un Ricerca SQL. Ancora, SELEZIONA Clienti DOVE clienti.Città = "New York". Proprio come faresti o diresti dammi tutti i miei prodotti di questa categoria. Quindi, otterrai una raccolta di quegli oggetti dalla cache, non dal database. Provenire dalla cache significa ovviamente che il database non deve più ricevere quel colpo ed è tutto in memoria. È molto più veloce poiché proviene da più server contemporaneamente.

Quindi, tutte queste sono query parallele. E, per poterlo fare, la cache deve supportare l'indicizzazione, che NCache fa. Non sono sicuro che altri prodotti lo facciano o meno, ma assicurati che la cache supporti l'indicizzazione. Altrimenti, saranno query davvero molto lente.

Raggruppamento di dati

Una cosa che non puoi fare in una cache è unire più oggetti o più tabelle che è ciò che puoi fare nel database relazionale. Quindi, ci sono modi per aggirare il problema che è che puoi raggruppare le cose, puoi taggarle in determinati modi per recuperarle e in questo modo puoi recuperare i dati in base ad alcune associazioni logiche o raggruppamenti che si trovano nella cache. Quindi, diciamo che se memorizzi tutto nella cache, ti farò un esempio. Ad esempio, supponiamo che tu abbia indietro una collezione di clienti. Quindi, ho una raccolta di tag oggetto e voglio memorizzare nella cache ogni oggetto separatamente nella cache. Ma, in seguito, voglio essere in grado di recuperare tutto in una chiamata.

//Caching Query Results (Collection)
//Cache Collection Objects Separately
static void CacheSupplierProducts(NorthwindEntities context, int supplierId)
{
    Tag[] productTags = new Tag[1];
    productTags[0] = new Tag("SupplierProducts:" + supplierId);
    
    IQueryable<Product> products = context.Products;
    
    var result = from product in products
                  where product.SupplierID == supplierId
                  select product;
                  
    foreach (Product p in result)
    {
        String key = "Products:ProductId:" + p.ProductID;
        _cache.Insert(key, p, productTags);
    }
}
...
ICollection productList = _cache.GetByAnyTag(productTags).Values;

Quindi, o emetto la stessa query, query SQL e dico di restituirmi tutte le cose. Ma ho ottenuto questi oggetti dal database, non li ho presi dalla cache. E non sono un intero set di dati. Diciamo, qualunque sia il set che volevo recuperare in quel momento. Quindi, ho memorizzato nella cache ogni oggetto individualmente a cui potrei aver bisogno di accedere individualmente. Ma voglio essere in grado di recuperare tutto come una raccolta. Quindi, uso il concetto di tag. Li ho taggati tutti con lo stesso tag. E quel tag potrebbe essere qualsiasi stringa univoca e dico di darmi tutti gli elementi che hanno questo tag. Quindi, in una chiamata posso riavere di nuovo tutta l'intera collezione. Quindi, è quel tipo di cose che puoi fare con i tag, questo tipo di compensa la mancanza di join nella cache.

Quindi, puoi fare il raggruppamento. Il gruppi e sottogruppi. Tu puoi fare tag. Puoi creare tag con nome. Tag con nome essenzialmente hai una chiave e poi un valore. Se stai memorizzando nella cache, ad esempio, testo, testo in formato libero. Non c'è modo di indicizzare quel testo da solo perché è testo. Quindi, devi creare tu stesso i tag e taggarti da solo potrebbe non essere sufficiente. Vuoi essere in grado di nominare ogni tag.

Quindi, proprio come un oggetto ha nomi di attributi. Quindi, il tag del nome è come gli attributi di un oggetto. Quindi, il nome potrebbe essere città e il valore in questo testo potrebbe essere New York o Las Vegas. Quindi, puoi fare tutte quelle cose e poi recuperare quelle cose e in caso di NCache almeno puoi usarlo se specifichi tutto questo tramite l'API o tramite il Query SQL. Quindi, quando stai recuperando qualcosa basato su SQL ...

Prima domanda, ottimo! Possiamo usare tassonomie gerarchiche? Quello che puoi fare in realtà è... i gruppi e i sottogruppi ti danno un solo livello di gerarchia. Quindi, all'interno di un gruppo puoi avere più sottogruppi ma non puoi andare oltre.

Puoi utilizzare diversi tipi di tag per rappresentare perché puoi assegnare più tag a un elemento. Quindi, ad esempio, se avevi più gerarchie, puoi assegnare per ogni livello che scendi puoi assegnare tutti i primi di ogni livello come tag separato.

Un'altra domanda. Possiamo controllare la rappresentazione interna della cache? Gli indici sono costruiti in base alla combinazione di tabelle hash, in caso di NCache, e alberi rossi neri. Puoi scegliere gli indici ma non scegliere quale struttura dati verrà utilizzata, internamente. Ma gli indici sono costruiti in base alla natura dell'uso. Quindi, ad esempio, le tabelle hash sono buone per alcuni tipi di accesso e se hai intenzione di eseguire ricerche di tipo intervallo, gli alberi rossi e neri sono molto meglio. Così la NCache lo fa. Non so cosa facciano gli altri prodotti ma NCache indicizza roba un bel po'.

Read-through e write-through

Fammi passare rapidamente attraverso il leggere, scrivere. Quindi, perché vuoi leggere e scrivere? Durante la lettura, ne abbiamo visto un esempio, ovvero che potresti ricaricare automaticamente le cose.

Un altro vantaggio del read-through è ovviamente che stai consolidando la maggior parte dei tuoi dati di accesso nella cache stessa. Più accedi... più questo entra nella cache o nel livello di memorizzazione nella cache, meno è nella tua applicazione e l'applicazione diventa più semplice. L'applicazione fa solo un cache.Get e ovviamente l'altro vantaggio era che puoi caricare automaticamente le cose.

Il write-through è allo stesso modo. Un vantaggio è che hai consolidato tutte le scritture. Il secondo vantaggio è che puoi effettivamente accelerare le tue scritture. Quindi, ad esempio, write-behind è una funzionalità in cui si aggiorna la cache in modo sincrono e la cache aggiorna il database in modo asincrono. Quindi, se gli aggiornamenti del database non sono veloci quanto la cache, il che è vero, le prestazioni dell'applicazione migliorano improvvisamente perché aggiornerai solo la cache e il database degli aggiornamenti della cache.

Quindi, il read-through, il write-through e il write-behind sono funzionalità davvero molto potenti di cui dovresti trarre vantaggio. Questo è anche codice lato server che scrivi che viene eseguito sul cluster di cache e ti semplifica la vita. In questo modo, la tua applicazione può avere più dati nella cache e aggiornarla anche tramite la cache.

Lascia che lo esamini velocemente e parli di qualcosa. Non entrerò nel dettaglio di Memorizzazione nella cache dello stato della sessione ASP.NET. Sappi solo che puoi semplicemente collegarlo senza alcuna modifica al codice e apportare modifiche a web.config e se ne occuperà automaticamente e la stessa cosa vale stato di visualizzazione ed cache di output.

Alta disponibilità (tempo di attività del 100%)

Passerò velocemente attraverso un paio di cose. Per prima cosa volevo parlare di... Qualsiasi cache che usi, perché è come un database, è un database in memoria in produzione. Quindi, una cache deve essere altamente disponibile. Devi avere una cache altamente disponibile.

Cluster di cache dinamica

NCache è altamente disponibile attraverso un paio di cose che fa. Innanzitutto ha un cluster di cache dinamica. È possibile aggiungere o rimuovere server in fase di esecuzione e il cluster riadatta automaticamente. Non è necessario codificare i nomi dei server nella configurazione, i client automaticamente. Una volta che un client comunica con qualsiasi server di cache, ottiene informazioni sull'appartenenza al cluster. Se l'appartenenza cambia in fase di esecuzione, supponiamo che tu aggiunga un nuovo nodo o elimini un nodo, l'appartenenza aggiornata viene propagata al client.

Quindi, questa è la prima parte che deve essere lì. È davvero importante che tu la veda in questo modo.

Topologie di memorizzazione nella cache

La seconda è la topologia della memorizzazione nella cache. Quindi, ci sono diversi modi per farlo NCache, ad esempio, ti darà quattro topologie di memorizzazione nella cache. Il primo si chiama a cache specchiata. È un 2 nodi attivo/passivo.

I secondi sono chiamati Cache replicata, dove ogni server nella cache ha una copia dell'intera cache. Quindi, più server hai, più copie di cache hai. È scalabile per la lettura, non scalabile per gli aggiornamenti. Ma ha il suo uso con i casi.

Viene chiamata la terza topologia Cache partizionata, dove l'intera cache è suddivisa in partizioni. Ogni server è una partizione. E queste partizioni vengono create automaticamente.

Quindi, ad esempio, in caso di NCache ogni partizione ha un numero di bucket al suo interno. Quindi, il cluster totale ha 1,000 bucket. Quindi, se hai tre partizioni, hanno un terzo, un terzo numero di bucket.

Replica partizionata è lo stesso con la partizione, ma viene eseguito il backup di ogni partizione su un server diverso e tutto ciò viene eseguito automaticamente per te. Quindi, quando crei un cluster a due nodi, avrai due partizioni, le due repliche. Quando aggiungi un terzo server, automaticamente, viene creata una terza partizione e quando viene creata una terza partizione alcuni dei bucket devono essere spostati dalla partizione esistente.

Quindi, tutto ciò viene fatto automaticamente per te. Viene creata automaticamente una nuova replica. In effetti, se lo vedi da questo, lascia che te lo mostri, qui. Diciamo che se hai una partizione a due server ... ma diciamo che se hai solo un cluster di due server, hai due partizioni. La partizione 1 era qui e la replica 1. Partizione 2, replica 2. Ora, hai aggiunto un terzo server, improvvisamente devi avere una terza partizione e questo otterrà alcuni dei secchi da qui, altri da qui, questa è una cosa. In secondo luogo, la replica 2 non sarà più qui, si sposterà qui perché ora la replica per la partizione 3 deve essere qui.

Quindi, tutta quella regolazione viene eseguita automaticamente per te da NCache. Quindi, questa è una cosa. In secondo luogo, c'è una funzione chiamata Cache cliente alcune persone lo chiamano Near Cache, che è davvero potente che devi usare. Fondamentalmente è una cache locale all'interno dell'applicazione client. Ma c'è una cosa speciale in questo è che questa cache locale non è disconnessa con il cluster di cache. È connesso al cluster di cache. Si mantiene sincronizzato.

Quindi, in caso di NCache, ad esempio, la cache del client si collega automaticamente dietro le quinte a un file config. Qualunque cosa tu recuperi da ciascuna di queste applicazioni, i server sono ciò che viene automaticamente conservato nella cache del client. Quindi, la prossima volta che ne avrai bisogno, lo troverai nella cache del client. Inoltre, il cluster di cache sa quali dati si trovano in quale cache del client. Quindi, se quei dati cambiano, diciamo, da un altro client, il cluster notifica a tutte le cache client che hanno quei dati di andare ad aggiornarsi. Quindi, la cache del client rimane connessa ma è una cache locale. Può essere anche In-Proc. In-Proc significa all'interno del processo di candidatura. Quindi, ciò accelera davvero le tue prestazioni ma allo stesso tempo fai parte della cache distribuita connessa complessiva.

Replica WAN

Salterò molte cose, non abbiamo tempo. Quindi, c'è anche Replica WAN. Se disponi di più data center, dovresti essere in grado di replicare la cache sulla WAN e non puoi creare un cluster sulla WAN. Questo morirà solo perché questi socket si rompono, la latenza è solo molto alta. Quindi, ci deve essere un modo per connettere le cache tra due data center.

In caso di NCache abbiamo questa cosa chiamata topologia bridge che collega più datacenter. Ora puoi avere attivo-attivo, attivo-passivo o anche più di due datacenter. E tutto questo viene fatto in modo asincrono e c'è anche la risoluzione dei conflitti fatta per te. Quindi, come puoi vedere, una cache non è solo un semplice archivio di valori chiave. Quindi, ci sono molte cose che dovresti tenere a mente dietro le quinte.

NCache vs. Redis

Una cosa che volevo rapidamente coprire era NCache vs. Redis, solo di alto livello, volevo parlare di questo. NCache è la cache .NET nativa. Funziona su Windows e puoi eseguire sia la memorizzazione nella cache lato client che quella lato server, questo è un vantaggio. Invece, Redis è principalmente una cache basata su Linux. Prima che Microsoft stabilisse una partnership con loro, la maggior parte delle persone sul lato .NET non sapeva nemmeno che esistessero, anche se sono state una cache molto popolare su Unix e PHP e altri ambienti.

In secondo luogo, la versione Linux di NCache è disponibile in Azure, come Cache as a Service. Quindi, il motivo è la cache come servizio perché per le applicazioni .NET non puoi davvero eseguire codice lato server su una cache basata su Linux. Devi avere una cache basata su .NET per l'esecuzione. Quindi, questa è un'enorme limitazione che otterrai.

Terzo, se hai intenzione di fare qualcosa al di fuori di Azure, Redis è disponibile solo come cache basata su Linux. Il supporto per le finestre che Microsoft ha fatto è qualcosa che non usano da soli. Anche su Azure non scelgono di usarlo su Windows. Non è molto stabile. Ci sono anche più dettagli se vuoi vederne uno più dettagliato confronto tra NCache ed Redis, puoi venire qui e poi vedere i confronti. Quindi, abbiamo confronto con tutti, perché siamo così sicuri di noi.

Quindi, come puoi vedere, questo è un confronto in piena regola. Basta attraversarlo. Se stai pensando di utilizzare una cache distribuita, cosa che dovresti, hai tutte quelle esigenze di scalabilità. Fai i compiti, assicurati che qualunque cosa usi sia adatta alle tue esigenze. E, per quanto NCache è interessato, ti semplificheremo il confronto NCache con altri. Puoi venire sul nostro sito web e scaricare NCache. È open source. Quindi, puoi scaricare l'edizione Enterprise o quella Open Source qui oppure puoi andare su GitHub e tu avrai NCache

Questa è la fine della mia presentazione. Qualsiasi domanda? È possibile passare una chiamata di stored procedure. Deve essere tutto SQL, come il materiale SQL delle transazioni che verrà eseguito all'interno del server SQL stesso.

Sì. Quindi, la cache può trovarsi sullo stesso server dell'applicazione. Non lo consigliamo. Non è una buona strategia di distribuzione, ma se hai una piccola configurazione, sì, ovviamente.

Quando esegui il partizionamento, tutto il partizionamento viene eseguito per te. Quindi, l'idea è che ogni partizione dovrebbe essere uguale nel suo peso, in termini di dimensione dei dati, in termini di transazioni.

Non controlli le partizioni, sai solo che esistono.

Quando si aggiorna la tabella degli elementi è possibile scegliere di aggiornare la cache dall'interno del database stesso, se si dispone di una procedura CLR in grado di effettuare una chiamata direttamente dal database alla cache. Puoi anche scrivere codice separato che può aggiornare la cache e tutto ciò che dipende da quanto sei e mantieni nella cache.

Quindi, sai, posso parlare di più offline se vuoi. Ma, voglio dire, ci sono molti modi in cui puoi assicurarti che tutti i dati a cui devi accedere siano mantenuti freschi nella cache.

Sì, in realtà, metterò a disposizione le diapositive. Questo è il motivo per cui abbiamo scansionato le email di tutti. Quindi, possiamo farlo e avremo anche il video registrato e caricato. Quindi puoi guardare e anche i tuoi colleghi possono guardarlo.

In realtà, per applicazione o... In realtà per più applicazioni. Quindi, tutto dipende dal carico della transazione. Puoi avere un minimo di 2 server cache solo per avere il cluster e quindi il numero di server dipende da quanti server di applicazioni hai o da quanto, quanta attività hai sostanzialmente? Quanti dati verranno memorizzati nella cache? Quante letture e scritture stai facendo?

Non importa, sì. Sì, tutto continuerà a funzionare. Grazie ragazzi.

Cosa fare dopo?

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