Dieser Artikel wurde maschinell übersetzt.

Microsoft Azure

Verwenden des verteilten Cache in Microsoft Azure

Iqbal Khan
Jeremiah Talkar

Microsoft Azure wird zunehmend die Wolke-Wahl für .NET Anwendungen. Neben seiner umfangreichen Satz an Cloud-Features, Azure bietet vollen Integration mit der Microsoft .NET Framework. Es ist auch eine gute Wahl für Java, PHP, Ruby und Python apps. Viele der Umzug nach Azure Anwendungen sind High-Traffic, so dass Sie vollen Unterstützung für hohe Skalierbarkeit erwarten. Verteilter in-Memory-Cache kann ein wichtiger Bestandteil einer skalierbaren Umgebung sein.

In diesem Artikel behandelt wird, verteilte Zwischenspeicherung im allgemeinen und was es kann.

Die hier beschriebenen Funktionen beziehen sich auf allgemeine verteilten Cache im Arbeitsspeicher, und nicht speziell Azure-Cache oder NCache für Azure.  Für .NET Anwendungen in Azure bereitgestellt werden hat verteilter in-Memory-Cache drei Hauptvorteile:

  1. Anwendungs-Performance und Skalierbarkeit
  2. Zwischenspeicherung ASP.NET Sitzungszustand Ansichtszustand und Seite ausgeben
  3. Runtime-Datenaustausch mit Veranstaltungen

Anwendungs-Performance und Skalierbarkeit

Azure erleichtert eine Anwendungsinfrastruktur skalieren. Beispielsweise können Sie problemlos weitere Web-Rollen, Worker-Funktionen oder virtuelle Maschinen (VMs) Wenn Sie höhere Belastung der Transaktion zu antizipieren. Trotz dieser Flexibilität kann die Datenspeicherung einen Engpass dar, der Sie halten könnte, von der Lage, Ihre app zu skalieren.

Dies ist, wo ein verteilter in-Memory-Cache kann hilfreich sein. Damit können Sie Zwischenspeichern, so viele Daten wie Sie wollen. Es kann teuer Datenbanklesevorgänge um mehr als 90 Prozent reduzieren. Dies verringert auch Transaktions Druck auf die Datenbank. Es werden schneller durchführen und auf eine größere Transaktion Last nehmen können.

Im Gegensatz zu einer relationalen Datenbank skaliert ein verteilter in-Memory-Cache in einer linearen Weise. Es wird nicht im Allgemeinen einen Engpass Skalierbarkeit geworden, obwohl 90 Prozent des gelesenen Verkehrs auf dem Zwischenspeicher der Datenbank beziehen könnte. Alle Daten im Cache wird an mehrere Cache-Server verteilt. Sie können problemlos weitere Cache-Server mit zunehmender Ihre Transaktion zu laden. Abbildung 1 zeigt, wie man apps auf den Cache.

Abbildung 1 mit im Speicher verteilten Cache in .NET Anwendungen

// Check the cache before going to the database
  Customer Load(string customerId)
{
// The key for will be like Customer:PK:1000
  string key = "Customers:CustomerID:" + customerId;
  Customer cust = (Customer)Cache[key];
  if (cust == null)
{
// Item not found in the cache; therefore, load from database
  LoadCustomerFromDb(cust);
// Now, add this object to the cache for future reference
  Cache.Insert(key, cust, null,
  Cache.NoAbsoluteExpiration,
  Cache.NoSlidingExpiration,
  CacheItemPriority.Default, null );
}
  return cust;
}

Ein verteilter in-Memory-Cache kann schneller und besser skalierbar als eine relationale Datenbank sein. Abbildung 2 zeigt einige Performance-Daten, um Ihnen eine Idee. Wie Sie sehen können, ist die Skalierbarkeit linear. Vergleichen Sie dies mit der relationalen Datenbank oder Ihr ASP.NET -Session State-Speicher, und Sie sehen den Vorteil.

Abbildung 2-Performance-Zahlen für ein typischer verteilten Cache

Cluster-Größe Lesevorgänge pro Sekunde Schreibvorgänge pro Sekunde
Cluster mit 2 Knoten 50,000 32,000
Cluster mit 3 Knoten 72,000 48,000
Cluster mit 4 Knoten 72,000 64,000
Cluster mit 5 Knoten 120,000 80,000
Cluster mit 6 Knoten 144,000 96,000

ASP.NET Sitzungszustand, Ansichtszustand und Seitenausgabe-Zwischenspeicherung

Mit verteilten in-Memory-Cache in Azure hilft auch bei ASP.NET Sitzungszustand, ASP.NET Ansichtszustand und ASP.NET Ausgabecache. Sie müssen irgendwo ASP.NET -Sitzungszustand gespeichert. Dies kann einen großen Skalierbarkeit-Engpass werden. Sie können in Azure ASP.NET Sitzungszustand in einer SQL-Datenbank, Azure Table Storage oder eine verteilte in-Memory-Cache speichern.

