Condividi tramite

Il presente articolo è stato tradotto automaticamente.

Scala fuori

Distribuito la cache sul percorso per la scalabilità

Iqbal Khan

Nell'articolo viene descritto:
  • Cache distribuita
  • Scalabilità
  • Sincronizzazione del database
 In questo articolo utilizza le seguenti tecnologie:
ASP.NET, servizi Web, applicazioni HPC

Contenuto

Distribuiti nella cache
Funzionalità di disponibilità del necessario in cache distribuita
Scadenze
Espulsioni
Memorizzazione nella cache dati relazionali
La sincronizzazione di una cache con altri ambienti
Sincronizzazione database
Read-Through
Scrivere A, la scrittura sottostante
Query cache
Propagazione dell'evento
Cache prestazioni e scalabilità
Disponibilità elevata
Prestazioni
Ottenere la popolarità

applicazione Se si sta sviluppando un ASP.NET , servizi Web o un'applicazione di calcolo ad alte prestazioni (HPC), è probabile che possono verificarsi problemi di scalabilità principali come si tenta di modificare la scala e inserire carico maggiore in un'applicazione. Con un'applicazione ASP.NET, i colli di bottiglia si verifica in archivi dati di due. Il primo è i dati di applicazione che risiedono in un database e l'altra è ASP.NET sessione stato dati in genere memorizzati in una delle tre modalità (InProc, SqlServer o StateServer) fornita da Microsoft. Tutti e tre presentano problemi di scalabilità principali.

I servizi Web non utilizzano in genere lo stato della sessione, ma sono colli di bottiglia a livello di scalabilità quando si tratta di dati dell'applicazione. Come le applicazioni ASP.NET, servizi Web ospitati in IIS e distribuiti in una Web farm per la scalabilità.

Applicazioni HPC progettati per eseguire enormi parallela anche l'elaborazione hanno problemi di scalabilità, perché l'archivio dati non si adatta allo stesso modo. HPC (detto anche elaborazione griglia) è in genere utilizzato Java, ma come .NET guadagni quota di mercato, sta diventando più comune per applicazioni HPC. Distribuzione applicazioni HPC centinaia e anche migliaia di computer per l'elaborazione parallela e devono spesso operano su grandi quantità di dati e la condivisione dei risultati intermedi con altri computer. Applicazioni HPC utilizzano un database o un sistema di file condiviso come un archivio dati ed entrambi questi non scala molto bene.

Distribuiti nella cache

La memorizzazione nella cache è un concetto noto in ambienti hardware e software. Tradizionalmente, la memorizzazione nella cache è stato un meccanismo autonomo, ma che non è realizzabile più in ambienti la maggior parte delle poiché le applicazioni ora eseguito su più server e in più processi all'interno di ogni server.

Cache distribuita in memoria è una forma di memorizzazione nella cache che consente la cache si estendono su più server in modo che può crescere in dimensioni e capacità di transazione. Cache distribuita è diventato possibile per una serie di motivi. Innanzitutto, memoria è diventato molto costosa e si può vari computer con molti gigabyte a prezzi throwaway. In secondo luogo, le schede di rete sono diventati molto veloce con 1Gbit ora ovunque standard e traction l'10Gbit. Infine, a differenza di un server di database che in genere richiede un computer di fascia alta, cache distribuita funziona anche sul computer di costo più basso (come quelle utilizzate per i server Web), che consente di aggiungere facilmente più macchine.

Cache distribuita è scalabile l'architettura che utilizza. Si distribuisce il lavoro tra più server, ma ancora offre una visualizzazione logica di una cache singola. Per i dati dell'applicazione, una cache distribuita conserva una copia di un sottoinsieme dei dati nel database. Questo è destinato a essere un archivio temporaneo, che può significare ore, giorni o settimane. In numerose situazioni, i dati utilizzati in un'applicazione non sono necessario memorizzare in modo permanente. In ASP.NET, ad esempio, i dati della sessione sono temporaneo e necessari per forse alcuni minuti per poche ore al massimo.

Allo stesso modo, nella HPC, parti di grandi dimensioni dell'elaborazione richiede la memorizzazione dei dati intermedi in un archivio dati e questo è anche natura temporaneo. Il risultato finale di HPC potrebbe trovarsi in un database, tuttavia. nella figura 1 viene illustrata una configurazione tipica di una cache distribuita in un'organizzazione.

