Codecamp Südflorida 2017
Skalierung von .NET-Anwendungen mit verteiltem Caching
Von Iqbal Khan
Präsident & Technologie-Evangelist
Bei Ihren .NET-Anwendungen können aufgrund der zunehmenden Transaktionslast Datenbank- oder Speicherengpässe auftreten. Erfahren Sie, wie Sie Engpässe beseitigen und Ihre .NET-Anwendungen mithilfe von verteiltem Caching skalieren. Dieser Vortrag umfasst:
- Schneller Überblick über Skalierbarkeitsengpässe in .NET-Anwendungen
- Beschreibung des verteilten Caching und wie es Leistungsprobleme löst
- Wo können Sie verteiltes Caching in Ihren Anwendungen verwenden?
- Einige wichtige Funktionen in einem verteilten Cache
- Praktische Beispiele mit einem verteilten Cache
Heute werde ich darüber sprechen, wie Sie .NET-Apps mit verteiltem Caching skalieren können. In diesem Gespräch geht es nicht darum NCache. Obwohl ich mich darauf beziehen werde NCache Der Hauptzweck besteht jedoch darin, Sie über die Probleme aufzuklären und wie Sie sie mit Caching lösen können.
Was ist Skalierbarkeit?
Okay! Lassen Sie uns der Vollständigkeit halber einige der Definitionen durchgehen, die Sie sicher bereits kennen, aber zunächst definieren wir, was Skalierbarkeit ist. Skalierbarkeit ist keine hohe Leistung. Hohe Leistung wäre etwas, wenn Sie fünf Benutzer hätten, Sie hätten eine wirklich gute Reaktionszeit, das ist eine hohe Leistung. Skalierbarkeit bedeutet, dass Sie auch bei Spitzenlasten die gleiche hohe Leistung aufrechterhalten können. Wenn Ihre Anwendung also mit fünf Benutzern keine hohe Leistung erbringt, liegen andere Probleme vor. Mehr als wir dort lösen können.
Lineare Skalierbarkeit
Zweitens, was ist lineare Skalierbarkeit? Lineare Skalierbarkeit ist eher eine Bereitstellungsdefinition.
Wenn Sie Ihre Anwendung in einer Umgebung mit mehreren Servern bereitstellen, beispielsweise wenn Sie über eine Umgebung mit Lastausgleich verfügen, ist Ihre Anwendung linear skalierbar, wenn Sie einfach weitere Server hinzufügen können, um zusätzliche Transaktionskapazität zu erhalten. Wenn Sie also tausend Benutzer mit zwei Servern hätten, hätten Sie einen dritten Server, sagen wir, 1500 Benutzer, und wenn Sie dann weitere Server hinzufügen, erhalten Sie jeweils 500 Benutzer. Ich sage nur hypothetisch, aber das ist eine lineare Skalierbarkeit. Wenn Sie das erreichen können, dann ist das das Ziel, denn dann werden Sie nie auf Probleme stoßen, für deren Lösung Sie sicher hier waren.
Nichtlineare Skalierbarkeit
Nichtlineare Skalierbarkeit ist genau das Gegenteil davon, dass Sie über eine Anwendungsarchitektur verfügen, bei der Sie einfach keine teurere Hardware oder mehr Server kaufen können, um dieses Problem zu lösen.
Es gibt einige grundlegende Engpässe: Wenn Sie für eine bestimmte Zeit weitere Server oder Ihre Anwendung hinzufügen, steigt die Leistung oder die Transaktionskapazität, danach wird sie jedoch tatsächlich langsamer, selbst wenn Sie weitere Server hinzufügen. Sie möchten also definitiv keine nichtlineare Skalierbarkeit.
Welche Art von Anwendungen benötigen Skalierbarkeit?
Dabei handelt es sich in der Regel um serverseitige Anwendungen.
Dies sind Webanwendungen, ASP.NET, dies könnten Webdienste WCF sein, dies könnte das Backend für beliebige IOT-Anwendungen sein. Wir haben viele verschiedene IoT-Geräte, die mit einer Art Back-End kommunizieren. Dabei kann es sich um Big-Data-Verarbeitungsanwendungen handeln, obwohl die Big-Data-Verarbeitung eher eine Java-Aktivität ist. Aufgrund von Hadoop ist .NET keine sehr große Big-Data-Verarbeitung, aber wenn Sie Big-Data-Verarbeitung durchführen würden, müssten Sie auf jeden Fall alle anderen Serveranwendungen skalieren, die nicht in diese Kategorie passen. Ich meine, Sie haben möglicherweise viel Stapelverarbeitung, wenn Sie ein großes Unternehmen sind, müssen Sie möglicherweise eine bestimmte Anzahl von Dingen bis Mitternacht oder vor dem nächsten Werktag aktualisieren, und da Sie immer mehr Kunden haben Wenn Sie Millionen und Abermillionen von Kunden haben, müssen Sie das natürlich skalieren.
Ein gutes Beispiel könnte also sein, dass Kunden, Ihre Bank und die Kunden Geld von einem Konto auf ein anderes überweisen, was normalerweise nachts im Backend im Batch-Modus verarbeitet wird. Sie müssen dies also vertraglich innerhalb einer bestimmten Frist erledigen. Wenn also alle diese Anwendungen nicht skalierbar sind, treten große Probleme auf.
Was ist das Skalierbarkeitsproblem?
Glücklicherweise liegt das Problem nicht auf der Anwendungsebene. Wenn Sie über die meisten dieser Anwendungen verfügen, ist es kein großes Problem, der Anwendungsebene weitere Server hinzuzufügen. Das Problem liegt in der Datenspeicherung. Und wenn ich das Wort Datenspeicherung verwende, meine ich relationale Datenbanken, Mainframe-Altdaten. Dort befinden sich die meisten Ihrer Daten, und diese können nicht auf die gleiche Weise skaliert werden wie die Anwendungen. Jetzt, NoSQL databaseFür einen der Anwendungsfälle gibt es Skalierungen, aber das Problem besteht darin NoSQL databases, und wieder haben wir ein NoSQL database von uns selbst genannt NosDB. Es handelt sich um eine Open-Source-Datenbank. Also die Einschränkung von NoSQL database ist, dass Sie einfach nicht alle Daten dorthin verschieben können, weil Sie dazu Daten von Ihrem Mainframe oder Ihren relationalen Datenbanken wegbewegen müssen, was Ihnen aus verschiedenen Gründen, vielleicht technischen, vielleicht geschäftlichen, möglicherweise nicht möglich ist.
Die relationalen Datenbanken werden also weiterhin Ihre wichtigste Stammdatenquelle sein. Es gibt viele Anwendungsfälle, in denen Sie viele neue Daten eingeben können NoSQL databases und wenn Sie dies tun, wird der Skalierbarkeitsengpass behoben. In den meisten Fällen können Sie dies jedoch nur für einen Teil Ihrer Daten tun. Der Großteil der Daten muss weiterhin in Ihren relationalen Datenbanken oder in Ihren alten Mainframe-Datenquellen verbleiben. Welches Problem Sie auch lösen müssen, diese Skalierbarkeit, Sie müssen es lösen, während Sie weiterhin mit relationalen Datenbanken oder Ihrem alten Mainframe arbeiten. Und hier löst ein verteilter Cache dieses Problem tatsächlich. Es ermöglicht Ihnen, die Mainframe-Daten Ihrer relationalen Datenbanken weiterhin zu nutzen und gleichzeitig alle Engpässe zu beseitigen.
Verteilte Cache-Bereitstellung
Hier ist also ein Bild: Wenn es sich um Altdaten Ihrer relationalen Datenbanken handelt, können Sie eine Caching-Ebene zwischen der Anwendung und der Datenbank einfügen.
Wenn Sie das tun, beginnen Sie damit, Daten zwischenzuspeichern, die Sie häufig verwenden werden. Und in etwa 80 Prozent der Fälle müssen Sie nicht einmal auf die Datenbank zugreifen. Da es sich beim Cache um einen verteilten Cache handelt, können Sie immer mehr Server hinzufügen. Er skaliert auf die gleiche Weise wie die Anwendungsebene. Sie haben hier also mindestens zwei Cache-Server und halten dann ein Verhältnis von vier zu eins oder fünf zu eins zwischen der Anwendungsschicht und der Caching-Schicht ein. Dieses Verhältnis kann sich nun je nach Art Ihrer Geschäftstätigkeit ändern. Wenn Sie, sagen wir, wenn Sie eine Webanwendung hätten, für jeden Benutzerklick Hunderte von Cache-Aufrufen durchführen würden, dann würde sich das Verhältnis natürlich ändern, aber in den meisten Fällen führen Sie nicht Hunderte von Cache-Aufrufen durch.
Ein typischer Cache-Server ist nur ein kostengünstiger Server. Es handelt sich um eine Konfiguration vom Typ Webserver, Dual-CPU, Quad-Core-Typ, es verfügt lediglich über viel Speicher. Viel Speicher bedeutet, dass 16 bis 32 GB ziemlich normal sind, mehr als 32 GB sind normalerweise nicht erforderlich. Obwohl wir viele Kunden haben, die auf bis zu 64 Gigabyte umsteigen, empfehlen wir, statt viel mehr Speicher in jeder Box zu haben, einfach weitere Boxen hinzuzufügen. Der Grund dafür ist, dass je mehr Speicher Sie in jeder Box haben, desto leistungsfähigerer Prozessor erforderlich ist und Ihre Box dann immer mehr wie eine Datenbank aussieht, was nicht beabsichtigt ist. Sie möchten die Kosten so gering wie möglich halten.
Nun ist ein verteilter Cache eine Infrastruktur, die Sie für alle Ihre Anwendungen bereitstellen möchten. Genauso wie Sie über eine Datenbank verfügen, bei der es sich praktisch um eine gemeinsame Infrastruktur handelt, besteht die neue Best Practice darin, über einen verteilten In-Memory-Cache zu verfügen. Es wird auch In-Memory genannt NoSQL Schlüsselwertspeicher. Und integrieren Sie es in Ihre Infrastruktur- und Architekturanwendungen, damit Sie diesen Shop immer besuchen. Sie überprüfen also den Shop, bevor Sie zur Datenbank gehen. Sobald Sie über diese Infrastruktur verfügen, werden alle Ihre Anwendungen automatisch skalierbar. Sie müssen sich also nie Sorgen machen, dass die Datenbanken zu einem Engpass werden. Und das größte Problem bei der Skalierbarkeit bzw. Unfähigkeit zur Skalierung besteht darin, dass Ihr Unternehmen dann viel Aktivität ausübt.
Nehmen wir an, Sie sind eine Fluggesellschaft und haben gerade eine Sonderaktion für Hawaii durchgeführt. Am, ich weiß nicht, Mittwoch loggen sich alle auf Ihrer Website ein, um mit dem Ticketkauf zu beginnen. Sie werden also nach Flügen suchen und Tickets kaufen, und Sie haben ungefähr fünfmal mehr Verkehr als zuvor, und plötzlich wird die Website langsamer, vielleicht stürzt sie ab, und sie kann natürlich abstürzen Wenn Ihre Datenbank überlastet ist, sie aber über akzeptable Grenzen hinaus langsamer wird, sind die Kosten für das Unternehmen sehr hoch, da die Leute einfach abwandern. Sie müssen also wirklich sicherstellen, dass Sie Skalierbarkeit einplanen, damit es nie zu der Situation kommt, dass Ihr Unternehmen mehr Aktivitäten durchführen möchte, zwar Geschäfte generieren kann, Sie aber keine Verarbeitung innerhalb der Anwendung durchführen können. Und wenn Sie über die richtige Infrastruktur verfügen, werden Sie dieses Problem nie haben.
Ich stelle gerade die Frage auf, warum Sie ein verteiltes Caching verwenden sollten. Welches Problem gelöst wird, und dann gehen wir im Detail darauf ein, wie Sie es tatsächlich verwenden. Neben mehr Speicher verfügt man in der Regel, wie gesagt, über eine Dual-CPU, eine Quad-Core-Konfiguration und zwei Netzwerkkarten mit jeweils einem Gigabit oder mehr. Im Falle von NCache Dies sind ggf. Windows-Boxen Redis Dies sind Linux-Boxen, je nachdem, ob Sie eine .NET- oder eine Java-Anwendung haben. Mein Fokus liegt hier auf .NET, aber für Java gibt es auch verteilte Caches. Sie nennen sie In-Memory-Data-Grid, auf der .NET-Seite spricht man von einem verteilten Cache.
Häufige Anwendungsfälle von verteiltem Cache
Okay! Nachdem wir nun sozusagen dargelegt haben, warum Sie einen verteilten Cache als Teil Ihrer Best-Practice-Infrastruktur benötigen, sowohl aus IT-Perspektive als auch, was noch wichtiger ist, aus Entwicklungsperspektive, möchten Sie die Anwendung entwerfen. Die erste Frage, die mir ebenfalls in den Sinn kommt, ist: Wie verwende ich diesen Cache? Welche Anwendungsfälle gibt es? Wo verwende ich sie? Ich weiß, welche Art von Anwendungen ich verwenden werde, aber welche Art von Daten werde ich zwischenspeichern?
Es gibt also drei Hauptkategorien. Nummer eins ist das, was jeder versteht, nämlich das Zwischenspeichern von Anwendungsdaten.
Zwischenspeichern von Anwendungsdaten
Beim Caching von Anwendungsdaten werden also Daten zwischengespeichert, die in Ihrer Datenbank vorhanden sind, Sie zwischenspeichern sie, darüber haben wir gerade gesprochen. Wenn Sie das also tun, erstellen Sie tatsächlich zwei Kopien der Daten. Einer befindet sich in der Datenbank des Masters und einer im Cache, der temporären Kopie. Was ist in diesem Fall das Hauptanliegen? Was kann schiefgehen, wenn man zwei Kopien hat? Sie könnten aus dem Takt geraten. Tatsächlich ist dies eine so große Angst in den Köpfen der Menschen, dass die meisten Leute, wenn man sie fragt, wofür man Caching verwendet, sagen: „Nun, bei schreibgeschützten Daten kann ich bei meinen Transaktionsdaten kein Risiko eingehen, bei Daten, die …“ ändert sich, denn was ist, wenn das schief geht? Was passiert, wenn mein Kunde das Geld zweimal von demselben Konto abhebt?
Wenn Sie Transaktionsdaten nicht zwischenspeichern können, sinkt der Wert eines verteilten Caches erheblich, da Referenzdaten nur zwanzig oder dreißig Prozent der Daten ausmachen. 80 Prozent oder 70 bis 80 Prozent der Daten sind Ihre Kunden, Ihre Konten, die Aktivitäten, Ihre Transaktionsdaten, die Daten, die sich vielleicht alle 30 Sekunden, jede Minute ändern, Daten, die Sie möglicherweise im Cache behalten können eine sehr, sehr kurze Zeit. Wenn Sie also keinen Cache für Transaktionsdaten verwenden können, haben Sie sich wirklich eingeschränkt. Ein guter verteilter Cache muss also sicherstellen, dass der Cache und die Datenbank immer synchron sind. Sobald Sie also die Gewissheit haben, dass der Cache immer mit der Datenbank synchronisiert ist, können Sie praktisch alles zwischenspeichern und wenn Sie das tun, sehen Sie wirklich viele Spiele.
Und ich werde noch viel detaillierter darauf eingehen.
ASP.NET-spezifisches Caching
Der zweite Anwendungsfall besteht darin, dass Sie bei einer ASP.NET-Anwendung bestimmte ASP.NET-spezifische Dinge zwischenspeichern können. Und das Schöne an dieser Kategorie ist, dass Ihrerseits keine Programmierung erforderlich ist, da Microsoft über ein Framework verfügt, in das ein Cache einfach eingefügt wird. Nummer eins ist der Sitzungsstatus. So ziemlich jede ASP.NET-Anwendung muss einen Sitzungsstatus haben. Einige Leute haben es speziell so programmiert, dass es nicht verwendet wird, was keine gute Idee ist. Sie sollten eine Sitzung nutzen, die Ihr Leben viel einfacher macht.
Eine Sitzung ist ein sehr guter Kandidat für die Zwischenspeicherung, denn wenn Sie eine Sitzung in der Datenbank speichern, stoßen Sie auf die gleichen Probleme, dass Datenbanken nicht für die Speicherung von Blobs ausgelegt sind, was eine Sitzung ausmacht. Die Leistung ist also sehr langsam und, was noch wichtiger ist, die Skalierbarkeit geht einfach verloren. Aus dem gleichen Grund, aus dem Sie Anwendungsdaten zwischenspeichern möchten, möchten Sie die Sitzungen auch nicht in der Datenbank ablegen. Sie möchten sie im verteilten Cache ablegen.
Der zweite ist ein Ansichtszustand. Wenn Sie nicht das MVC-Framework verwenden, wenn Sie noch das alte ASP verwenden.NET framework dann Zustand anzeigen. Für diejenigen unter Ihnen, die nicht wissen, was ein Ansichtsstatus ist: Ein Ansichtsstatus ist eine verschlüsselte Zeichenfolge, die nur einhundert Bytes oder Hunderte von Kilobytes groß sein kann, die generiert und an den Browser gesendet und dann wieder zurückkommt wenn du einen Beitrag zurückschreibst. Es ist also eine ziemlich teure Reise. Dies verlangsamt natürlich Ihre Leistung, da viel mehr Daten übertragen werden. Und es erhöht auch Ihre Bandbreitenkosten, da beim Hosten Ihrer Anwendung die darüber liegende Pipe nicht frei ist. Wenn Ihre Kunden also auf Ihre Webanwendung zugreifen, zahlen Sie hier für die Bandbreite. Wenn Sie das also mit den Millionen und Abermillionen von Anfragen oder Transaktionen multiplizieren, die Ihre Benutzer oder Kunden durchführen werden, sind das eine Menge zusätzlicher Kosten, die Sie nicht verursachen möchten. Das ist also ein sehr guter Kandidat für das Caching. Sie haben es also auf dem Server zwischengespeichert und einfach einen kleinen Schlüssel gesendet, damit der Schlüssel zurückkommt, wenn das nächste Mal ein fehlerhafter Beitrag auftritt, und bevor die Seite ausgeführt wird, wird der Ansichtsstatus aus dem Cache abgerufen.
Der dritte ist der Ausgabecache, der ein weiterer Teil von ASP ist.NET framework Wenn sich Ihre Seitenausgabe nicht ändert, warum sollten Sie sie dann das nächste Mal ausführen? Denn jedes Mal, wenn Sie die Seite ausführen, verbraucht sie CPU, Speicher und alle anderen Ressourcen, einschließlich Ihrer Datenbanken. Daher ist es viel besser, einfach die Ausgabe der letzten Ausführung zurückzugeben, die die gesamte Seite oder einen Teil der Seite umfassen kann. Für alle diese drei Punkte schließen Sie einfach einen verteilten Cache an, ohne dass Sie etwas programmieren müssen. Das zeige ich dir jetzt. Die Natur dieses Problems unterscheidet sich jedoch stark von der Anwendung.
In den Bewerbungsdaten hatten wir zwei Kopien der Daten, oder? Das Problem war also die Synchronisierung. Hier haben Sie nur eine Kopie, die in einem In-Memory-Speicher aufbewahrt wird. Was ist also die größte Sorge, wenn man so etwas in einem In-Memory-Store aufbewahrt und das die einzige Kopie ist? Das auch! Oder wenn ein Server ausfällt, haben Sie einfach den Cache verloren. Damit irgendetwas davon im Cache gespeichert wird. Stellen Sie sich einfach die gleiche Fluggesellschaft vor, die ich gerade ausprobiert habe, und habe eine halbe Stunde damit verbracht, die perfekte Kombination aus Fluggesellschaften zu finden. Ich bin gerade dabei, auf „Senden“ zu klicken, und die Sitzung geht verloren. Keine gute Erfahrung, weil der Webserver gerade ausgefallen ist.
Wie lösen Sie also dieses Problem, wenn Sie einen In-Memory-Speicher haben und dieses Problem haben? Sie haben Redundanz. Sie haben mehr als eine Kopie der Daten. Ein guter verteilter Cache muss Ihnen also die Datenreplikation ermöglichen. Ohne eine intelligente und leistungsstarke Datenreplikation wird Ihr Cache wiederum deutlich weniger nützlich sein.
Laufzeitdatenfreigabe über Ereignisse
Der dritte Anwendungsfall, den die meisten Menschen nicht kennen oder der immer beliebter wird, besteht darin, dass Sie diese sehr skalierbare In-Memory-Infrastruktur nutzen können. Sie können es für die gemeinsame Nutzung von Laufzeitdaten über Ereignisse verwenden. Es ähnelt einer Art Messaging, ist jedoch eine stark vereinfachte Version davon und befindet sich in einer einzigen Rechenzentrumsumgebung, in der mehrere Anwendungen den Cache als Möglichkeit nutzen können Pub/Sub-Typ einer Datenfreigabe. Eine Anwendung legt also etwas in den Cache, löst ein Ereignis aus und die Verbraucher, die an diesen Daten interessiert sind, haben dieses Ereignis erhalten und können diese Daten konsumieren.
Anstatt das also in die Datenbank oder in eine MSM-Warteschlange zu stellen, entsteht eine Situation, die ihren eigenen Zweck hat. Ein Cache ist nicht dazu da, die MSM-Warteschlange zu ersetzen, aber in vielen Situationen ist er eine viel einfachere und vor allem viel schnellere und skalierbarere Infrastruktur für den ereignisbasierten Datenaustausch. Wenn Sie also mehrere Anwendungen haben, die zur Laufzeit Daten miteinander teilen müssen, sollten Sie dies auf jeden Fall als eine sehr wichtige Funktion in Betracht ziehen.
ASP.NET-spezifisches Caching
Ich zeige Ihnen nur kurz das ASP.NET-Caching und wie Sie das machen. Es ist sehr, sehr einfach und ich werde es tatsächlich verwenden ... Ich habe also Beispielcode. Wenn ich also zum Beispiel ... Ich hätte also diese ASP.NET-Anwendung. Alles, was Sie tun müssen, ist, in diesem Fall die web.config aufzurufen NCache Und wieder wird es für alle Caches ziemlich gleich sein. Als erstes müssen Sie eine Baugruppe hinzufügen. Diese Assembly ist also der Sitzungsstatusanbieter. Also, ASP.NET framework verfügt über eine Sitzungsstatus-Provider-Schnittstelle, die ein verteilter Cache implementieren muss. NCache hat es implementiert und lädt die Assembly in Ihre Anwendung.
Sobald Sie das getan haben, müssen Sie als Nächstes zum Sitzungsstatus-Tag wechseln. Stellen Sie in der Tat sicher, dass der Modus benutzerdefiniert ist und dass die Zeitüberschreitung Ihren Wünschen entspricht. Im Falle von NCache dann schreibst du einfach diese Zeile. Andere Caches verfügen über ähnliche Informationen. Also, Sie müssen einfach... Im Falle von NCache Alles, was Sie tun müssen, ist sicherzustellen, dass Ihr Cache einen Namen hat, und ich zeige Ihnen, was das bedeutet. Aber schon mit so vielen Änderungen in Ihrer Anwendung können Sie grundsätzlich mit dem Speichern Ihrer Sitzungen beginnen. Wenn Sie diese Änderung also in jeder web.config in der Anwendungsschicht vornehmen, stellen Sie natürlich sicher, dass ein Cache vorhanden ist. Sobald Sie dies getan haben, können Sie tatsächlich damit beginnen, Sitzungen im Cache abzulegen.
Hands-on-Demo
Ich zeige Ihnen schnell einen Cache-Cluster. Ich habe zum Beispiel diese ... ähm, ich habe diese Azure-VMs, bei denen ich Demo1 und Demo2 habe, ebenso wie meine Cache-Server-VMs und der Demo-Client wie der Anwendungsserver. Das sind also die Kunden. Ein Cache-Client ist Ihre Anwendungsserver-Box. Also werde ich ...
Erstellen Sie einen Cache-Cluster
Und ich habe mich angemeldet, sagen wir, ich habe mich beim Demo-Client angemeldet und werde diesen bei Bedarf verwenden NCache und wieder werde ich dieses Tool namens verwenden NCache Manager. Es ist ein grafisches Tool. Lassen Sie uns die Caches von einem einzigen Ort aus konfigurieren. Ich werde hierher kommen und sagen: Erstellen Sie einen neuen Cluster-Cache. Alle Caches sind in benannt NCache. Deshalb werde ich meinen Cache Demo-Cache nennen. Ich werde nicht auf die Details dieser Eigenschaften eingehen.Ich werde meine Replikationsstrategie als partitioniertes Replikat auswählen. Und ich wähle eine asynchrone Replikation. Ich mache meinen ersten Cache-Server. Ich werde hier meinen zweiten Cache-Server einrichten. Also werde ich einen Cache-Cluster mit zwei Knoten aufbauen. Ich werde einfach alles auswählen. Das ist also der TCP-Port, auf dem der Cache-Cluster gebildet wird. Sie können ihn ändern, wenn ein Portkonflikt auftritt. Ich werde angeben, wie viel Speicher mein Cache-Server für den Cache verwenden soll. Ich habe es natürlich als einen einzigen Auftritt, bei deinem wird es noch viel mehr sein.
Lassen Sie mich Ihnen zum Beispiel hier kurz zeigen, was das bedeutet. Ich werde einfach zu diesem Teil gehen.
Stellen Sie sich das also wie einen Cache-Server vor und dieser hat einen anderen Cache-Server. Hier existiert also Partition 1. Partition 1 ist im Wesentlichen eine Sammlung von Buckets. Partition 2 hat eine eigene Box. Es gibt also einen Fall NCache Es handelt sich um etwa tausend Buckets, die auf die Anzahl Ihrer Partitionen verteilt werden. Jeder Server hat eine Partition und bei jedem Server wird die Partition auf einem anderen Server repliziert. Wenn Sie also über drei Server verfügen, sehen Sie, dass Partition 1 hier gesichert ist. Partition 2 wird hier gesichert. Partition 3 wird hier gesichert. Die Replikate sind in diesem Fall nicht aktiv NCache. Sie werden nur aktiv, wenn die Hauptpartition ausfällt.
Was ich dort also spezifiziere, ist die Größe einer Partition. Wenn ich also im Falle einer Partitionsreplik hier beispielsweise 1 Gig spezifiziere, wird tatsächlich 1 Gig für die Partition und 1 Gig für die Replik verwendet. Also insgesamt 2 Gigs. Wenn Sie also beispielsweise über 16 GB Arbeitsspeicher verfügen, möchten Sie etwa zwei oder zweieinhalb GB für das Betriebssystem und andere Prozesse übrig lassen und den Rest können Sie verwenden. Für 16 GB können Sie also problemlos 13 GB verwenden. Also, machen Sie ein halbes und ein halbes Stück. Es handelt sich also um eine Partitionsgröße von sechseinhalb Gigabyte, und natürlich können Sie auch 32 Gigabyte haben, und wenn Sie wiederum drei Gigs weglassen, haben Sie eine Partitionsgröße von 29 Gigabyte, halbeinhalb und 14 Gigabyte. Und wenn Sie dann mehr Speicher benötigen, können Sie statt mehr Speicher einfach weitere Server hinzufügen, da dies einfacher zu verwalten ist. Dadurch bleiben die Dinge viel skalierbarer. Also klicke ich hier einfach auf „Weiter“.
Das nächste ist meine Räumungsrichtlinie. Ich werde nicht auf diese Details eingehen. Und ich werde jetzt einen Client-Knoten hinzufügen. Sobald ich das getan habe, werde ich einen Cache starten. Ich werde einen Cache erstellen und wollte Ihnen diesen Teil zeigen, weil das den Rest des Vortrags ausmacht. Es werden also diese beiden Cache-Knoten gestartet.
Stress simulieren und Cache-Statistiken überwachen
Also werde ich eine Reihe von Überwachungstools öffnen und dieses Tool namens Stresstest-Tool tatsächlich ausführen.
Es ist eine Befehlszeile. Es handelt sich um eine Konsole, die tatsächlich mit der Aktivität im Cache beginnt. Das ist so, als würde es Ihre Anwendung simulieren. Wenn Sie also sehen, dass Ihre Anwendung Sitzungen in den Cache legt, ist jede Sitzung ein Objekt. Sie fügen also hinzu. Die Cache-Anzahl beträgt also 177, auf dieser Box 172 und 35. Es wird also fast ausgeglichen sein und dann wird es besser auf einem anderen gesichert ...
Dieses ist hier gesichert, dieses ist hier gesichert. Wie Sie sehen, erfolgt die Replikation automatisch. Um Ihre Bewerbung müssen Sie sich keine Sorgen machen. Sie haben lediglich diesen Cluster erstellt und auf der Anwendungsebene einfach die Web.config geändert, und alles andere geschieht automatisch. Sie können diese Dinge natürlich überwachen, aber der Cache ist benannt. In unserem Fall habe ich den Cache also als Demo-Cache bezeichnet. Sie können es benennen, tatsächlich können Sie mehrere Caches haben. Die häufigste Konfiguration, die wir bei unseren Kunden gesehen haben, ist, dass sie über drei Caches verfügen. Einen Cache nennen sie beispielsweise Objekt-Cache. Es handelt sich also um ihren Haupttransaktionscache. Einen Cache nennen sie Session-Cache. Daher werden alle Sitzungen in diesem Cache abgelegt. Den dritten Cache nennen sie ihn Referenz-Cache. Sie legen also mehr Referenzdaten im Referenzcache ab.
Und der Grund dafür, dass sie einen separaten Cache für Transaktionsdaten und nicht für Referenzdaten erstellen, liegt darin, dass Sie für Referenzdaten diese Funktion namens „Client-Cache“ verwenden möchten, in der Sie zwischenspeichern möchten.
Client-Cache für noch bessere Leistung
Eigentlich springe ich durcheinander, also verzeihen Sie mir bitte, wenn ich etwas durcheinander bringe. Wenn Sie Referenzdaten haben, lassen Sie mich noch einen Schritt zurückgehen. Bevor es verteilte Caches gab, gab es dieses ASP.NET-Cache-Objekt. Das ASP.NET-Cache-Objekt war ein lokaler InProc-Cache. Es ging innerhalb des Bewerbungsprozesses superschnell, oder? Wenn Sie Dinge auf Ihrem eigenen Heap aufbewahren, kann nichts mit dieser Leistung mithalten. Sobald Sie in einen verteilten Cache gehen, ist es anders, es ist ein Cache für automatische Prozesse. Was die Leute nicht merken, ist, dass Ihre Leistung tatsächlich sinkt.
Wir haben viele Kunden, die zunächst verblüfft sind und sagen: „Nun, ich hätte eine Leistungssteigerung bekommen sollen, aber meine Leistung ist durch einen ASP.NET-Cache da oben gesunken, jetzt ist es viel langsamer, weil sie das Objekt serialisieren müssen.“ Wenn Sie ein großes Objekt haben, ist die Serialisierung ein ziemlich erheblicher Kostenfaktor, der unabhängig von einem bestimmten Cache anfallen muss. Und sobald Sie den Prozesscache verlassen, ist Ihre Leistung viel langsamer als bei einem lokalen InProc-Cache. Aber es ist immer noch schneller als die Datenbank. Es ist fast zehnmal schneller als die Datenbank, aber fast zehnmal langsamer als der InProc-Cache.
Was also passiert, ist, dass die Leute den Vorteil dieses InProc-Cache nutzen möchten. Nun, für Daten, die sich nicht sehr häufig ändern, gibt es eine Funktion namens Client Cache. Manche Leute nennen es „Near Cache“, besonders auf der Java-Seite.
Bei dieser Funktion handelt es sich im Wesentlichen um einen lokalen Cache. Es ist wie Ihr InProc ASP.NET-Cache. Es befindet sich im Anwendungsprozess oder es kann nur ein lokaler OutProc-Cache sein, der nicht so schnell wie InProc, aber immer noch schneller ist als der Übergang zur Caching-Ebene. Der Unterschied besteht jedoch darin, dass dieser Cache die Caching-Ebene kennt. Dieser Client-Cache ist der Cache über dem Cache und wird synchronisiert. Sie müssen sich also keine Gedanken über das größte Problem machen, über das wir gesprochen haben: Wie halten Sie den Cache mit der Datenbank synchron? Nun haben Sie drei Kopien der Daten. Eine in der Datenbank, eine in der Caching-Ebene, eine im Client-Cache. Natürlich ist der Client-Cache eine Teilmenge der Caching-Ebene. Die Caching-Ebene ist eine Teilmenge der Datenbank. Aber was auch immer es ist, es muss synchronisiert werden. Da es also einen Client-Cache gibt, handelt es sich wiederum um einen InProc, der Dinge in Objektform statt in serialisierter Form speichert. Es hält es auf Ihrem Haufen. Sie erhalten also den gleichen Vorteil wie das lokale InProc ASP.NET-Cache-Objekt, jedoch mit allen anderen Vorteilen der Skalierbarkeit, da es sich bei diesem Client-Cache um eine kleine Teilmenge handelt. Sie können festlegen, wie groß es sein soll. Diese Schwelle wird es niemals überschreiten.
Sie haben also möglicherweise einen Gig in jedem Client-Cache und 32 Gigs in der Caching-Ebene, und die Datenbank enthält wahrscheinlich noch viel mehr. Wie auch immer, selbst wenn man einen Auftritt hat, weil es ein bewegliches Fenster ist, oder? Also, was auch immer Sie tun, Sie behalten es bei. Einige der Daten bleiben für eine lange Zeit erhalten, andere möglicherweise für ein paar Minuten, aber innerhalb dieser Zeit werden Sie Hunderte von Anrufen tätigen und müssen nicht auf die Caching-Ebene wechseln, und das ist natürlich auch nicht der Fall Gehen Sie zur Datenbank. Ein Client-Cache ist also eine wirklich leistungsstarke Funktion, wenn Sie ihn aktiviert haben. Sie tun dies, um weitere Referenzdaten zu erhalten. Also, im Falle von NCache, können Sie durch Konfigurationsänderung einen Client-Cache angeben. Es gibt keine zusätzliche Programmierung, aber es wird einem bestimmten Cache zugeordnet. Aus diesem Grund verfügen unsere Kunden normalerweise über drei Caches. Objektcache, Sitzungscache und Referenzcache. Für den Referenz-Cache verwenden sie einen Client-Cache, für die anderen beiden nicht.
Einfach zu konfigurierender Client-Cache
Warum führen sie nicht einen Client-Cache mit dem Sitzungscache durch? Eigentlich, weil die Leistung nachlässt. Der Grund dafür ist, dass dies nur dann besser ist, wenn Sie viel mehr lesen und schreiben. Denn was passiert im Falle eines Schreibvorgangs? Sie schreiben hier und dann hier und dann schreiben Sie in die Datenbank. Sie schreiben also an drei Stellen. Es bringt also keinen Mehrwert, wenn Sie mehr Schreibvorgänge durchführen müssen. Sie aktualisieren Ihre Kopie und dann aktualisieren Sie nur diese, und dann benachrichtigt dies alle anderen Client-Caches, sich selbst zu aktualisieren. Es handelt sich um ein verzögertes Update, nicht dass es sich nur um ein oder zwei Millisekunden verzögert, aber im Falle eines Client-Cache handelt es sich dennoch um ein verzögertes Update. Es gibt keine Replikation zwischen den Client-Caches. Der Client-Cache synchronisiert sich nur selbst mit der Caching-Ebene und die Caching-Ebene gibt die Aktualisierungen dann an andere Client-Caches weiter. Nur wenn der andere Cache diese Daten hat. Denn im Falle des Client-Cache verfügt jeder Client-Cache über unterschiedliche Daten, basierend auf Ihrem Nutzungsmuster.
Wo wird der Client-Cache verwendet?
Gehen wir also einen Schritt zurück: Im Falle der Referenzdaten verfügt jeder Client-Cache über einen eigenen Datensatz. Nehmen wir also an, 1 bis 1000, 500 bis 1500 und so weiter. Es gibt also einige Überschneidungen zwischen den beiden, aber es handelt sich nicht um identische Kopien. Gemeinsam ist, dass sie alle Teilmengen dieses Caches sind. Wenn ich also die Elementnummer, sagen wir, 700, in diesem Cache aktualisiere, wird eine Aktualisierung im Cache durchgeführt und der Cache weiß, welche anderen Client-Caches diese Elemente haben, und sie werden sofort in ihren anderen Caches aktualisiert. Aber nur, wenn alle es haben. Es wird also nicht wirklich repliziert, da es sich im Fall des Client-Cache nicht um identische Kopien handelt. Was ich im Falle von Sitzungen eigentlich erklären wollte, ist, dass Sie im Falle einer Sitzung den Client-Cache und den Cluster-Cache aktualisieren müssen, zwei Stellen ohne Mehrwert, da Sie für Sitzungen einen Lese- und einen Schreibvorgang ausführen. Zum Zeitpunkt der Webanforderung lesen Sie also am Ende der Seite, auf der Sie schreiben.
Der Schreibvorgang muss nun also an zwei Stellen erfolgen und der Lesevorgang erfolgt im Client-Cache. Die Leistung sinkt also tatsächlich, wenn Sie Client Cache mit Sitzungen oder anderen schreibintensiven Vorgängen verwenden, aber die Leistung verbessert sich enorm, wenn Sie ihn für leseintensivere Vorgänge verwenden. Hat das Sinn gemacht?
Der größte Wert eines verteilten Caches ist also: Je schneller, desto schneller und am größten ist der Sitzungsstatus. Fast jede Anwendung hat es. Ich habe gerade einen Cache-Cluster mit zwei Knoten erstellt und Sie haben gesehen, wie lange es gedauert hat, vielleicht zwei Minuten, im Falle eines NCache. Es ist also wirklich einfach, einen Cache-Cluster zu erstellen. Natürlich möchten Sie Ihre Tests und ähnliches durchführen. Aber es ist wirklich einfach. Es gibt keinen technischen Aufwand. Wenn kein technischer Aufwand anfällt, sind Ihre Zeitpläne viel einfacher zu handhaben. Sie müssen lediglich einen Gesundheitstest durchführen, um durchzukommen. Wenn Sie mit der Verwendung eines verteilten Caches beginnen möchten, würde ich Ihnen dringend empfehlen, ihn als ersten Schritt für den Sitzungsstatus zu verwenden und dann mit dem Objekt-Caching zu beginnen, über das wir gleich sprechen werden.
Zwischenspeichern von Anwendungsdaten
Wir haben also über das Sitzungs-Caching gesprochen. Kommen wir kurz zum Caching von Anwendungsdaten. Hier ist was für ein typisches NCache Die API sieht so aus, dass sie dem ASP.NET-Cache sehr ähnlich sieht. Wenn Sie bemerken, dass eine Verbindung besteht.
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Sie stellen also eine Verbindung zum Cache basierend auf dem Namen her und erstellen einfach einen Cache mit dem Namen. Deshalb habe ich Ihnen diese Demonstration gegeben, damit Sie verstehen, was das bedeutet. Und dieses Cache-Handle behalten Sie genauso bei, wie Sie auch ein Datenbank-Handle beibehalten würden. Und dann verwenden Sie dieses Cache-Handle, um einen Cache.Get auszuführen. Jeder Get, jede Operation hat einen Schlüssel. Ein Schlüssel ist im Fall von eine Zeichenfolge NCache und dann formatieren Sie den Schlüssel basierend auf dem, was Sie damit machen. Im Falle eines einzelnen Objekts empfiehlt es sich daher, einfach den Klassennamen, möglicherweise den Attributnamen und den Wert anzugeben. Und dann können Sie das bekommen. Es gibt also ein Get und Get.Contains, Add, AddAsync. Asynchron bedeutet, nicht warten.
Was passiert, ist, dass darunter auf der Client-Seite eine De-Serialisierung stattfindet. Also machen wir für den Client ein Cache.Add. Nehmen wir an, Sie geben ihm ein Objekt, es ist ein Mitarbeiterobjekt, und er wird es basierend auf der standardmäßigen .NET-Serialisierung oder der benutzerdefinierten Serialisierung serialisieren NCache Serialisierung. Und dann erstellen Sie daraus ein Byte-Array und senden das Byte-Array an den Cache. NCache macht mehr als das, weil Sie möglicherweise bestimmte Attribute indizieren müssen. Es extrahiert die Werte davon. Ja, das wird es. Es wird. Es sofort. Ja! Jedes Objekt, das Sie zwischenspeichern, muss eine Serialisierung durchlaufen.
Sobald Sie die Anwendung starten, werden Ausnahmen ausgelöst. Wenn Sie ein ASP.NET-Cache-Objekt verwenden, ist keine Serialisierung erforderlich. Sie können also so ziemlich alles zwischenspeichern, und oft ist es so, dass Ihre eigenen Objekte möglicherweise einfacher zu serialisieren sind, Sie aber möglicherweise einen Drittanbieter verwenden. Nehmen wir an, früher wurde das Datentabellenobjekt nicht serialisiert, aber jetzt ist es so. Wenn Sie also Objekte von Drittanbietern verwenden, die nicht serialisierbar sind, haben Sie keine Kontrolle. Sie können sie also nicht abfangen, wenn Sie einen verteilten Cache verwenden. Im Falle von NCache, wir haben unsere eigene benutzerdefinierte Serialisierung, mit der Sie diese Objekte identifizieren können. NCache Anschließend erstellt es zur Laufzeit den Serialisierungscode für Sie und kompiliert ihn im Speicher. Dadurch können Sie auch Objekte verwenden, die nicht serialisierbar sind. Diese Serialisierung erfolgt jedoch sofort. Ihre Anwendung funktioniert also nicht, wenn sie nicht die richtige Serialisierung verwendet.
Async besagt im Wesentlichen, dass man nicht warten sollte, bis der Cache aktualisiert wird. Ich kann also weitermachen. Ich vertraue darauf, dass der Cache dieses Ding hinzufügt. Sie entsperren also nicht die Datenbank, sodass die Aktualisierungen aufgrund von Datenintegritätsproblemen fehlschlagen können. Ein Cache weist keine Probleme mit der Datenintegrität auf. Es schlägt nur fehl, wenn es zu Abstürzen kommt. Wenn Ihnen das Gedächtnis ausgeht oder etwas anderes passiert. Sie können also ziemlich sicher sein, dass Sie höchstwahrscheinlich alles, was Sie hinzufügen, in den Cache aufnehmen werden. Async gibt Ihnen also noch einen weiteren Schub. Wie Sie sehen, sieht die API also sehr einfach aus.
Cache frisch halten
Wenn Sie also Anwendungsdaten zwischenspeichern, wie halten Sie den Cache aktuell? Das ist wirklich sehr, sehr wichtig. Es gibt verschiedene Möglichkeiten zum Cachen.
Verwendung zeitbasierter Abläufe
Abläufe: Fast alle Caches unterstützen Abläufe. Es gibt ein absolutes Ablaufdatum, bei dem Sie diese Angabe für jedes Element erhalten. Hier ist, wie lange es meiner Meinung nach im Cache bleiben soll. Das kann zwischen 15 Sekunden und Stunden, Tagen und Wochen liegen. Und zwar für das Caching von Anwendungsdaten. Es gibt einen weiteren Ablauf, der als gleitender Ablauf bezeichnet wird und nicht der Synchronisierung des Caches mit der Datenbank dient. Es dient der Bereinigung. Also, dieses ASP.NET, all die vorübergehenden Daten, über die wir gesprochen haben, was passiert, wenn Sie mit diesen Daten fertig sind? Sie sollten sich keine Gedanken über die Reinigung machen müssen. Sie können also einen gleitenden Ablauf festlegen und sagen, wenn niemand diese Daten so lange verwendet, sagen wir, bei Sitzungen von 20 Minuten, wenn niemand die Sitzung für diese 20 Minuten nutzt, entfernen Sie sie aus dem Cache. Das ist also eher eine Aufräumaktion.
Welche Risiken bestehen beim Ablauf? Das Ablaufdatum ist eigentlich eine Vermutung. Sie sagen: Ich glaube, mit fünf Minuten bin ich einverstanden, aber es gibt keine Garantie dafür, dass in dieser Zeit niemand die Daten in der Datenbank aktualisiert, insbesondere wenn andere Anwendungen oder andere Prozesse die Datenbank aktualisieren. Daher sind Ablauffristen nur in begrenzten Anwendungsfällen sinnvoll.
Verwendung von Datenbankabhängigkeiten
Eine weitere sehr wichtige Funktion besteht darin, dass es zu unerwarteten oder unvorhersehbaren Aktualisierungen in der Datenbank kommen kann. Wenn dies der Fall ist, sollte der Cache in der Lage sein, sich selbst mit der Datenbank zu synchronisieren. Der Cache sollte also über Ihre Datenbank Bescheid wissen. Es sollte ein Client Ihrer Datenbank werden und Ihre Datenbank auf Änderungen überwachen. In ADO.NET gibt es eine Funktion namens SQL-Abhängigkeit. Hat das jemand gesehen?
Also, SQL-Abhängigkeit ist das, was NCache wird zum Client Ihres SQL-Servers oder Ihrer Oracle-Datenbank. Im Falle eines SQL-Servers können Sie also die SQL-Abhängigkeit der SQL-Server-ADO.NET-Funktion verwenden NCache Wird verwendet, um Ereignisse aus der Datenbank abzurufen. Der Cache, NCache wird zum Client Ihrer Datenbank. Es empfängt Ereignisse und macht dann basierend darauf sein eigenes Ding. In manchen Fällen gibt es keine Veranstaltungen. Nehmen wir also an, wenn Sie DB2 oder MySQL hatten, gibt es dort keine Ereignisse. Dann sollte der Cache also in der Lage sein, Abfragen durchzuführen. NCache Unterstützt auch die Abfrage basierend. Also machen Sie das Gleiche, Sie speichern dieses Element im Cache und sagen, dass es dieser Zeile in dieser Tabelle zugeordnet wird und dann NCache führt die Abfrage durch und wenn sich diese Daten ändern, werden sie entweder erneut aus dem Cache entfernt oder eine neue Kopie neu geladen. Aber diese Funktion bietet Ihnen viel Komfort.
Nochmals, das Gleiche, worüber ich gesprochen habe, ist, dass Sie sicherstellen möchten, dass der Cache immer mit der Datenbank synchronisiert ist. Der Ablauf reicht nur für eine kleine Teilmenge der Anwendungsfälle aus.
Es kommt also zu einem Cache-Fehler, wenn Sie kein automatisches Neuladen durchführen. Wenn Sie also die SQL-Abhängigkeit starten, wird Folgendes entfernt: NCache Entfernt das Element aus dem Cache. Wenn Ihre Anwendung es also benötigt, kommt es zu einem Cache-Fehler, und dann sind Sie gezwungen, eine neue Kopie aus der Datenbank zu holen. Wenn Sie einen Cache-Fehler vermeiden möchten, der in vielen E-Commerce-Anwendungen auftritt, weil sie Daten so häufig lesen, dass sie nicht möchten, dass irgendetwas die Belastung der Datenbank erhöht, würden Sie tatsächlich die SQL-Abhängigkeit verwenden mit dieser Funktion namens Durchlesen.
Eigentlich muss ich Ihnen etwas Code zeigen, sonst wird es sehr langweilig. Lassen Sie mich es Ihnen schnell zeigen. Ich habe also nur eine sehr einfache Konsolenanwendung. Im Falle von NCache, alles was Sie tun müssen, ist hier einige Assemblys hinzuzufügen. Also, es gibt NCache.Laufzeit und NCache.Netz. Dann geben Sie einige Namespaces dieser beiden an, stellen dann eine Verbindung zum Cache her und haben Ihr Cache-Handle. Dann erstellen Sie ein Objekt und führen dann Cache.Add aus. Und Sie geben den Schlüssel an. Das ist kein guter Schlüssel. Ich wollte es ändern, aber Ihr Schlüssel sollte den tatsächlichen Wert enthalten. Sie führen also ein Cache.Add aus und geben das Objekt an.
In diesem Fall verwende ich auch einen absoluten Ablauf von einer Minute. Sie geben also den absoluten Ablauf an und fertig. Das ist alles, was Sie tun müssen, um dies zum Cache hinzuzufügen. Wenn Sie es das nächste Mal benötigen, führen Sie einfach einen Cache.Get aus, geben denselben Schlüssel an und erhalten das Objekt zurück. Sehr, sehr einfach für einen absoluten Ablauf. Das Gleiche können Sie auch für den gleitenden Ablauf tun. Anstatt einen absoluten Wert anzugeben, müssen Sie jedoch ein Intervall wie 10 Minuten oder 20 Minuten angeben. SQL-Abhängigkeit ist das, was ich Ihnen zeigen wollte. Wie es aussieht. Dort! Also die gleiche Art von Anwendung. Sie müssen nur diese beiden hier hinzufügen und die Namespaces angeben. Wenn Sie dann die Dinge zum Cache hinzufügen, geben Sie die SQL-Abhängigkeit an.
Lassen Sie mich einfach auf die Definition eingehen. Deshalb werde ich dies hier zum Cache hinzufügen. Ich habe also meinen Schlüssel, den ich dir letztes Mal gezeigt habe. Anstatt das Objekt hinzuzufügen, füge ich jetzt ein Cache-Element hinzu. Das ist ein NCache Struktur. Es speichert also das eigentliche Objekt und außerdem eine SQL-Abhängigkeit. So, NCache verfügt über ein Cache-Abhängigkeitsobjekt. Also erstelle ich eine neue SQL-Cache-Abhängigkeit. Das ist ein NCache Klasse, die intern der SQL-Abhängigkeit des SQL-Servers zugeordnet ist. Sie übergeben ihm also eine Verbindungszeichenfolge und die Verbindungszeichenfolge ist Ihre SQL-Server-Verbindungszeichenfolge, und Sie übergeben ihm eine SQL-Anweisung. In meinem Fall habe ich also „select this“ angegeben, wobei „product ID“ mein Wert ist. Also ordne ich es einfach einer Zeile in der Produkttabelle zu. Und indem ich das so genau spezifiziert habe, habe ich es jetzt gerade gesagt NCache um Client des SQL-Servers zu werden. Und entfernen Sie dieses Element, wenn sich dies ändert, wenn sich diese Zeile in der Datenbank ändert.
Es kommt also darauf an, was die SQL-Anweisung ist. Wenn die Sequenzmethode also nur eine Zeile enthält, wird sie nur einer Zeile zugeordnet, und das wird auch so sein. Normalerweise können Sie hier keine Verknüpfungen durchführen, und das ist die Einschränkung der SQL-Abhängigkeitsfunktion in ADO.NET. Für eine einzelne Tabelle ist dies jedoch problemlos möglich. So würden Sie also vorgehen ...
Der SQL-Server verfügt also über dieses Ding namens SQL-Broker. Es erstellt also tatsächlich einen Datensatz oder eine Datenstruktur auf der SQL-Server-Seite, um diese Datensätze zu überwachen. Für alle SQL-Abhängigkeiten, die Sie erstellen, erstellt der SQL-Server Datenstrukturen, um die Datensätze zu überwachen. Auf dieser Grundlage wird Ihnen eine SQL-Benachrichtigung gesendet.
Sie müssen dies also auf der SQL-Server-Seite konfigurieren, da es sich auch um eine Sicherheitssache handelt, sodass Ihre Datenbank in die Konfiguration des SQL-Servers einbezogen werden muss, aber es ist ziemlich einfach. Ich meine, es ist keine Programmierung oder irgendetwas auf dem Server erforderlich, sondern nur eine Konfiguration. Der Kunde kümmert sich um alles.
Durchlesen und Durchschreiben
Okay! Also haben wir die SQL-Abhängigkeit erledigt. Ich wollte es Ihnen zeigen. Wenn Sie dieses Element nicht aus dem Cache entfernen möchten, können Sie es über ein Durchlesen erneut laden. Das Durchlesen ist also eine weitere sehr, sehr leistungsstarke Funktion.
Read-through ist ein serverseitiger Code. Tatsächlich handelt es sich beim Durchlesen um Ihren Code, der auf dem Cache-Cluster ausgeführt wird. Sie registrieren also tatsächlich Ihren Code und er wird im Cache-Cluster ausgeführt. Es heißt Bi NCache. Und der Wert eines Durchlesens … Lassen Sie mich zunächst zeigen, wie ein Durchlesen aussieht, und ich zeige Ihnen, welchen Wert es hat. Ich meine, warum möchten Sie das Durchlesen durchführen? So sieht ein typisches Durchlesen aus. Es ist eine IReadThrough-Schnittstelle. Sie führen ein InIt durch, damit Sie eine Verbindung zu Ihren Datenquellen herstellen können. Sie führen natürlich eine Entsorgung durch, und dann gibt es eine Ladung aus der Quelle. Es übergibt Ihren Schlüssel und erwartet ein Cache-Element zurück. Das Cache-Element enthält also Ihr Objekt und eine Reihe anderer Dinge, für die Sie Abläufe und andere Dinge darin festlegen können. Sehr einfache Schnittstelle.
Dies wird von aufgerufen NCache Sie implementieren also diese Schnittstelle und registrieren Ihre Assembly. Im Falle von NCache, Sie registrieren Ihre Assembly beim Cache und wenn Sie nun einen Cache.Get ausführen und dieses Element nicht im Cache vorhanden ist, wird der Cache tatsächlich NCache ruft Ihr Lesegerät auf, um es aus Ihren Datenquellen abzurufen. Ihre Datenquelle könnte eine Datenbank, ein Mainframe oder jede andere Datenquelle sein. Durch einen Read-Through-Vorgang können Sie also sicherstellen, dass ein Cache immer über die Daten verfügt und zwar in dem Maße, wie die Anwendung sie sieht. Das ist also ein Vorteil.
Der zweite Vorteil ist das Nachladen, das … Sie können also tatsächlich das Durchlesen kombinieren. Sie können dies also bei Ablauf und Datenbanksynchronisierung tun, wenn das Element sonst aus dem Cache entfernt werden würde und Sie nicht möchten, dass es entfernt wird, weil Sie es sowieso einfach erneut laden möchten. Warum also nicht den Cache auf diese Weise neu laden lassen, denn wenn Sie nur daran denken, haben Sie Millionen von Elementen im Cache, die alle ständig ablaufen, oder? Denn so haben Sie es konfiguriert. Und Sie haben eine E-Commerce-Anwendung und eine sehr stark frequentierte Anwendung, und jedes Mal, wenn etwas abläuft, gibt es viele gleichzeitige Anfragen dafür. Sie werden alle in die Datenbank aufgenommen. Plötzlich ist der Datenbankverkehr ohne Grund gestiegen, obwohl Sie ihn einfach nicht im Cache benötigen.
Da dies ständig geschieht, werden Sie trotz des Caches einen starken Anstieg des Datenbankverkehrs feststellen. Das bedeutet also, dass ein Neuladen niemals aus dem Cache entfernt wird. Es wird einfach aktualisiert. Ihre Anwendungen werden also niemals in die Datenbank gelangen. Sie werden die alte Kopie so lange aktualisieren, bis Sie sie aktualisieren. Sie haben also plötzlich das Problem beseitigt oder behoben, bei dem es aufgrund der Abläufe oder der Datenbanksynchronisierung zu starken Spitzen im Datenbankverkehr kam, obwohl Sie über den Cache verfügten. Dadurch, dass der Cache dies beim Durchlesen neu lädt, wird es wirklich sehr leistungsfähig.
Der andere Vorteil des Durchlesens besteht natürlich darin, dass Sie die Anwendungsschicht zentralisieren und vereinfachen, da immer mehr Datenbankzugriffe über den Cache erfolgen. Wenn Sie also über mehrere Anwendungen verfügen, die auf dieselben Daten zugreifen, können Sie den Datenzugriff innerhalb der Caching-Ebene wirklich zentralisieren. Natürlich können Sie dies nicht für alle Daten tun, aber für viele Daten ist dies möglich.
Das Durchschreiben funktioniert auf die gleiche Weise wie das Durchlesen. Lassen Sie mich einfach zum Durchschreiben übergehen. Es funktioniert auf die gleiche Weise. Es verfügt über einen Write-Through-Provider, wiederum InIt, der entsorgt wurde, und statt „Laden“ handelt es sich nun um einen Schreibvorgang in die Datenquelle und es gibt eine andere Art von Massenschreibvorgang. Der Vorteil des Durchschreibens ist derselbe wie beim Durchlesen: Sie zentralisieren alles. Der zweite Vorteil besteht darin, dass Sie einen Schreibvorgang ausführen können, der darin besteht, dass Sie den Cache aktualisieren, der, wie gesagt, zehnmal schneller ist als die Datenbank, und dann den Cache auffordern, die Datenbank zu aktualisieren. Und das Write-Behind ist im Wesentlichen das Gleiche wie das Write-Through, erfolgt jedoch auf asynchrone Weise. Es handelt sich um eine Warteschlange, die erstellt und verarbeitet wird. Diese Warteschlange wird auch im Fall von repliziert NCache. Daher gehen keine Updates verloren, wenn ein Server ausfällt. Aber das „Write-Behind“ beschleunigt die Anwendung wirklich, denn ich meine, Sie haben es doch schon durch die Zwischenspeicherung beschleunigt, um alle Lesevorgänge durchzuführen, oder? Etwa 70 bis 80 Prozent der Lesevorgänge oder Transaktionen werden also ohnehin in den Cache verschoben. Warum nicht auch die Schreibvorgänge beschleunigen? Wenn Sie es im Write-Behind-Modus tun können, wenn Sie es sich leisten können, einen asynchronen Schreibvorgang durchzuführen. Wenn die Daten zu sensibel sind und Sie sich das nicht leisten können, führen Sie einen Durchschreibvorgang durch und erhalten dann nur den ersten Vorteil, nämlich die Zentralisierung des Codes. Der zweite Vorteil einer schnelleren Leistung ergibt sich nur, wenn Sie asynchron arbeiten können.
Zusammenfassung
Der Grundgedanke besteht darin, dass Sie, wenn Sie mit dem Caching beginnen, nicht an einen Cache denken, der hier nur ein einfacher Schlüsselwert ist. Ich meine, mein gesamter Zweck bestand darin, Sie davon zu überzeugen, dass Sie wirklich einen verteilten Cache als Teil davon benötigen Ihrer Infrastruktur und der Anwendungsarchitektur. Wenn Sie möchten, dass die Anwendungen skaliert werden, müssen Sie dies integrieren, unabhängig davon, welches Caching-Produkt Sie verwenden. Ich meine, Sie sollten es einfach haben. Derzeit gibt es für .NET-Leute folgende Optionen auf dem Markt NCache Das ist Open Source und auch kommerziell. Es gibt Redis dass Microsoft zumindest auf Azure verfügbar gemacht hat. Auf Azure handelt es sich um einen verwalteten Cache-Dienst. Außerhalb davon müssen Sie ihn installieren. Die Installation erfolgt hauptsächlich unter Linux, es sei denn, Sie verwenden die nicht unterstützte Open-Source-Version. Auf der Java-Seite gibt es viel mehr Optionen für das Caching. Das war also das Erste.
Das zweite Ziel, das Sie verstehen sollten, ist, dass es sich nicht um einen einfachen Schlüsselwert handelt. Sie möchten sicherstellen, dass Sie alle Arten von Daten zwischenspeichern und alle möglichen Situationen bewältigen können. Dann erzielen Sie den echten Nutzen. Und ich bin noch nicht einmal zum anderen Teil gekommen, weil mir tatsächlich die Zeit davonläuft, nämlich wie man zum Beispiel Laufzeitdaten teilt und welche architektonischen Dinge man sicherstellen möchte Der Cache ist immer dynamisch, sodass Sie Dinge konfigurieren können. Es ist Teil Ihres Rechenzentrums, es ist Teil Ihrer Produktionsumgebung. Daher ist jeder Cache, bei dem Sie zur Laufzeit keine Änderungen vornehmen können, kein geeigneter Cache. Dann kommt es zu vielen Ausfallzeiten. Wir haben Kunden, die einmal im Jahr Ausfallzeiten eingeplant haben. Einige unserer Kunden haben das nicht einmal, weil sie eine so hohe Verfügbarkeit haben.
Sie möchten sogar den Cache selbst ohne Ausfallzeit auf eine neue Version aktualisieren. Ich meine, es hängt davon ab, welche Geschäftsanforderungen Sie haben. Aber all diese Dinge müssen berücksichtigt werden, viele Menschen verfügen mittlerweile über mehrere Rechenzentren. Zumindest für DR-Zwecke und dann auch für den geografischen Lastausgleich. Wenn Sie das haben, erwarten Sie doch, dass sich Ihre Datenbank repliziert, oder?
Warum sollte der Cache also nicht mehrere Rechenzentren unterstützen können? Denn je weniger ein Cache leisten kann, desto mehr müssten Sie tun. Das ist das Endergebnis. Da sich Ihre Anwendungsanforderungen nicht ändern, muss der Cache berücksichtigt werden. Denken Sie also daran.
Es gibt also einen Vergleich zwischen NCache und Redis.
Sie sind beide Open Source. NCache hat auch Enterprise Edition. Also im Grunde, wenn Ihr .NET, NCache passt sehr gut rein. Im NCache, N steht für .NET. Unterm Strich meine ich, dass wir uns so sehr für .NET engagieren.