Eine SQL-Datenbank ist nicht ideal zum Speichern von Sitzungsstatus. Relationale Datenbanken wurden nie wirklich für Blob-Speicher entwickelt, und ein ASP.NET -Session State-Objekt wird als Blob gespeichert. Dies kann Leistungsprobleme verursachen und eine Skalierbarkeit-Engpass.

Ebenso ist Azure Table Storage nicht ideal für Blob Storage. Es ist beabsichtigt, zum Speichern von strukturierten Entitäten. Obwohl es besser skalierbar als eine SQL-Datenbank ist, ist es immer noch nicht ideal für die Speicherung ASP.NET Session State.

Ein verteilter Cache im Arbeitsspeicher eignet sich besser zum Speichern von ASP.NET Session State in Azure. Es ist schneller und besser skalierbar als die beiden anderen Optionen. Es repliziert auch Sitzungen, so kein Datenverlust, besteht wenn ein Cacheserver ausfällt. Wenn Sie in einem separaten dedizierten Sitzungen speichern Zwischenspeichern Tier, dann Rollen Web und Web Server VMs werden statusfrei, was gut ist, denn Sie sie bezwingen können ohne Datenverlust Sitzung.

Während ausgeführt ASP.NET Sitzungsstatus im Cache eignet sich aus Sicht der Leistung, wenn der Cache ausfällt, wird Ihre gesamte app eingehen. Und, natürlich, was auch immer in Ihrer Session ist wäre auch gegangen. Der neue Redis-Cache für Azure Sitzungszustandsanbieter haben so Sie wissen können, wann diese Arten von Problemen passieren und mindestens in eine saubere Möglichkeit für den Benutzer anzuzeigen.

Abbildung 3 veranschaulicht einen verteilten in-Memory-Cache um ASP.NET Sitzungszustand gespeichert zu konfigurieren.

Abbildung 3 konfigurieren ASP.NET Sitzungszustandsspeicher in ein verteilter Cache

// Check the Cache before going to the database
  Customer Load(string customerId)
{
// The key for will be like Customer:PK:1000
  string key = "Customers:CustomerID:" + customerId;
  Customer cust = (Customer)Cache[key];
  if (cust == null)
{
// Item not found in the cach; therefore, load from database
  LoadCustomerFromDb(cust);
// Now, add this object to the cache for future reference
  Cache.Insert(key, cust, null,
  Cache.NoAbsoluteExpiration,
  Cache.NoSlidingExpiration,
  CacheItemPriority.Default, null );
}
  return cust;
}

Obwohl das ASP.NET -MVC-Framework die Notwendigkeit der Verwendung des Ansichtszustands ASP.NET entfernt hat, noch nicht die Mehrheit der ASP.NET Anwendungen noch in das MVC-Framework ASP.NET verschoben. Daher benötigen sie noch ASP.NET View State.

ASP.NET View State können große Bandbreite belasten und dazu führen, dass einen merklicher Abfall in Ihre ASP.NET Anwendung Antwortzeiten. Das ist da ASP.NET Ansichtszustand Hunderte von Kilobyte für jeden Benutzer sein können. Es ist unnötig, und aus dem Browser bei Post zurück gesendet. Wenn diese ASP.NET View State auf dem Web-Server-End zwischengespeichert und eine eindeutige ID an den Browser gesendet wird, kann es verbessern Reaktionszeiten und auch den Bandbreiten-Verbrauch verringern.

In Azure, wo die ASP.NET Anwendung in mehreren Webrollen oder VMs ausgeführt wird, ist der am wenigsten störende Ort diese ASP.NET -Ansichtszustand Zwischenspeichern in eine verteilte in-Memory-Cache. Auf diese Weise können Sie es von einem beliebigen Webserver erhalten. Hier ist, wie Sie den ASP.NET -Ansichtszustand für die Lagerung in einer verteilten in-Memory-Cache konfigurieren können:

<!-- /App_Browsers/Default.browser -->
<browsers>
  <browser refID="Default" >
    <controlAdapters>
      <adapter
      controlType="System.Web.UI.Page"
      adapterType="DistCache.Adapters.PageAdapter"/>       
    </controlAdapters>
  </browser>
</browsers>

ASP.NET bietet auch ein Output Cache-System, mit dem Sie Zwischenspeichern der Seitenausgabe, das nicht ändern dürfte. So musst du die Seite das nächste Mal ausführen. Das spart CPU-Ressourcen und ASP.NET Reaktionszeit beschleunigt. In einer Multi-Server-Bereitstellung ist der beste Ort Ausgabe der Cache-Seite in ein verteilter Cache, so dass er von allen Web-Servern zugänglich sein wird. Glücklicherweise hat ASP.NET Ausgabecache eine Provider-basierten Architektur, so dass Sie leicht in eine verteilte in-Memory-Cache anschließen können (siehe Abbildung 4).