fig02.gif

Nella figura 1 Distribuiti da cache condivise da diverse applicazioni in un'azienda (fare clic l'immagine per ingrandirla)

Funzionalità di disponibilità del necessario in cache distribuita

Tradizionalmente, gli sviluppatori sono considerati la memorizzazione nella cache soltanto dati statici, i dati di significato non cambia mai tutta la durata dell'applicazione. Ma che i dati in genere sono un sottoinsieme ridotto, forse a 10 %, dei dati che un'applicazione elabora. Sebbene sia possibile salvare i dati statici nella cache, il valore reale deriva se è possibile memorizzare nella cache dati dinamici o transazionali, i dati che varia pochi minuti. È comunque memorizzare perché durante tale periodo, si potrebbe recuperare di decine di volte e salvare che molte andata e ritorno nel database. Se è possibile moltiplicare che migliaia di utenti che tentano di eseguire le operazioni contemporaneamente, è possibile immaginare quanti letture meno che per il database.

Ma se si memorizzano nella cache i dati dinamici, la cache dispone di alcune funzionalità che consente di evitare i problemi di integrità dei dati. Una tipica cache deve disporre di funzionalità per la scadenza e la rimozione di elementi, nonché altre funzionalità. Verranno esplorare queste funzionalità nelle sezioni che seguono.

Scadenze

Scadenze si trovano all'inizio dell'elenco. Consentono di specificare quanto tempo i dati devono rimanere nella cache prima che la cache rimuove automaticamente. È possibile specificare due tipi di scadenze: Runtime assoluto scadenza scadenza e fase scorrevole (o periodi di inattività).

Se i dati della cache è esiste anche in un'origine dati master, significa che questo dati possono essere modificati nel database da utenti o applicazioni che è possibile che non hanno accesso alla cache. In questo caso, i dati nella cache diventano obsoleti. Se si è in grado di stimare il tempo i dati è possibile in modo sicuro mantenere nella cache, è possibile specificare assoluto-data di scadenza, qualcosa, ad esempio, "Scadenza 10 minuti dall'ora l'elemento" o "Scadenza di questo elemento a mezzanotte stasera".

Una variazione interessante per scadenza assoluta è se la cache possibile ricaricare una copia aggiornata dell'elemento memorizzato nella cache direttamente dall'origine dati. Ciò è possibile solo se la cache fornisce un read-through funzionalità (vedere le sezioni successive) e consente di registrare un gestore di read-through Ricarica gli elementi memorizzati nella cache quando si verifica scadenza assoluta. Fatta eccezione per pochi cache esterna, la maggior parte delle cache non supportano questa funzionalità.

È possibile utilizzare periodi di inattività (ora di scorrimento) scadenza per la scadenza di un elemento se non viene utilizzato per un determinato periodo di tempo. È possibile specificare qualcosa di simile a "Scadenza questo elemento." Se nessuno legge o si aggiorna per 10 minuti Questo approccio è utile quando l'applicazione deve temporaneamente i dati, ma al termine dell'applicazione utilizzarlo, si desidera che la cache per automaticamente hanno una scadenza. Lo stato sessione ASP.NET è un ottimo candidato per la scadenza periodi di inattività.

Assoluto-data di scadenza consente di evitare situazioni in cui la cache è una copia dei dati non aggiornata o una copia precedente rispetto alla copia master nel database. Scadenza di periodi di inattività è destinata a pulire la cache dopo l'applicazione non necessita più determinati dati. Anziché l'applicazione per tenere traccia delle operazioni di pulitura necessarie, è possibile consentire la cache di occuparsi di esso.

Espulsioni

Più distribuite cache sono in memoria e non vengono mantenute la cache disco. Ciò significa che nella maggior parte dei casi, la memoria è limitata e la dimensione della cache non può crescere oltre un limite determinato, potrebbe essere la memoria totale disponibile, oppure molto minore che, se si dispone di altre applicazioni in esecuzione sullo stesso computer.

In entrambi i casi, una cache distribuita deve consentire di specificare una dimensione massima della cache (in teoria, in termini di dimensioni della memoria). Raggiungimento di questa dimensione, la cache deve iniziare la rimozione di elementi memorizzati nella cache per liberare spazio per nuovi, un processo in genere denominato espulsioni.