Abbildung 4 konfigurieren ASP.NET Ausgabecache für verteilte In-Memory-Cache

<!-- web.config -->
<system.web>
  <caching>
    <outputCache defaultProvider="DistributedCache">
      <providers>
        <add name="DistributedCache"
          type="Vendor.Web.DistributedCache.DistCacheOutputCacheProvider,
            Vendor.Web.DistributedCache"
          cacheName="default"
          dataCacheClientName="default"/>
      </providers>
    </outputCache>
  </caching>
</system.web>

Runtime-Datennutzung durch Ereignisse

Ein weiterer Grund zu prüfen, mit verteilten in-Memory-Cache in Azure ist Runtime Datenfreigabe. Anwendungen führen in der Regel Runtime Datenfreigabe auf folgende Weise:

  1. Polling-relationale Datenbanken zur Erkennung von Datenänderungen
  2. Mithilfe von Datenbankereignissen (z. B. SqlDependency oder OracleDepedency)
  3. Nachrichtenwarteschlangen wie MSMQ verwenden

Alle diese Ansätze bieten Grundfunktionen, aber jeder hat bestimmte Themen Performance und Skalierbarkeit. Polling ist in der Regel eine schlechte Idee. Dies beinhaltet viele unnötige Datenbank gelesen. Datenbanken sind bereits ein Engpass Skalierbarkeit auch ohne zusätzliche Datenbankereignisse. Mit dem zusätzlichen Aufwand für Datenbankereignisse, Datenbanken werden noch schneller unter schweren Transaktion Belastung ersticken.

Nachrichtenwarteschlangen sind spezialisiert auf sequenzierte Datenaustausch und anhaltende Ereignisse dauerhafte Speicherung. Sie sind gut für Situationen, in denen die Empfänger nicht empfingen Ereignisse für eine lange Zeit oder bei Anwendungen im WAN verteilt sind. Jedoch wenn es darum geht, eine transaktionsintensiven Umgebung, Nachrichtenwarteschlangen möglicherweise nicht ausführen oder Skalieren wie ein verteilter Cache im Arbeitsspeicher.

So haben Sie eine transaktionsintensiven Umgebung wo mehrere Anwendungen müssen Daten zur Laufzeit ohne jede Sequenzierung zu teilen und Sie brauchen nicht zu Veranstaltungen für eine lange Zeit beibehalten, sollten Sie erwägen, einen verteilten in-Memory-Cache für die gemeinsame Nutzung zur Laufzeit Daten. Ein verteilter in-Memory-Cache können Sie Daten zur Laufzeit in eine Vielzahl von Möglichkeiten, gemeinsam alle asynchronen sind:

  1. Item level Ereignisse auf Update und entfernen
  2. Cache- und Gruppenebene/Region-Veranstaltungen
  3. Kontinuierliche abfragebasierte Veranstaltungen
  4. Thema-basierte Ereignisse (für Veröffentlichungen/Abonnements Modell)

Die ersten drei Möglichkeiten sind im wesentlichen unterschiedlich, Datenänderungen im Cache zu überwachen. Die Anwendung wird für jede dieser Rückrufe registriert. Verteilte Cache ist verantwortlich für "feuern das Ereignis" ändert sich immer dann, wenn die entsprechenden Daten in den Cache. Daraus ergibt sich Ihre Anwendungsrückruf-aufgerufen wird.

Wenn ein bestimmtes zwischengespeichertes Element aktualisiert oder entfernt wird, gibt es ein Elementebene-Ereignis ausgelöst. Gruppe/Region auf und Cache - Ereignisse werden ausgelöst, wenn Daten in diesen "Container" hinzugefügt, aktualisiert oder entfernt werden. Kontinuierliche Abfrage besteht aus Suchkriterien definieren eines Datasets in verteilten Cache. Verteilte Cache löst Ereignisse, wenn Sie hinzufügen, aktualisieren oder Entfernen von Daten aus diesem Dataset aus. Dies können Sie Cache Änderungen überwacht werden:

string queryString = "SELECT Customers WHERE this.City = ?";
Hashtable values = new Hashtable();
values.Add("City", "New York");
Cache cache = CacheManager.GetCache(cacheName);
ContinuousQuery cQuery = new ContinuousQuery(queryString, values);
cQuery.RegisterAddNotification(
  new CQItemAddedCallback(cqItemAdded));
cQuery.RegisterUpdateNotification(
  new CQItemUpdatedCallback(cqItemUpdated));
cQuery.RegisterRemoveNotification(
  new CQItemRemovedCallback(cqItemRemoved));
cache.RegisterCQ(query);

Thema-basierte Ereignisse sind Allzweck und sind nicht gebunden an Datenänderungen im Cache. In diesem Fall eine Cache-Kunde ist verantwortlich für "Feuern der Veranstaltung." Verteilte Cache wird so etwas wie ein Nachrichten-Bus und transportiert dieses Ereignis für alle anderen Clients in den Cache.

Mit Thema-basierte Ereignisse können Ihre Anwendungen Daten in einem Modell Publish/subscribe-teilen, wo eine Anwendung Daten veröffentlicht und ein Thema-basierten-Ereignis auslöst. Andere Anwendungen für dieses Ereignis warten und starten diese Daten verbraucht, nachdem es empfangen wurde.

Verteilten Cache-Architektur

Hochfrequentierten apps können Ausfallzeiten nicht leisten. Für diese Anwendungen in Azure ausgeführt gibt es drei wichtige Aspekte der verteilten in-Memory-Cache:

  1. Hohe Verfügbarkeit
  2. Lineare Skalierbarkeit
  3. Datenreplikation und Zuverlässigkeit

Cache-Elastizität ist ein wesentlicher Aspekt der Erhaltung Ihrer verteilten in-Memory-Caches. Viele verteilte in-Memory-Caches erreichen, Elastizität und hohe Verfügbarkeit durch Folgendes:

Selbstheilende Peer-to-Peer-Cache-Cluster: Alle Cache-Server bilden einen Cache-Cluster. Ein Selbstheilung Peer-to-Peer-Cluster passt sich an, wenn Knoten hinzugefügt oder entfernt werden. Mächtiger Caches Form eine selbstheilende Peer-to-Peer-Cache Cluster, während andere Master/Slave Cluster bilden. Peer-to-Peer ist dynamisch und können Sie hinzufügen oder Entfernen von Cacheservern ohne Beenden des Caches. Master/Slave-Cluster sind begrenzt, da eine oder mehrere der benannten Knoten runter behindert Operationen Zwischenspeichern. Einige caches wie Memcached nicht Form Cache-Cluster und daher nicht elastischen angesehen.

Verbindung Failover: Die Cache-Kunden sind apps, die auf Applikations-Server und Webserver, die dann die Cacheserver zugreifen. Verbindung Failover-Funktionalität ist innerhalb der Cacheclients. Das bedeutet, wenn Cache-Server im Cluster ausfällt, der Cache-Client weiterhin funktionsfähig sind von anderen Servern im Cluster zu finden.

Dynamische Konfiguration: beide cache-Servern und -Clients zwischengespeichert haben diese Fähigkeit. Anstatt die Cacheclients mit hartcodieren Konfigurationsdetails, propagieren Cache-Server diese Informationen an die Cacheclients zur Laufzeit, einschließlich aller Änderungen.

Zwischenspeicherung Topologien

In vielen Fällen sind Sie Zwischenspeichern von Daten, die in der Datenbank, z. B. ASP.NET Sitzungszustand nicht vorhanden ist. Daher kann Daten verloren gehen sehr schmerzhaft sein. Sogar wo Daten in der Datenbank vorhanden sind, kann eine Menge davon zu verlieren, wenn ein Cache-Knoten ausfällt stark app Leistung auswirken.

Daher ist es besser, wenn Ihre verteilte in-Memory-Cache Ihrer Daten repliziert. Replikation muss jedoch Leistung und Lagerkosten. Ein guter in-Memory-Cache bietet eine Reihe von Zwischenspeicherung Topologien um verschiedene Anforderungen an Speicher und Replikation von Daten zu behandeln:

Gespiegelte Cache: Diese Topologie ist eine aktive und eine passive Cache-Server. Alle Lese- und Schreibvorgänge sind gegen den aktiven Knoten aus, und Updates werden asynchron zum Spiegel angewendet. Diese Topologie wird normalerweise verwendet, wenn Sie nur einen dedizierten Cacheserver Ersatzteile und einen app/Web-Server als den Spiegel teilen können.

Replizierter Cache: Diese Topologie weist zwei oder mehr aktiven Cache-Servern. Der gesamte Cache wird auf alle repliziert. Alle Updates sind synchron — sie sind auf alle Cache-Server als einen Vorgang angewendet. Lesen Sie Transaktionen Skala linear, da Sie weitere Server hinzufügen. Der Nachteil ist, dass Speicher zu erhöhen oder Transaktion Kapazität aktualisieren nicht mehr Knoten hinzufügen.