Espulsioni vengono create base vari algoritmi. Più diffuso è meno utilizzati di recente (LRU), in cui vengono rimossi gli elementi memorizzati nella cache che sono stato ignorati ad al tempo massimo. Un altro algoritmo è meno frequente (LFU). In questo caso, gli elementi che sono stati modificati il minor numero di volte in cui viene rimossi. Esistono alcune altre varianti, ma i due sono più comuni.

Memorizzazione nella cache dati relazionali

La maggior parte dei dati provengono da un database relazionale, ma anche se non esiste, è relazionale natura, vale a dire che diverse parti di dati sono correlate a un altro, ad esempio, un oggetto del cliente e un oggetto ordine.

Quando si dispone di queste relazioni, è necessario gestirli in una cache. Ciò significa che la cache necessario conoscere la relazione tra un cliente e un ordine. Se si aggiorna o si rimuove un cliente dalla cache, si consiglia la cache per automaticamente anche aggiornare o rimuovere di oggetti di ordini correlati dalla cache. Questo consente di mantenere l'integrità dei dati in molte situazioni.

Ma anche in questo caso, se non è una cache tenere traccia di queste relazioni, è necessario e che rende l'applicazione più complessa e complessi. È più facile molto se segnala solo che la cache i dati ora viene aggiunto che un ordine è associato a un cliente e cache quindi sa che se quel cliente è aggiornato o rimosso, gli ordini correlati relativi inoltre necessario essere aggiornato o rimosso dalla cache.

Cache di ASP.NET include la funzione davvero interessante CacheDependency, che consente di tenere traccia delle relazioni tra i diversi elementi memorizzati nella cache. Alcune cache esterna dispongono anche di questa funzionalità. nella figura 2 viene illustrato un esempio del funzionamento della cache ASP.NET.

Nella figura 2 mantenere traccia delle relazioni tra elementi cache

using System.Web.Caching;

...

public void CreateKeyDependency()
{
   Cache["key1"] = "Value 1"; 
   // Make key2 dependent on key1.
   String[] dependencyKey = new String[1];
   dependencyKey[0] = "key1";
   CacheDependency dep1 = new CacheDependency(null, dependencyKey);

   Cache.Insert("key2", "Value 2", dep2);
}

Si tratta di una dipendenza su più livelli, significato che A può dipendere da B e B può dipendere da c. In questo modo, se l'applicazione rimuove C, A e B devono essere rimosse dalla cache nonché.

La sincronizzazione di una cache con altri ambienti

Scadenze e funzionalità di dipendenza di cache sono utili per mantenere la cache nuova e corretta. È inoltre necessario sincronizzare la cache con origini dati che sia la cache non dispongono dell'accesso in modo che le modifiche in tali origini dati sono riflesse nella cache per mantenerlo aggiornato.

Ad esempio, si supponga la cache viene scritto utilizzando Microsoft .NET Framework, ma si sono applicazioni di Java o c ++ modifica dei dati nell'origine dati master. Si desidera che queste applicazioni per notificare la cache quando vengono modificati alcuni dati nelle origini dati master in modo che la cache può invalidare un elemento memorizzato nella cache corrispondente.

In teoria, la cache deve supportare questa funzionalità. In caso contrario, questo carico se dell'applicazione in uso. Cache di ASP.NET fornisce questa funzionalità tramite CacheDependency, come eseguire alcune soluzioni di memorizzazione nella cache esterna. Consente di specificare che un determinato elemento memorizzato nella cache dipende da un file e che ogni volta che questo file è aggiornato o rimosso, la cache rileva questo e invalida l'elemento memorizzato nella cache. Invalidare impone l'elemento all'applicazione di recuperare la copia più recente di questo oggetto alla successiva ora l'applicazione si deve e non si trova nella cache.

Se si dispone di 100.000 elementi nella cache, 10.000 di esse disponga di dipendenze tra i file e per cui potrebbe essere 10.000 file in una cartella speciale. Ogni file ha un nome speciale associato a tale elemento memorizzato nella cache. Quando un'altra applicazione, se scritto in. NET, o non, modifica i dati nell'origine dati master, che un'applicazione può comunicare alla cache tramite un aggiornamento del timestamp di file.

Sincronizzazione database

La necessità di sincronizzazione del database si verifica perché il database è condivisa tra più applicazioni, e non tutte le applicazioni hanno accesso nella cache. Se l'applicazione è l'unica applicazione l'aggiornamento del database inoltre possibile aggiornare la cache, probabilmente non è necessario la funzionalità di sincronizzazione del database. Ma in un ambiente reale, che non sempre il caso. Ogni volta che una terza parte o qualsiasi altra applicazione modifica i dati del database, si desidera che la cache per riflettere tale modifica. La cache riflette le modifiche per ricaricare i dati o almeno, non utilizzare i dati precedenti nella cache.

Se la cache è una copia precedente e il database una nuova copia, ora è un problema di integrità dei dati poiché non si conosce la copia è da destra. Naturalmente, il database è sempre a destra, ma è sempre non accedere a database. È possibile ottenere dati dalla cache perché l'applicazione concede il trust che la cache sempre sarà corretta o che la cache sia corretta per le esigenze.

Sincronizzazione con il database può significare invalidare l'articolo correlato nella cache in modo che alla successiva che l'applicazione deve, verrà recuperato, livello di dal database. Una variante interessante a questo processo è quando la cache ricarica automaticamente una copia aggiornata dell'oggetto quando i dati vengono modificati nel database. Tuttavia, questo è possibile solo se la cache consente di fornire un gestore read-through (vedere la sezione successiva) e quindi viene utilizzato per ricaricare l'elemento dal database memorizzato nella cache. Tuttavia, solo una parte della cache esterna supporta questa funzionalità e nessuno di quelli liberi eseguire.

Cache ASP.NET è una funzionalità di SqlCacheDependency (vedere la Figura 3 ) che consente di sincronizzare la cache con un SQL Server 2005/2008 o Oracle 10 g R2 i database della versione successiva, essenzialmente qualsiasi database che dispone di CLR di .NET incorporato. Alcuni delle cache esterna di fornire anche di questa funzionalità.

Nella figura 3 utilizzo di SqlDependency per la sincronizzazione con un database relazionale

using System.Web.Caching;
using System.Data.SqlClient;

...

public void CreateSqlDependency(Customers cust, SqlConnection conn)
{
  // Make cust dependent on a corresponding row in the
  // Customers table in Northwind database
  string sql = "SELECT CustomerID FROM Customers WHERE ";
  sql += "CustomerID = @ID";
  SqlCommand cmd = new SqlCommand(sql, conn);
  cmd.Parameters.Add("@ID", System.Data.SqlDbType.VarChar);
  cmd.Parameters["@ID"].Value = cust.CustomerID;

  SqlCacheDependency dep = new SqlCacheDependency(cmd);
  string key = "Customers:CustomerID:" + cust.CustomerID;

  Cache.Insert(key, cust, dep);
}

SqlCacheDependency cache ASP.NET consente di specificare una stringa SQL per associare una o più righe in una tabella di database. Se questa riga viene sempre aggiornata, il DBMS genera un evento di .NET che intercetta la cache. Quindi sapere quale elemento memorizzato nella cache è correlato a questa riga nel database e invalida l'elemento memorizzato nella cache.

Una funzionalità cache ASP.NET non è disponibile ma che alcune soluzioni esterna è database basato sul polling di sincronizzazione. Questa funzionalità è utile in due casi. In primo luogo, se il DBMS non dispone di CLR di .NET incorporato, è impossibile trarre vantaggio dal SqlCacheDependency. In questo caso, sarebbe utile se la cache potrebbe eseguire il polling del database in base a intervalli configurabile e rilevare le modifiche in determinate righe di una tabella. Se le righe sono state modificate, la cache invalida i propri elementi memorizzati nella cache corrispondente.

La seconda situazione è quando i dati del database viene modificato spesso e gli eventi .NET stanno diventando troppo concisi. Ciò si verifica perché viene generato un evento .NET separato per ogni modifica SqlCacheDependency, e se si dispone di migliaia di righe che vengono aggiornate spesso, questo potrebbe crowd facilmente la cache. In questi casi, è molto più efficiente si basano sul polling, in cui con query di un database è possibile recuperare centinaia o migliaia di righe che sono stati modificati e quindi invalidano elementi memorizzati nella cache corrispondenti. Ovviamente, polling crea un leggero ritardo nella sincronizzazione (forse 15–30 secondi), ma ciò è accettabile in molti casi.