Partitionierter Cache: Diese Topologie weist den gesamten Cache partitioniert, wobei jeder Cacheserver, die eine Partition enthält. Cacheclients verbinden sich in der Regel auf alle Cacheserver, damit sie Daten in der gewünschten Partition direkt zugreifen können. Ihre Lagerung und Transaktion Kapazität wächst, wenn Sie weitere Server hinzufügen, so gibt es linearer Skalierbarkeit. Es gibt keine Replikation, obwohl, so dass Sie Daten verlieren könnte, wenn ein Cacheserver ausfällt.

Partitioniert replizierten Cache: Das ist wie ein Cache partitioniert, außer jede Partition auf mindestens einem anderen Cacheserver repliziert werden. Sie verlieren nicht keine Daten, wenn ein Cacheserver ausfällt. Die Partition ist in der Regel aktiv und das Replikat ist passiv. Ihre Anwendung nie interagiert direkt mit dem Replikat. Diese Topologie bietet die Vorteile eines Caches partitioniert wie lineare Skalierbarkeit und Zuverlässigkeit der Daten. Es gibt eine geringfügig bessere Leistung und Speicherkosten, die bei der Replikation.

Client-Cache (nahe Cache): Cacheclients laufen in der Regel unter app/Web-Server, also den Zugriff auf den Cache in der Regel Netzwerkverkehr beinhaltet. Client-Cache (auch in der Nähe von Cache genannt) ist ein lokaler Cache hält häufig verwendete Daten in der Nähe Ihrer Anwendung und spart Netzwerk Reisen. Diese lokale Cache ist auch verbunden und synchronisiert mit dem verteilten Cache. Client-Cache kann InProc (d. h. innerhalb der Bearbeitung Ihrer Bewerbung) oder OutProc.

Bereitstellen verteilten Cache in Azure

In Azure haben Sie mehrere verteilter Cache-Optionen, einschließlich Microsoft Azure Caches, NCache für Azure und Memcached. Jeder Cache bietet einen anderen Satz von Optionen. Dies sind die häufigsten Bereitstellungsoptionen für eine einzige Region:

  1. Rolle Cache (zusammen oder gewidmet)
  2. Cache-Service
  3. Cache-VMs (dediziert)
  4. Cache-VMs WAN (mehrere Regionen)

In der Rolle Cache können Sie einen Cache Rolle auf eine co-located oder spezielle Rolle in Azure bereitstellen. Co-located bedeutet Ihre Anwendung auch auf die VM ausgeführt wird und gewidmet, dass es nur den Cache ausgeführt wird. Obwohl ein guter verteilter Cache Elastizität und hohe Verfügbarkeit bietet, gibt es Aufwand hinzufügen oder Entfernen von Cacheservern aus dem Cache-Cluster zugeordnet. Ihre Präferenz sollte einen stabilen Cache-Cluster haben. Sie sollten hinzufügen oder Entfernen von Cache-Server, nur, wenn Sie möchten, zu skalieren oder zu reduzieren, Ihre Cache-Kapazität oder wenn Sie einen Cacheserver down.

Der-Rolle-Cache ist volatiler als andere Bereitstellungsoptionen, weil Azure einfach starten und stoppen von Rollen. In einer co-located Rolle teilt der Cache auch CPU- und Speicherressourcen mit Ihren Anwendungen. Für ein oder zwei Fällen ist es OK, um diese Bereitstellungsoption verwenden. Es eignet sich nicht für größere Bereitstellungen, aber aufgrund der Auswirkungen auf negativ auf die Leistung.

Sie können auch erwägen einen dedizierten in Rolle-Cache. Denken Sie daran, diesen Cache als Teil Ihrer Cloud-Service bereitgestellt wird, und ist nur innerhalb dieses Dienstes sichtbar. Dieser Cache können nicht über mehrere Anwendungen freigegeben werden. Der Cache läuft auch, nur so lange, wie der Dienst ausgeführt wird. Also, wenn Sie haben den Cache, auch wenn Sie die Anwendung beenden möchten, verwenden Sie diese Option.

Microsoft Azure Cache und NCache für Azure beide bieten die Möglichkeit, in Rolle-Bereitstellung. Sie können Memcached diese Konfiguration führen Sie mit einige Optimierungen, aber Sie Daten verlieren, wenn eine Rolle da Memcached Daten replizieren nicht wiederverwendet wird.

Cache-Service im Cache Dienst, verteilte Cache unabhängig von Ihrem Dienst bereitgestellt wird, und bietet Ihnen eine Cache-Level-Ansicht. Sie weisen eine gewisse Menge Speicher und CPU-Kapazität und erstellen Ihren Cache. Der Vorteil eines Cache-Dienstes ist seine Einfachheit. Sie nicht installieren und Konfigurieren eines verteilten Cache-Software selbst. Infolgedessen ist Ihr Cache-Management-Aufwand reduziert, da Azure verteilten Cache-Cluster für Sie verwaltet wird. Ein weiterer Vorteil ist, dass Sie diesen Cache in mehreren Anwendungen gemeinsam nutzen können.