Read-Through

In poche parole, read-through è una funzionalità che consente la cache di leggere direttamente i dati dell'origine dati, tutto ciò che potrebbe essere. Scrivere un gestore read-through e registrarlo con la cache e quindi la cache chiama questo gestore in momenti appropriati. la figura 4 Mostra un esempio.

Nella figura 4 esempio di un gestore Read-Through per SQL Server

using System.Web.Caching;
using System.Data.SqlClient;
using Company.MyDistributedCache;

...

public class SqlReadThruProvider : IReadhThruProvider
{
  private SqlConnection _connection;

  // Called upon startup to initialize connection
  public void Start(IDictionary parameters)
  {
    _connection = new SqlConnection(parameters["connstring"]);
    _connection.Open();
  }

  // Called at the end to close connection
  public void Stop() { _connection.Close(); }

  // Responsible for loading object from external data source
  public object Load(string key, ref CacheDependency dep)
  {
    string sql = "SELECT * FROM Customers WHERE ";
    sql += "CustomerID = @ID";
    SqlCommand cmd = new SqlCommand(sql, _connection);
    cmd.Parameters.Add("@ID", System.Data.SqlDbType.VarChar);

    // Let's extract actual customerID from "key"
    int keyFormatLen = "Customers:CustomerID:".Length;
    string custId = key.Substring(keyFormatLen,
    key.Length - keyFormatLen);
    cmd.Parameters["@ID"].Value = custId;

    // fetch the row in the table
    SqlDataReader reader = cmd.ExecuteReader();

    // copy data from "reader" to "cust" object
    Customers cust = new Customers();
    FillCustomers(reader, cust);

    // specify a SqlCacheDependency for this object
    dep = new SqlCacheDependency(cmd);
    return cust;
  }
}

Poiché una cache distribuita, in genere, si trova all'esterno dell'applicazione, viene condiviso tra più istanze dell'applicazione o anche più applicazioni. Una funzionalità di importanti di un gestore read-through è che i dati che è memorizzare nella cache viene recuperati dalla cache direttamente dal database. Di conseguenza, le applicazioni non necessario disporre di codice del database. Appena possibile recuperare dati dalla cache e, se la cache non sia stato, la cache passa e accetta dal database.

Si otterranno vantaggi ancora più importanti se si combinano le funzionalità di read-through con scadenze. Ogni volta che un elemento nella cache scade, la cache ricarica automaticamente mediante la chiamata al gestore read-through. Con questo meccanismo di risparmiare molto traffico al database. La cache utilizza un solo thread, di un viaggio di database, per ricaricare i dati che del database, mentre si dispone di migliaia di utenti tenta di accedere gli stessi dati. Se non fosse stato read-through funzionalità, tutti gli utenti dovrebbe essere sarà direttamente al database, inundating il database con migliaia di richieste parallele.

Read-through consente di stabilire una griglia di dati a livello di organizzazione, ovvero un archivio di dati che non solo è scalabile, ma può anche aggiornamento da origini dati master. Questo fornisce le applicazioni con un'origine dati alternativa da cui leggere i dati e si evita numerose alla pressione dei database.

Come accennato in precedenza, database sono sempre il collo di bottiglia in ambienti di transazione elevata e diventano i colli di bottiglia a causa di eccessive principalmente per operazioni di lettura, anche rallentano le operazioni di scrittura. La presenza di una cache che funge da una griglia di dati a livello di organizzazione di sopra del database consente alle applicazioni un incremento di prestazioni e scalabilità principale.

Tuttavia, tenere presente che read-through non sostituisce per eseguire alcune query join complessi nel database. Una tipica cache non è possibile eseguire questi tipi di query. Una funzionalità read-through funziona bene per un singolo oggetto per operazioni di lettura ma non nelle operazioni che comportano complesse query unite in join, è sempre necessario eseguire le operazioni nel database.

Scrivere A, la scrittura sottostante

Write-through è analogo a quello read-through: è fornire un gestore e la cache chiama il gestore, che scrive i dati al database ogni volta che si aggiorna la cache. Un vantaggio di principale è che l'applicazione non deve necessariamente scrivere direttamente nel database perché la cache è... Ciò semplifica il codice dell'applicazione perché la cache, anziché l'applicazione, è il codice di accesso ai dati.

In genere, l'applicazione emette un aggiornamento per la cache (ad esempio, Aggiungi, Inserisci o Rimuovi). La cache si autoaggiorna prima e quindi genera una chiamata di aggiornamento al database tramite il gestore write-through. L'applicazione attende finché non vengono aggiornati sia la cache e il database.

Cosa succede se si desidera attendere la cache per essere aggiornato, ma si non desidera attendere che il database per essere aggiornato perché che rallenta le prestazioni dell'applicazione? Ecco entra in gioco write-behind, che utilizza lo stesso gestore write-through ma aggiorna la cache in modo sincrono e il database in modo asincrono. Ciò significa che l'applicazione attende che la cache per essere aggiornato, ma non attendere per il database da aggiornare.

Si conosce l'aggiornamento del database è messe e che il database viene aggiornato abbastanza rapidamente dalla cache. Si tratta di un altro metodo per migliorare le prestazioni dell'applicazione. È necessario scrivere comunque nel database, ma attendere perché? Se la cache contiene i dati, anche non subiscono le conseguenze di altre istanze dell'applicazione non trova i dati nel database perché aggiornato la cache e le altre istanze dell'applicazione verranno trovare i dati nella cache e non è necessario passare al database.

Query cache

In genere, l'applicazione Trova oggetti nella cache in base a una chiave, come una tabella di hash, come si è visto negli esempi di codice sorgente precedenti. Si dispone della chiave e il valore è l'oggetto. Ma a volte è necessario cercare gli oggetti in base agli attributi diverso la chiave. Di conseguenza, la cache deve fornire la funzionalità è alla ricerca o alla query la cache.

Esistono un paio di metodi che è possibile eseguire questa operazione. Uno consiste nell'eseguire la ricerca di attributi dell'oggetto. L'altro prevede situazioni in assegnate tag non autorizzato agli oggetti memorizzati nella cache che si desidera eseguire la ricerca in base a tag. Basato su attributi di ricerca è attualmente disponibile solo in alcune soluzioni commerciali tramite linguaggi di query di oggetto, ma basato su tag la ricerca è disponibile nella cache esterna e nella velocità di Microsoft.

Si supponga di che aver salvato un oggetto del cliente. È possibile pronunciare, "Assegnazione me tutti i clienti in cui la città è San Francisco" quando si desidera solo cliente oggetti, anche se la cache è di dipendenti, clienti, ordini, ordinare gli elementi e altro ancora. Quando si utilizza una query di tipo SQL come quella illustrata nella Figura 5 , trova gli oggetti che corrispondono ai criteri specificati.

Nella figura 5 tramite una query LINQ alla ricerca di elementi nella cache

using Company.MyDistributedCache;

...

public List<Customers> FindCustomersByCity(Cache cache, string city)
{
  // Search cache with a LINQ query
  List<Customers> custs = from cust in cache.Customers
                          where cust.City == city
                          select cust;
  return custs;
}

Assegnazione di tag consente si allega più tag arbitrario a un oggetto specifico e lo stesso tag può essere associato a più oggetti.I tag sono in genere basati su stringa e l'assegnazione dei tag consente anche di classificare gli oggetti in gruppi e quindi individuare gli oggetti in un secondo momento tramite questi tag o gruppi.

Propagazione dell'evento

Potrebbe non essere sempre necessario propagazione dell'evento nella cache, ma è un'importante funzionalità è necessario conoscere.Si tratta di una buona funzionalità se distribuito applicazioni, applicazioni HPC o più applicazioni di condivisione dei dati tramite una cache.Propagazione quale evento è è chiedere la cache per generare eventi quando si verificano determinati eventi nella cache.Le applicazioni possono acquisire questi eventi e intraprendere le azioni appropriate in risposta.

Si supponga che l'applicazione ha recuperato un oggetto dalla cache e visualizzarle all'utente.Potrebbe essere interessato a conoscere se chiunque Aggiorna o si rimuove questo oggetto dalla cache mentre viene visualizzato.In questo caso, l'applicazione riceverà una notifica ed è possibile aggiornare l'interfaccia utente.