Der Nachteil eines Cache-Service ist Ihre eingeschränkten Zugriff. Nicht steuern oder den Cache VMs innerhalb des Clusters zu manipulieren, so wie Sie in einem lokalen verteilt-Cache. Auch können Sie keinem serverseitigen Code wie Read-Through, Write-through, Cache Loader usw. bereitstellen. Sie können die Anzahl der VMs im Cluster nicht kontrollieren, da es von Azure behandelt werden. Sie können nur unter den Optionen für die Bereitstellung von Basic, Standard und Premium. Microsoft Azure Cache bietet eine Cache-Service Deployment-Option, während NCache für Azure nicht.

Zwischenspeichern von VMs können Sie auch Ihre verteilten Cache in Azure bereitstellen. Dies gibt Ihnen volle Kontrolle über Ihre verteilten Cache. Wenn Sie Ihre Anwendung auf Web Worker-Funktionen, Rollen oder dedizierte VMs bereitstellen, können Sie auch der Clientteil von verteilten Cache (Bibliotheken) bereitstellen. Sie können auch den Cache-Client über Windows Installer installieren, wenn Sie Ihre Rolle erstellen. Dies gibt Ihnen weitere Installationsoptionen wie OutProc-Client-Cache (in der Nähe von Cache).

Dann können Sie separaten dedizierten VMs wie Ihre Cacheserver zuordnen, Ihre verteilter Cache-Software installieren und Ihre Cache-Cluster auf Basis Ihrer Anforderungen zu bauen. Diese speziellen Cache-VMs sind stabil und weiterlaufen, auch wenn die Anwendung beendet. Deine Cache-Client-Gespräche zum Cache cluster über ein TCP-Protokoll. Für einen Cache-VM gibt es zwei Bereitstellungsszenarien, die Sie verwenden können:

  1. Innerhalb des virtuellen Netzwerks bereitstellen: Ihre Anwendung Rollen/VMs und die Cache-VMs befinden sich in demselben virtuellen Netzwerk. Es gibt keine Endpunkte zwischen der Anwendung und verteilten Cache. Infolgedessen ist Zugriff auf schnell. Der Cache ist auch von der Außenwelt völlig verborgen und daher sicherer.
  2. In separaten virtuellen Netzwerken bereitstellen: Ihre Anwendung Rollen/VMs und die Cache-VMs sind in verschiedenen virtuellen Netzwerken. Verteilte Cache ist in ein eigenes virtuelles Netzwerk und über Endpunkte verfügbar gemacht werden. Infolgedessen können Sie den Cache über mehrere Anwendungen und mehrere Regionen teilen. Jedoch haben Sie viel mehr Kontrolle über Ihre Cache-VMs als ein Cache-Service.

In beide Cache VM-Deployment-Optionen haben Sie vollen Zugriff auf alle Cache-Server. Dadurch können Sie die Bereitstellung von Server-seitigen Code z. B. Read-Through, Write-through und Cache Loader, genau so wie in einer on-premise-Bereitstellung. Sie haben auch mehr Überwachungsinformationen, weil Sie vollen Zugriff auf den Cache VM verfügen. Microsoft Azure Cache nicht die Option Cache VM zur Verfügung, während es in NCache für Azure und Memcached verfügbar sind.

Microsoft plant, seinen verwalteten Cache im allgemeinen Verfügbarkeit im Juli zu haben, die die bestehende ersetzen wird geteilt-Diensts. Es wird höchstwahrscheinlich keine Azure Portal Präsenz und erfordert eine Windows PowerShell -Befehlszeile zum Erstellen und verwalten.

NCache für Azure auf dedizierten virtuellen Computer installieren können und von Ihrem Web und Worker-Funktionen zugreifen. Sie können auch NCache für Azure Web und Worker-Funktionen installieren, aber das ist keine empfohlene Strategie. NCache für Azure kommen nicht als Cache Service. Microsoft Azure bietet auch Redis Cache Service, das über das Management Portal erhältlich ist.

Cache-VMs über WAN Wenn Sie einen Cloud-Service, die in mehreren Regionen bereitgestellt wird haben, sollten Sie Ihre Cache-VMs im WAN bereitstellen. Die Cache-VM-Bereitstellung in jeder Region ist dasselbe wie die vorherige Option. Jedoch haben Sie eine Situation mit zwei zusätzliche Anforderungen:

  1. Multisite- ASP.NET -Sitzungen: Sie können eine ASP.NET -Sitzung von einem Standort zum anderen übertragen, wenn ein Benutzer umgeleitet wird. Dies ist eine häufige Erscheinung für Anwendungen, die in mehrere aktive Standorte bereitgestellt. Sie können umleiten Verkehr um Überläufe zu behandeln oder weil sie einer Website nach unten bringen.
  2. WAN-Replikation des Caches: Sie können alle Cache-Updates von einem Standort zum anderen replizieren. Dies ist eine aktiv / passiv oder aktiv / aktiv-Multisite-Bereitstellung. In aktiv / passiv werden Aktualisierungen in eine Richtung repliziert. Sie sind in aktive bidirektional. Der Cache ist standortübergreifend durch WAN-Replikation synchronisierte gehalten, aber halten Sie im Verstand es verbraucht Bandbreite.