Si tratta, ovviamente, è un esempio molto semplice.In altri casi, potrebbe essere un'applicazione distribuita in cui alcune istanze dell'applicazione sono produrre dati ed è necessario utilizzarlo altre istanze.Il producer può informare gli utenti quando i dati sono pronti generando un evento tramite la cache che ricevono i consumer.Esistono molti esempi di questo tipo, in cui collaborazione o condivisione tramite la cache dei dati possono essere ottenuti tramite la propagazione dell'evento.

Cache prestazioni e scalabilità

Quando si considerano le funzionalità di memorizzazione nella cache illustrate nelle sezioni precedenti, non deve dimentichi che principale motivi che Thinking dell'utilizzo di una cache distribuita, che sono per migliorare le prestazioni e, più importante, per migliorare la scalabilità dell'applicazione.Inoltre, poiché la cache viene eseguito in un ambiente di produzione come server, deve anche fornire un'elevata disponibilità.

Scalabilità è il problema fondamentale che gli indirizzi di una cache distribuita.Una cache scalabile è quello che può garantire prestazioni anche quando si aumenta il carico delle transazioni.In questo modo, se si dispone di un'applicazione ASP.NET in una Web farm e crescita di Web farm da cinque server Web per 15 o persino 50 server Web, non sarà in grado di aumentare il numero di server di cache in modo proporzionale e mantenere il tempo di risposta stesso.Si tratta di un elemento che non è possibile eseguire con un database.

Una cache distribuita consente di evitare i problemi di scalabilità che in genere perché è molto più semplice di natura più un DBMS deve affrontare un database e inoltre perché utilizza meccanismi di archiviazione diverso (noto anche come cache topologie) da un DBMS.Questi includono replicate, partizionata e topologie di cache del client.

In situazioni di cache distribuite in più, sono disponibili due o più server di cache che ospitano la cache.Si utilizzerà il termine "cluster cache" per indicare due o più server di cache unite alla cache di logica un modulo.Una cache replicata copia l'intera cache su ogni server di cache del cluster di cache.Ciò significa che una cache replicata fornisce un'elevata disponibilità.In caso di qualsiasi server di cache un verso il basso, tutti i dati nella cache non persi perché un'altra copia è immediatamente disponibile per l'applicazione.È anche una topologia estremamente efficiente e fornisce la scalabilità grande se l'applicazione deve eseguire numerose operazioni di lettura in modo intensivo.Quando si aggiungono più server di cache, aggiungere tale capacità molto più della transazione di lettura del cluster di cache.Ma non la topologia ideale per le operazioni di scrittura in modo intensivo di una cache replicata.Se si sta aggiornando la cache spesso sono lettura, non utilizzare la topologia di replica.

Una cache partizionata interrompe la cache in partizioni e quindi archivia una partizione in ogni server della cache del cluster.Questa topologia è più scalabile per memorizzazione nella cache i dati transazionali (quando operazioni di scrittura della cache sono di frequente come letture).Quando si aggiungono più server di cache per il cluster, è aumentare non solo la capacità di transazione, ma anche la capacità di archiviazione della cache, poiché tutte le partizioni tali costituiscono l'intera cache.

Cache distribuite molti forniscono una variante di una cache partizionata per un'elevata disponibilità, in cui ogni partizione anche viene replicati in modo server una cache contiene una partizione e una copia o un backup della partizione del server.In questo modo, non perdere i dati se qualsiasi un server viene interrotto.Alcune soluzioni di memorizzazione nella cache consentono di creare più di una copia di ciascuna partizione di affidabilità aggiunto.

Un'altra topologia molto potente di memorizzazione nella cache è di cache di client (anche chiamata nella cache), che è molto utile se la cache si trova in un livello di memorizzazione nella cache dedicato remoto.L'idea dietro una cache del client è che ogni client mantiene un working set della cache chiudere da (anche all'interno di processo dell'applicazione) sul computer client.Tuttavia, come una cache distribuita deve essere sincronizzate con il database in modo diverso (come illustrato precedentemente), cache di un client deve essere sincronizzato con la cache distribuita.Alcune soluzioni di memorizzazione nella cache esterna forniscono questo meccanismo di sincronizzazione, ma più forniscono solo una cache client autonomo senza alcuna sincronizzazione.

Nello stesso modo che una cache distribuita riduce il traffico al database, una cache client riduce il traffico alla cache distribuita.Non è solo più velocemente rispetto alla cache distribuita perché è più vicino all'applicazione (e può anche essere InProc), inoltre, migliora la scalabilità di cache distribuita riducendo viaggi alla cache distribuita.Naturalmente, la cache di un client è un buon approccio solo quando si eseguono molte prevalenza di letture scritture.Se il numero di letture e scritture è uguale, non utilizzare una cache client.Scritture diventerà più lente poiché è necessario aggiornare sia la cache del client e la cache distribuita.

Disponibilità elevata

Poiché una cache distribuita viene eseguito come un server nell'ambiente di produzione e in molti casi viene utilizzato come archivio dati solo per l'applicazione (ad esempio, stato sessione ASP.NET), è necessario che la cache fornire elevata disponibilità.Questo significa che la cache è necessario molto stabile in modo che non si blocca e offre la possibilità di apportare modifiche alla configurazione senza interrompere la cache.

Gli utenti la maggior parte di una cache distribuita richiedono la cache per eseguire senza eventuali interruzioni per mesi in un momento.Ogni volta che è necessario interrompere la cache, è in genere durante un orario pianificato verso il basso.È per questo motivo un'elevata disponibilità è talmente importante per una cache distribuita.Ecco alcune domande da tenere presenti quando si valuta se una soluzione di memorizzazione nella cache fornisce un'elevata disponibilità.

  • Possibile è ridurre uno dei server cache senza interrompere l'intera cache?
  • È possibile aggiungere un server cache senza interrompere la cache?
  • È possibile aggiungere nuovi client senza interrompere la cache?

Nella maggior parte delle cache, è possibile utilizzare una dimensione cache massimo specificato in modo che la cache non superi la quantità di dati.La dimensione della cache si basa sulla quantità di memoria disponibili in tale sistema.È possibile modificare tale capacità?Si supponga che si inizialmente impostare le dimensioni della cache da 1 GB ma ora si desidera renderlo 2 GB.È possibile eseguire che senza interrompere la cache?

Quelli sono i tipi di domande che si desidera prendere in considerazione.Numero di queste modifiche alla configurazione richiede effettivamente la cache per essere riavviato?Il meno migliore.Diverse funzionalità di memorizzazione nella cache, il primo criterio di disporre di una cache che può eseguire in un ambiente di produzione è quanto tempo di attività verrà consentono la cache.

Prestazioni

Semplicemente inserire, se l'accesso alla cache non è più veloce di accedere al database, non è necessario per fare in modo che.Che detto, deve desiderato in termini di prestazioni da una cache distribuita valida?

La prima cosa da ricordare è che una cache distribuita è in genere OutProc o remoto, quindi tempi di accesso non sarà più veloci di quello di una cache di InProc autonoma (ad esempio, la cache di ASP.NET).In una cache autonoma InProc, è possibile leggere probabilmente 150.000 per 200.000 elementi al secondo (dimensione oggetto 1 KB).Con un OutProc o una cache remota, questo numero Elimina in modo significativo.In termini di prestazioni, è possibile che circa 20.000 a 30.000 letture al secondo (dimensione oggetto 1 KB) come il throughput di un server di cache singoli (da tutti i client colpire su di esso).È possibile ottenere una parte di questo prestazioni InProc utilizzando una cache del client (in modalità InProc), ma che è solo per le operazioni di lettura e non per le operazioni di scrittura.Per ottenere la scalabilità rallentano le prestazioni, ma il rallentamento delle prestazioni è ancora molto più veloce di accesso al database.

Ottenere la popolarità

Una cache distribuita come un concetto e come una procedura consigliata sta per essere più popolarità.Solo alcuni anni fa, poche persone lo spazio di .NET conoscenza, anche se la comunità di Java è stato prima di .NET in quest'area.Con la crescita eccessive nelle transazioni di applicazione, i database sono sovraccarico oltre i limiti e cache distribuita è ora accettata come parte essenziale di qualsiasi architettura di applicazione scalabile.

Iqbal Khan è il presidente e tecnologia evangelist inAlachisoft. Alachisoft fornisce che NCache, .NET un leader del settore distribuiti nella cache per migliorare le prestazioni e scalabilità nelle applicazioni enterprise.Esamina dispone di una MS in informatica presso la University Indiana, Bloomington.È possibile contattarlo all'indirizzoIqbal@Alachisoft.com.