Wichtige Funktionen zum Zwischenspeichern

Wenn Sie einen verteilten in-Memory-Cache verwenden, wird es eine große Datenmenge verarbeiten. Ein grundlegender verteilter in-Memory-Cache bietet nur eine Hashtable (Schlüssel, Wert)-Schnittstelle. Ein verteilter Cache auf Unternehmensebene vorsehen sowie die folgenden Features:

Suchen von Funktionen: statt immer Daten anhand eines Schlüssels zu finden, ist es viel einfacher, Caches basierend auf einige andere logischen Daten suchen. Zum Beispiel können viele verteilte Caches Sie Gruppen und Tags zu verwenden, um zwischengespeicherte Elemente logisch gruppieren. Viele können auch Caches durch LINQ, zu suchen, der für Objekt suchen in .NET Framework beliebt ist. Einige bieten auch eigene Object Query Language (OQL), eine SQL-ähnliche Abfragesprache, mit denen Sie suchen, können, des Caches. Die Fähigkeit, einen verteilten Cache basierend auf andere Attribute als Schlüssel zu suchen macht das verteilter Cache Look And Feel wie eine relationale Datenbank. Abbildung 5 zeigt, wie eine solche Suche ausgeführt werden könnte.

Abbildung 5 konfigurieren eine LINQ -Suche eines verteilten Caches

public IList<Customer> GetCutomers(string city)
{
  // Use LINQ to search distributed cache
  IQueryable<Customer> customers = 
    new DistCacheQuery<Customer>(cache);
  try {
    var result = from customer in customers
      where customer.City = city
      select customer;
    IList<Customer> prods = new List<Customer>();
    foreach (Customer cust in result) {
      customers.Add(cust);
    }
  }
  return customers;
}

Read-Through und Write-durch/Write-Behind: Read-Through und Write-through-Handler vereinfachen den Anwendungscode, da Sie ein großes Stück des Codes persistent in den Cache-Cluster verschoben haben. Ihre Anwendung geht einfach der Cache im Datenspeicher. Dies ist eine weitere Möglichkeit der Wiederverwendung von Code über mehrere Anwendungen hinweg.

Der Cache ruft Read-Through, wenn die Anwendung versucht, etwas zu holen, der nicht im Cache ist (Dies wird als "verfehlen" genannt). Wenn eine Miss geschieht, der Cache den Read-through-Handler aufruft und es holt sich die Daten aus Ihrer Datenbank (siehe Abbildung 6). Verteilte Cache setzt es im Cache und gibt sie an die Anwendung zurück.

Abbildung 6-Read-through-Handler für ein verteilter Cache

public class SqlReadThruProvider : IReadhThruProvider
{
  // Called upon startup to initialize connection
  public void Start(IDictionary parameters) { ... }
  // Called at the end to close connection
  public void Stop() { ... }
  // 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);
      // 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;
  }
}

Cache ruft auch den Write-through-Handler, wenn Sie den Cache zu aktualisieren und will, dass es automatisch die Datenbank zu aktualisieren. Der Write-through-Handler läuft auf eine oder mehrere Cache-Server im Cluster und Gespräche zu Ihrer Datenbank. Wenn die Write-through asynchron nach einer Verzögerung und nicht als Teil der Cache-Update-Transaktion aufgerufen wird, wird dieser Vorgang jedoch schreiben nach aufgerufen. Write-Behind verbessert die Anwendungs-Performance, da du musst nicht warten, bis die Datenbankaktualisierung abgeschlossen sein.

Synchronisieren Sie Cache mit relationalen Datenbank: Die meisten Daten in ein verteilter Cache stammen aus der Anwendungsdatenbank. Das heißt, es gibt jetzt zwei Kopien der Daten, die master-Kopie in der Datenbank und in verteilten Cache. Wenn Sie Anwendungen, die direkt aktualisieren von Daten in der Datenbank haben, aber keinen Zugriff auf Ihre verteilten in-Memory-Cache, Sie am Ende mit veralteten Daten im Cache.

Einige verteilten Caches bieten Datenbank-Synchronisation, um den Cache zu gewährleisten hat nie veraltete Daten. Diese Synchronisation ist entweder ereignisgesteuert (Datenbank-Benachrichtigungen z. B. SqlDependency verwenden) oder Polling-basierten. Ereignisgesteuerte Echtzeit näher ist, aber mehr Aufwand denn es eine separate SqlDependency im Datenbank-Server für schafft jede zwischengespeichert hat Element. Polling ist effizienter, da eine Datenbankaufruf Tausende von Elemente synchronisiert werden kann. Aber es in der Regel eine Verzögerung bei der Synchronisierung gibt zur Vermeidung von Überschwemmungen der Datenbank mit unnötigen Polling aufrufen. Also ist die Wahl zwischen näher an Echtzeit-Datenbank-Synchronisation oder eine effizientere Polling-basierten Synchronisation mit einer leichten Verzögerung.

Umgang mit relationale Daten in ein verteilter Cache: Ein verteilter in-Memory-Cache ist ein Schlüssel-Wert-Objektspeicher, aber die meisten Daten im Cache kommt aus einer relationalen Datenbank. Diese Daten hat eins-zu-viele-, 1: 1 und m: n-Beziehungen. Relationale Datenbanken stellen Einschränkungen der referenziellen Integrität und kaskadierte Aktualisierungen und Löschungen um diese Beziehungen zu erzwingen. Der Cache braucht etwas Ähnliches auch.

CacheDependency können Sie ein zwischengespeichertes Element abhängig von anderen zu haben. Wenn andere das zwischengespeicherte Element aktualisiert oder gelöscht wird, wird das ursprüngliche zwischengespeicherte Element automatisch gelöscht. Dies funktioniert wie eine Löschweitergabe. Es ist nützlich für die Behandlung: 1- und 1: n-Beziehungen zwischen Objekten im Cache. Einige verteilten in-Memory-Caches haben dieses Feature auch implementiert. Abbildung 7 zeigt, wie Sie CacheDependency konfigurieren würde.

Abbildung 7 Verwendung CacheDependency Beziehungen im Cache verwalten

public void CacheCustomerAndOrder(Customer cust, Order order)
{
  Cache cache = httpsRuntime.Cache;
  // Customer has one-to-many with Order. Cache customer first
  // then cache Order and create CacheDependency on customer
  string custKey = "Customer:CustomerId:" + cust.CustomerId;
  cache.Add(custKey, cust, null,
    Cache.NoAbsoluteExpiration,
    Cache.NoSlidingExpiration,
    CacheItemPriority.Default, null);
  // CacheDependency ensures order is removed if Cust updated or removed
  string[] keys = new string[1];
  keys[0] = custKey;
  CacheDependency dep = new CacheDependency(null, keys);
  string orderKey = "Order:CustomerId:" + order.CustomerId
    + ":ProductId:" + order.ProductId;
  // This will cache Order object with CacheDependency on customer
  cache.Add(orderKey, order, dep,
    absolutionExpiration,
    slidingExpiration,
    priority, null);
}

Zusammenfassung

Microsoft Azure ist eine leistungsfähige Cloud-Plattform und eine skalierbare Umgebung. Ein verteilter in-Memory-Cache kann ein wichtiger Bestandteil dieser Umgebung sein. Wenn Sie Ihre Anwendung in der .NET Framework geschrieben haben, dann sollten Sie mit einem .NET Cache verteilt. Wenn sie in Javaist, haben Sie verschiedene Java-basierte verteilte Cache-Lösungen. Haben Sie eine Kombination von .NET und Java -Anwendungen, verwenden Sie einen verteilten Cache unterstützt und bietet Datenportabilität. Die meisten Caches sind ganz konzentriert auf .NET oder Java, auch wenn einige beide unterstützen.

Für PHP, Ruby, Python und andere Anwendungen können Sie Memcached. Diese Umgebungen unterstützt. Memcached ist ein elastischer Cache nicht und hat daher hohe Verfügbarkeit und Daten -­Zuverlässigkeit Einschränkungen. So oder so, denken Sie daran, dass ein verteilter Cache ein sensibler Teil der Produktionsumgebung ist. Daher müssen Sie alle verfügbare Cache-Lösungen in Ihrer Umgebung gründlich zu bewerten und wählen Sie eine, die Ihren Bedürfnissen entspricht.


Iqbal Khan* ist der Technologieexperte für Alachisoft, wonach Ncache verteilten Cache für .NET und Microsoft Azure.  Er ist zu erreichen unter iqbal@alachisoft.com.*

Jeremiah Talkar* ist ein Microsoft Azure-Tech-Evangelist innerhalb im Microsoft Developer Platform Evangelism Corporate-Team mit 26 Jahren Erfahrung in der Produkt engineering, Beratung und Verkauf. Sie erreichen ihn am jtalkar@microsoft.com.*

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Scott Hunter, Masashi Narumoto und Trent Swanson