Orlando Code Camp
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
Im heutigen Gespräch geht es nicht darum NCache, es geht um verteiltes Caching. Ich werde darauf verweisen NCache als Beispiel, aber die Konzepte sind allgemeingültig und gelten daher für alle Caches.
Was ist Skalierbarkeit?
Okay! Lassen Sie uns zunächst ein paar Definitionen klären. Die erste Definition ist Skalierbarkeit. Skalierbarkeit ist nicht gleichbedeutend mit der Anwendungsleistung. Wenn Sie fünf Benutzer haben und Ihre Anwendung superschnell arbeitet, ist Ihre Anwendung erst dann skalierbar, wenn sie bei fünftausend, fünfzigtausend oder fünfhunderttausend Benutzern die gleiche gute Leistung erzielen kann. Bei der Skalierbarkeit geht es also um hohe Leistung bei Spitzenlasten. Manchmal wird Leistung mit Skalierbarkeit verwechselt. Möglicherweise weist Ihre Anwendung bei fünf Benutzern keine gute Leistung auf. In diesem Fall würde Ihnen das Caching nicht weiterhelfen, Sie müssen andere Probleme lösen.
Lineare Skalierbarkeit
Lineare Skalierbarkeit bedeutet, dass Ihre Anwendung so konzipiert ist, dass Sie weitere Server hinzufügen können und durch das Hinzufügen weiterer Server die Transaktionskapazität erhöhen können. Auch hier definieren wir die Skalierbarkeit im Hinblick auf die Transaktionskapazität, d. h. wie viele Benutzer und wie viele Transaktionen pro Sekunde Ihre Anwendung verarbeiten kann. Wenn Ihre Anwendung also linear mehr Transaktionen verarbeiten kann, wenn Sie mehr Server hinzufügen, dann ist sie linear skalierbar und unser Ziel ist es, eine lineare Skalierung zu erreichen, um eine lineare Skalierbarkeit in unserer Anwendung zu erreichen.
Nichtlineare Skalierbarkeit
Und wir wollen definitiv keine nichtlineare Skalierbarkeit, das heißt, Ihre Anwendung ist so aufgebaut, dass es ab einem bestimmten Punkt keine Rolle mehr spielt, ob Ihre Anwendung wächst, wenn Sie weitere Server hinzufügen, wahrscheinlich sogar fallen. Das bedeutet, dass es irgendwo einige Engpässe gibt, die nicht behoben wurden.
Welche Apps benötigen Skalierbarkeit?
Warum wollen wir also Skalierbarkeit und welche Anwendungen brauchen Skalierbarkeit?
In der Regel handelt es sich hierbei um serverseitige Anwendungen. Dies sind ASP.NET, jetzt ASP.NET core, Webdienste, IOT-Backends, Big-Data-Verarbeitung. Obwohl die Verarbeitung großer Datenmengen auf der .NET-Seite nicht üblich ist, handelt es sich eher um Java-Phänomene. Sie sollten jedoch auch in der Lage sein, dies mit .NET zu tun. Anwendungen zur Verarbeitung großer Datenmengen erfordern jedoch auch Skalierbarkeit und alle anderen Serveranwendungen. Sie könnten beispielsweise eine Bank sein und Millionen von Kunden haben, die anrufen und ihre Adresse ändern oder vielleicht eine neue Karte ausstellen oder verlangen oder vielleicht Geld überweisen, und Sie müssen alle diese Anfragen im Batch-Modus bearbeiten Es gibt einige Compliance-Anforderungen, die Sie vor dem nächsten Werktag erledigen müssen. Da Sie also immer mehr davon erhalten, müssen auch Ihre anderen Stapelverarbeitungsanwendungen skalierbar sein. Es sind also nicht nur diese Anwendungen. Alle anderen Anwendungen, die nur viele Transaktionen in einer komprimierten Zeit verarbeiten müssen, wobei diese komprimierte Zeit in diesen Fällen Transaktionen pro Sekunde beträgt und diese komprimierte Zeit in diesem Fall innerhalb dieser Compliance-Anforderungen liegen könnte. Wenn Sie also über eine dieser Anwendungen verfügen, die viel Datenverkehr oder viele Transaktionen erfordern, sind Sie bei uns genau richtig.
Skalierbarkeitsproblem
Wo liegt also das Skalierbarkeitsproblem? Warum führen wir überhaupt dieses Gespräch? Es liegt definitiv nicht an der Anwendungsebene, da lässt sich Ihre Anwendungsebene sehr gut skalieren, Sie haben einen Load Balancer und können immer mehr Server hinzufügen. Alles sieht sehr schön aus. Das Problem liegt wirklich in Ihrer Datenbank, Ihrem Datenspeicher. Und damit meine ich relationale Datenbanken oder Mainframe-Altdaten. Und Sie können diese nicht auf die gleiche Weise skalieren wie die Anwendungsebene. Der Grund dafür ist, dass die darin enthaltenen Daten nicht verteilt werden. Es liegt in der Natur der Datenbank, dass alles zusammengestellt werden muss. Und das Gleiche gilt für den Mainframe. Die Datenbank könnte also sehr schnell sein. Möglicherweise wird auf der Serverseite ein Speicher-Caching durchgeführt, die Skalierung ist jedoch nicht möglich NoSQL databases.
Obwohl dies einer der Gründe ist, warum Menschen es verwenden NoSQL Es geht um die Skalierbarkeit von Transaktionen, das andere um die Skalierbarkeit von Daten. Nehmen wir an, Sie haben Terabytes und Terabytes an Daten NoSQL ist dafür viel besser geeignet. Und der dritte Grund, warum die Leute es verwenden, ist, dass JSON-Dokumente diese Flexibilität des Schemas bieten. Aber, NoSQL databases sind nicht immer in der Lage, Ihnen zu helfen, und der Grund dafür ist, dass Sie Daten aus relationalen Datenbanken in eine verschieben müssen NoSQL database. Was ist, wenn Ihnen dies aus verschiedenen technischen und geschäftlichen Gründen nicht möglich ist? Einige der Daten müssen in Ihren relationalen Datenbanken und in Ihren alten Mainframe-Daten verbleiben. Obwohl, NoSQL databases sind großartig und wir haben eine NoSQL database das wir letztes Jahr selbst ins Leben gerufen haben NosDB, wie ich bereits erwähnt habe, aber sie werden Ihr Problem nicht lösen, es sei denn, Sie können Daten in sie einfügen. Wenn Sie also mit relationalen Datenbanken arbeiten müssen, müssen Sie das damit verbundene Skalierbarkeitsproblem lösen, und hier kommt ein verteilter Cache wirklich ins Spiel.
Verteilte Cache-Bereitstellung
Ein verteilter Cache ist im Wesentlichen ein verteilter In-Memory-Speicher.
Logischerweise liegt es nur zwischen der Anwendungsschicht und der Datenschicht. Physisch könnte es sich um eine Reihe separater VMs handeln oder sie könnten sich auf derselben Box befinden wie die Anwendung, oder ein Teil davon könnte hier sein, ein Teil davon könnte hier sein, und das sind die Dinge, über die wir sprechen werden. Aber logischerweise liegt es zwischen der Anwendungsschicht und der Datenbankschicht. Und das grundlegende Argument ist, dass Sie nicht so häufig auf die Datenbank zugreifen, wenn Sie Daten zwischenspeichern. Da Sie nicht auf die Datenbank zugreifen, wird diese nicht so stark ausgelastet, sodass es nicht zu einem Engpass kommt. In 80 % der Fälle können Sie zur Caching-Ebene wechseln und die Caching-Ebene weist nicht den Engpass auf, den eine Datenbank verursacht, da sie ebenfalls wie eine verteilt ist NoSQL database Eine Caching-Ebene wird ebenfalls verteilt. Es ist ein Schlüssel/Wert. Ein anderes Wort für einen verteilten Cache ist eigentlich In-Memory NoSQL Schlüsselwertspeicher, denn alles, was Sie in den Verteilungscache legen, ist ein Schlüssel und ein Wert, der Ihr Objekt ist. Wenn Sie das also tun, gehen Sie in 80 Prozent der Fälle hierher und in 20 Prozent der Fälle in die Datenbank. Bei diesen 20 Prozent handelt es sich größtenteils um Updates.
Es gibt natürlich einige Lesevorgänge, und diese Aktualisierungen werden auch schneller ausgeführt, da es keine Konkurrenz zu Lesetransaktionen gibt und dies keinen Engpass mehr darstellt. Warum? Denn ein verteilter Cache bildet einen Cluster aus zwei oder mehr Servern. Dies sind keine teuren Boxen, es handelt sich nicht um Boxen vom Typ Ihres Datenbankservers. Hierbei handelt es sich um typische Webserverkonfigurationen wie eine Box mit vier oder acht Kernen, nur mit viel Speicher. Viel bedeutet, dass wir unseren Kunden 16 bis 32 GB empfehlen. Einige unserer Kunden gehen auf mehr als 32, aber wir empfehlen fast nie, mehr als 64 zu gehen. Es ist besser, eine weitere Box hinzuzufügen, als mehr hier zu haben. Denn wenn Sie mehr Speicher hinzufügen, muss die Rechenleistung erhöht werden. Warum? Denn eine .NET-Anwendung verfügt über diese sogenannte Garbage Collection und je mehr Speicher Sie sammeln müssen, desto mehr Garbage Collector oder der GC muss arbeiten und die CPU wird in diesem Fall zu einem Engpass und Ihre Anwendung beginnt, Probleme zu haben. Der optimale Platz liegt also bei 16 bis 32 GB Arbeitsspeicher in diesen VMs oder physischen Boxen, und die meisten unserer Kunden verwenden hier VMs. Und etwa 8 Kerne als Hardwarekonfiguration und normalerweise zwei Netzwerkkarten, eine Netzwerkkarte ist für das Clustering und eine für die Kommunikation mit den Clients. Das Wort „Client“ bedeutet Ihren Anwendungsserver, es sind also nicht Ihre Clients. Es ist Ihr Anwendungsserver, der als Cache-Client fungiert.
Also mindestens zwei Cache-Server und dann ein Verhältnis von vier zu eins oder fünf zu eins zwischen der Anwendungsschicht und der Caching-Ebene. Und dieses Verhältnis basiert vor allem auf dem, was wir im Laufe der Jahre gesehen haben, und wir sind seit über zehn Jahren in diesem Bereich tätig. Wenn Sie hier mehr Server hinzufügen, um mehr Aktivität zu erzielen, dann sind es mehr als vier zu eins oder mehr Ein Verhältnis von fünf zu eins ergibt eine sehr gute Kapazität. Und natürlich fügen Sie aus einem von drei Gründen weitere Server hinzu. Entweder benötigen Sie mehr Speicher, weil Sie Speicherbedarf haben, wie wir gerade besprochen haben, oder Sie benötigen mehr Transaktionskapazität, weil Sie zunächst zwei Server hatten und hier so lange Boxen hinzugefügt haben, bis der Verwurf das Maximum erreicht hat. Wenn das in einer relationalen Datenbank passiert, stecken Sie fest. Du bist abgespritzt. In diesem Fall fügen Sie lediglich eine dritte Box hinzu, bis die Kapazität der dritten Box aufgebraucht ist, und fügen dann eine vierte hinzu und so und so weiter. Sie können hier also so viele Boxen haben, wie Sie möchten. Wir haben Kunden, die hier im Durchschnitt etwa fünf bis zehn Kartons haben, und einige unserer Kunden haben hier in der Anwendungsebene 40 bis 50 Kartons, und dann haben sie entsprechend. Bei einer Box mit zehn Servern oder einer Anwendungsschicht mit zehn Servern müssten Sie also etwa drei Server in der Caching-Ebene haben. So planen Sie also.
Das Ziel des bisherigen Vortrags besteht also darin, Sie davon zu überzeugen, dass Sie durch eine Caching-Ebene keinen Skalierbarkeitsengpass mehr haben. Unabhängig davon, welches Produkt und welche Caching-Lösung Sie verwenden, müssen Sie eine Caching-Ebene in Ihre Anwendung integrieren. Daher müssen Sie Ihre Anwendung so gestalten, dass Ihr Bild einen Cache enthält, damit es nie zu Engpässen kommt.
Anwendungsfälle von verteiltem Cache
Nachdem wir nun davon überzeugt sind, dass Sie als .NET-Entwickler den Cache verwenden sollten, stellt sich als nächstes die Frage, wo Sie ihn verwenden sollten. Wie sollten Sie es verwenden?
Und der erste Anwendungsfall ist das Zwischenspeichern von Anwendungsdaten, über das ich bisher gesprochen habe. Das heißt, Sie haben Anwendungsdaten in einer Datenbank und speichern sie hier zwischen, sodass Sie nicht in die Datenbank gehen müssen, genau das Gleiche .
App-Daten-Caching
Das Einzige, was Sie bei diesem Anwendungsfall beachten sollten, ist, dass die Daten jetzt an zwei Orten vorhanden sind: einer im Master, also der Datenbank, und einer im Cache, also nicht am anderen Ort. Was würde also schiefgehen, wenn Ihre Daten an zwei Orten vorhanden wären? Wenn Sie zwei Kopien davon haben, besteht die größte Sorge darin, ob der Cache aktuell ist und ob der Cache dieselbe Datenversion wie die Datenbank haben wird. Denn wenn der Cache nicht dieselbe Datenversion haben wird, dann sind Sie es wird gezwungen, schreibgeschützte Daten zwischenzuspeichern. Und schreibgeschützte Daten machen etwa 10–15 Prozent Ihrer Gesamtdaten aus. Sie profitieren also nicht wirklich davon. Sie profitieren, aber nicht in dem Maße, wie Sie sollten, um Ihre Anwendung wirklich skalierbar zu machen.
Tatsächlich ist es so, dass man einen Durchschnittsmenschen fragt, wofür ein Cache verwendet wird. Sie würden sagen: Nun, ich werde einfach meine schreibgeschützten Daten darin ablegen. Jeder hat Angst davor, Transaktionsdaten zwischenzuspeichern. Ihre Kunden, Ihre Konten oder Aktivitätsdaten, die sich alle 30 Sekunden, jede Minute, alle fünf Minuten oder auf unvorhersehbare Weise ändern. Aus diesem Grund haben die Leute Angst, das zwischenzuspeichern, weil es zwei Kopien davon gibt und was passiert, wenn der Cache nicht weiß, dass Sie es in der Datenbank geändert haben. Denken wir also daran, wenn wir weitermachen.
ASP.NET-spezifisches Caching
Der zweite Anwendungsfall ist, wenn Sie über eine ASP.NET-Anwendung verfügen. Der bekannteste ist der Sitzungsstatus. Und das ist auch alles in diesem Beispiel. Das erste Beispiel ist der Sitzungsstatus. Bei Sitzungen stehen Ihnen standardmäßig zwei Speicheroptionen zur Verfügung. Das eine ist InProc, das andere ist SQL, das Microsoft bereitstellt. Auf einem lokalen Server gibt es auch einen Statusserver, aber bei allen drei Optionen gibt es Skalierbarkeitsprobleme. Der SQL Server hat Leistungsprobleme. Aus dem gleichen Grund, warum wir zunächst kein Caching haben werden. Wenn Sie Sitzungen in SQL speichern, werden sie als Blobs gespeichert. Die Beziehung ist SQL, wie alle relationalen Datenbanken, die nicht für die Blob-Speicherung konzipiert wurden, sondern für strukturierte Daten. Es funktioniert also nicht. Es gibt viele Probleme. Die meisten unserer Kunden, wenn sie dorthin gehen NCache, der erste Anwendungsfall ist der Sitzungsstatus. Das liegt daran, dass das ihren unmittelbaren Nutzen bringt. Und das wirklich Schöne am Sitzungsstatus ist, dass keine Programmierung erforderlich ist, da Microsoft ein Framework bereitstellt, das einen Drittanbieter-Cache ermöglicht NCache einstecken und alles, was gerade hier ist, wird im Cache gespeichert.
Der andere Aspekt von ASP.NET besteht darin, dass es einen sogenannten Ansichtsstatus gibt, wenn Sie nicht über das MVC-Framework verfügen und sich im Pre-MVC-Framework befinden, was bei vielen ASP.NET-Anwendungen immer noch der Fall ist. Und für diejenigen unter Ihnen, die nicht wissen, was der Ansichtsstatus ist: Es handelt sich um eine verschlüsselte Zeichenfolge, die von Ihrem Webserver an den Browser gesendet wird, um dann bei einem Post zurück zurückgebracht zu werden. Es könnten also Hunderte von Kilobyte verschlüsselter Stärke sein, die einfach hin- und hergehen. Und wenn Sie das mit den Millionen von Transaktionen multiplizieren, die Ihre Anwendung verarbeiten wird, ist das mindestens eine Menge Bandbreite. Und die Bandbreite ist nicht kostenlos, sondern ziemlich teuer.
Und zweitens ist natürlich die Antwortzeit langsamer, wenn Sie eine so große Nutzlast an Ihre Leistung senden müssen. Es wäre also viel schöner, wenn Sie einfach den Ansichtsstatus auf der Serverseite zwischenspeichern und einen kleinen Schlüssel senden könnten. Wenn also die Rücksendung erfolgt, kommt der Schlüssel zurück und der Ansichtsstatus wird aus dem Cache abgerufen und angezeigt zur Seite. Das ist also der zweite Anwendungsfall. Auch hier ist kein Programmieraufwand erforderlich, Sie schließen einfach einen Cache eines Drittanbieters an NCache.
Der dritte Anwendungsfall ist der ASP.NET-Ausgabecache. Dieser Cache ist die Seitenausgabe. Wenn sich die Seitenausgabe nicht ändert, verfügt Microsoft bereits über ein Framework, das sie in einem lokalen eigenständigen InProc zwischenspeichert. Es ist besser, stattdessen einen dritten verteilten Cache einzubauen, damit in einer Webfarm beim ersten Zwischenspeichern einer Seitenausgabe diese für die gesamte Webfarm verfügbar ist, anstatt dass jeder Webserver seine eigene Kopie zwischenspeichert.
Das sind also die drei Anwendungsfälle für ASP.NET-Anwendungen zusätzlich zum Anwendungsdaten-Caching.
Nun ist die Natur des Problems hier eine völlig andere. In diesem Fall hatten Sie zwei Kopien der Daten. Hier ist der Cache der Masterspeicher. Sie speichern also keine Sitzungen mehr in der Datenbank. Sie speichern den Ansichtsstatus nirgendwo mehr mehr. Der Cache ist also der Master-Speicher und ein In-Memory-Speicher. Was kann also schiefgehen, wenn ein In-Memory-Store ein Master-Store ist? Erinnerung ist flüchtig! Ja. Es gibt also keine Beharrlichkeit. Ein guter verteilter Cache muss also Daten über mehrere Server replizieren, um Datenzuverlässigkeit zu gewährleisten, damit diese Sitzung nicht verloren geht. Denn vielleicht sind Sie eine Fluggesellschaft und haben diese spezielle Wochenendaktion für Hawaii durchgeführt, und Sie haben zwei- oder dreimal so viele Besucher auf Ihrer Website, und das sind Leute, die alle möglichen Suchanfragen durchgeführt haben, und das werden sie auch tun Klicken Sie auf die Schaltfläche „Senden“ und sie verlieren ihre Sitzung. Sie können diesen Kunden verlieren, wenn jeder Kunde Tausende von Dollar Umsatz macht. Sie möchten die Sitzung also auf keinen Fall verlieren. Legen Sie also keine Sitzungen in einem Cache ab, es sei denn, dieser führt eine Replikation durch.
Gemeinsame Nutzung von Laufzeitdaten
Der dritte Anwendungsfall ist die gemeinsame Nutzung von Laufzeitdaten. Das ist etwas, was viele Menschen lange Zeit nicht wussten. Benutzer verwenden Nachrichtenwarteschlangen, um Ereignisse über mehrere Anwendungen hinweg zu teilen. Aber ein verteilter Cache bietet Ihnen einen sehr einfachen und leistungsstarken datenorientierten Ereignismechanismus, bei dem Sie sich das jetzt wie einen Servicebus oder einen Nachrichtenbus vorstellen können, denn das sind Ihre Anwendungen, die darüber miteinander kommunizieren können. Anstatt also MSMQ oder RabbitMQ zu verwenden, die ihre eigenen Vorteile haben, ist ein Cache nicht dazu da, sie zu ersetzen. Wenn es bei Ihrem Bedarf jedoch mehr um Daten oder um Messaging geht, und zwar mehr um Daten und innerhalb desselben Rechenzentrums, bietet Ihnen ein verteilter Cache eine einfachere Schnittstelle, aber was noch wichtiger ist, er ist skalierbarer. Wenn Sie also eine höhere Transaktionsanwendung haben, geht es bei dieser ganzen Diskussion um Skalierbarkeit.
Obwohl Sie all diese Dinge mit diesen regulären Nachrichtenwarteschlangen erledigen könnten. Wenn Sie sich in einer Umgebung mit sehr vielen Transaktionen befinden, werden diese nicht auf die gleiche Weise verteilt wie ein verteilter Cache. Ein verteilter Cache ermöglicht Ihnen also all dies. Nehmen wir an, es gibt eine Datenfreigabe vom Pub/Sub-Typ, es gibt Ereignisbenachrichtigungen und eine kontinuierliche Abfragefunktion NCache hat, was auch Java-Caches haben, das Redis Dies ist nicht der Fall, mit dem Sie Daten einfach und nahtlos zwischen Anwendungen austauschen können. Und auch hier ähnelt das Problem der Verwendung des ASP.NET-spezifischen Cachings, da diese Daten zwar wahrscheinlich in einer Datenbank vorhanden sind, aber nicht in der Form, in der Sie sie teilen.
Sie haben es also wahrscheinlich in ein Formular umgewandelt, bevor Sie versuchen, es freizugeben, sodass das transformierte Formular im Cache gespeichert wird. Da Sie diese Daten nicht verlieren möchten, muss ein Cache die Daten replizieren. Eigentlich sogar für das Caching von Anwendungsdaten, obwohl dies technisch gesehen möglich ist, wenn Sie einige Daten verlieren, weil ein Cache-Server ausfällt und Sie nicht repliziert haben. Sie könnten diese Daten technisch gesehen aus der Datenbank neu laden. Es gibt kein Problem, außer es gibt einen Leistungseinbruch, denn wie auch immer, wenn Sie 16 GB Daten verloren haben, müssen Sie jetzt 16 GB Datenbanktreffer durchmachen, was Sie nicht tun möchten. Daher entscheiden sich die meisten unserer Kunden, auch beim Zwischenspeichern von Anwendungsdaten, für die Replikation, weil der Speicher so günstig ist. Sie wollen diesen Leistungseinbruch gar nicht erst hinnehmen. Bei diesen beiden muss man es natürlich haben, aber bei diesem hier ist es irgendwie gut, es zu haben.
Hands-on-Demo
Okay, bevor wir mit der Vorgehensweise fortfahren, möchte ich Ihnen zunächst zeigen, wie ein Cache aussieht. Ich werde es verwenden NCache wie das Beispiel hier.
Einrichten einer Umgebung
Ich habe also in Azure drei VMs, Demo1, Demo2 und Demo-Client. Demo1 und 2 werden meine Cache-Server-VMs sein und Demo-Client ist meine Anwendungsserver-VM. Nehmen wir in Ihrem Fall an, Sie haben zwei Cache-VMs und dann ein Verhältnis von vier zu fünf, vier zu eins oder fünf zu eins der Client-VMs.
Ich bin also beim Demo-Client angemeldet und werde dieses Tool verwenden NCache hat genannt NCache Manager. Also, ich habe es hier angefangen. Ich werde hierher kommen und sagen: Erstellen Sie einen neuen Cluster-Cache.
Erstellen Sie einen geclusterten Cache
Alle Caches drin NCache benannt sind, also werde ich es einfach Democache nennen. Ich werde nicht näher darauf eingehen, was die einzelnen Elemente bedeuten. Ich werde gleich darauf eingehen, aber ich werde einen auswählen Partitionierte Replikattopologie. Im Falle von NCacheEine Topologie bedeutet, wie werden die Daten gespeichert und repliziert? Eine partitionierte Replikat-Topologie ist etwas, das ... wenn ich hierher zurückkommen würde, stellen Sie sich das als einen Cache-Cluster mit zwei Knoten vor, der erstellt werden würde.
Wenn es sich um eine partitionierte Replik handelt, verfügt jeder Server über eine Partition. Es wird also insgesamt zwei Partitionen geben. Im Falle von NCache, der gesamte Cache verfügt über etwa tausend Buckets, sodass etwa die Hälfte davon in Partition eins und die andere Hälfte in Partition zwei gehen.
Jede Partition wird auf einem anderen Server gesichert, der als Replikat bezeichnet wird. Die Replik im Falle von NCache ist passiv, was bedeutet, dass kein Client mit den Replikaten kommuniziert, sondern nur die Partition mit den Replikaten. Und das Replikat wird nur dann aktiv, wenn seine primäre Partition ausfällt oder wenn die Partition ausfällt.
Das heißt, wenn dieser Server ausfällt, wenn wir einen Cluster mit drei Knoten und eine Partition hätten, sagen wir, Server drei ist ausgefallen, Partition drei ist jetzt ausgefallen. Replikat drei wird also automatisch zu Partition drei, sodass Sie keine Daten verlieren. Partitionierte Replikate bieten Ihnen also diese Speicher- und Replikationsstrategien. Es sagt Ihnen im Wesentlichen, dass Daten repliziert werden müssen. Es gibt auch eine synchrone und eine asynchrone Replikation. Wie auch immer, ich komme darauf zurück, aber ich wollte Ihnen nur zeigen, was das bedeutet. Daher werde ich eine asynchrone Replikation zwischen der Partition und den Replikaten auswählen. Dann gebe ich meinen Cache-Server an, also ist der erste demo1, der zweite demo2. Nun, alles, was ich für den Fall sage NCache, Sie können es vollständig skripten, sodass es automatisiert werden kann. Ich belasse alle Standardeinstellungen. Das ist der TCP-Port, auf dem sich die Cache-Cluster gebildet haben. Ich werde angeben, wie viel Speicher der Cache auf diesem Server verwenden soll, und der Cache wird nicht mehr als diesen Speicher verwenden. Also, was auch immer ich hier spezifiziere, ist dieses Mal zwei, weil. Es gibt eine Partition und eine Replik.
Das ist also die Größe einer Partition. In Ihrem Fall wird es also natürlich viel mehr sein, denn wenn Sie 16 GB auf einem Cache-Server haben, sollten Sie etwa 2 bis 2.5 GB für das Betriebssystem und andere Prozesse übrig lassen und den Rest reservieren. Nehmen wir also an, von 16 Gigabyte bleiben noch 13 Gigabyte übrig, aber 13 geteilt durch 2 wäre eine Partitionsgröße und dann NCache stellt sicher, dass nicht mehr als dieser Speicher belegt wird. Wenn also so viel Speicher verbraucht wird, gilt der Cache als voll NCache. Und dann NCache hat eine von zwei Möglichkeiten. Erstens, das merkt man NCache wird alle neuen Hinzufügungen der Daten ablehnen, bis einige der Daten automatisch ablaufen, oder Sie können eine sogenannte Räumung durchführen. Also, NCache bietet Ihnen drei Räumungsalgorithmen: LRU, LFU und Prioritäts-FIFO. In diesem Fall können Sie also sagen: 5 % des Caches entfernen.
Nun möchte ich ein wenig darüber sprechen, und zwar im Zusammenhang mit: Nehmen wir an, Sie speichern in jedem einzelnen Anwendungsfall Hier. Wenn Sie Anwendungsdaten zwischenspeichern, ist die Räumung vollkommen in Ordnung. Es gibt keine Probleme. Sie haben gerade den Speicher aufgebraucht, indem Sie einige der am wenigsten genutzten Daten entfernt und dann Platz für neue Daten geschaffen haben. Es wird also wie ein bewegliches Fenster, oder? Wenn Sie also immer mehr Daten verwenden, wird das ältere entfernt und das neue entfernt. Das wird also am häufigsten verwendet. Aber was ist, wenn es eine Sitzung ist? Wenn der Cache zum Speichern von Sitzungen verwendet wird, sind keine Räumungen erforderlich. Warum willst du die Räumung nicht? Denn die Sitzung ist möglicherweise noch aktiv. Es kann sein, dass die 20 Minuten oder was auch immer Ihre Zeitüberschreitung ist, nicht durchgehalten wurden. Wenn dies der Fall ist und Sie die Sitzung trotzdem entfernen, erzwingen Sie das gleiche Problem, über das wir gerade gesprochen haben, nämlich dass sich ein Benutzer nicht abgemeldet hat, Sie aber die Sitzung beenden. Was Sie also tun müssen, ist, Ihre Kapazitätsplanung durchzuführen. Im Falle von NCache, können Sie das ganz einfach machen, sehen, wie viel Speicher eine durchschnittliche Sitzung verbraucht, und dann Ihre Kapazitätsplanung durchführen. Extrapolieren Sie, wie viel Speicher verwendet wird. Sorgen Sie dafür, dass dieser andere Sitzungsspeicher niemals geräumt wird. Der Anwendungsdatenspeicher oder Anwendungsdaten-Cache kann problemlos gelöscht werden. Der Sitzungscache sollte jedoch nicht geräumt werden. Es sollte nur dann ablaufen, wenn der Benutzer die Sitzung nicht mehr nutzt.
Ich sage also einfach „Fertig stellen“ und schon habe ich einen Cache-Cluster mit zwei Knoten. Ich werde hierher kommen und einen Client-Knoten hinzufügen. In meinem Fall habe ich, wie gesagt, nur einen Client-Knoten. Ich glaube, ich habe den Cache wahrscheinlich nicht, also haben wir angefangen. Ich brauche diesen Service also NCache Der Manager kann mit diesem sprechen und die Konfiguration vornehmen. Okay! Nachdem ich das nun getan habe, werde ich hierher kommen und sagen: „Cache starten“. Wenn Sie nun den Cache starten, NCache baut einen Cluster zwischen diesen beiden Boxen auf, zu diesem TCP.
Stress simulieren und Cache-Statistiken überwachen
Damit Sie dann nicht wirklich auf die Details eingehen, welche Boxen welche Daten enthalten und ob es sich um einen Cluster handelt. Sie wissen nur, dass es einen Democache gibt. Wenn Sie eine Verbindung zu diesem Cache herstellen, stellt Ihre Anwendung bei partitionierten Replikaten automatisch eine Verbindung zu allen Servern her. Also, NCache kümmert sich um alle Details und ich werde hierher kommen und sagen: Statistiken anzeigen und das sind einige PerfMon-Zähler, damit Sie sehen können, was NCache reicht aus, aber sobald Sie anfangen, es zu verwenden. Ich werde auch dieses Tool namens starten NCache Monitor. Und es ist wie ein Tool im Dashboard-Stil. Und im Falle von NCachehaben Sie die Möglichkeit, ein Stresstest-Tool zu nutzen, mit dem Sie Ihre Anwendungsnutzung sehr schnell und ohne Programmieraufwand simulieren können.
Ich sage zum Beispiel Stresstest-Tool Democache, also reicht es aus, einen Putt zu bekommen und solche Sachen. Und plötzlich werden Sie sehen, dass dieses Tool mit beiden Cache-Servern kommuniziert und auf jeder Box etwa 700 Anfragen pro Sekunde ausführt, etwa 7 bis 800, sogar bis zu tausend. Nehmen wir an, ich möchte die Last erhöhen. Deshalb möchte ich ein weiteres Stresstest-Tool einführen.
Dies ist so, wie Sie es auch mit Ihrer Bewerbung tun würden. Ich meine, wenn Sie Ihre Anwendung testen möchten, führen Sie Ihre Anwendung mit einem Stresstest-Tool aus und fügen dann immer mehr Stress hinzu und dann möchten Sie sehen, ob das gesamte System funktioniert. Im Moment testen Sie also nur die Cache-Komponente. Die meisten unserer Kunden tun, was sie tun, wenn sie bewerten NCache, sie führen dieses Benchmarking durch. Sobald sie also alles in ihrer Umgebung konfiguriert haben, tun sie dies nicht, obwohl wir unsere Benchmarks veröffentlicht haben. Ich meine, sie überprüfen alles in ihrer eigenen Umgebung. Wenn Sie also immer mehr davon hinzufügen, werden Sie feststellen, dass sich diese Menge gerade verdoppelt hat.
Lassen Sie mich noch ein Stresstest-Tool vorstellen. Du wirst sehen, dass es immer weiter steigt. Genau dort, sehen Sie! Ich kann also immer mehr Stresstest-Tools hinzufügen, bis ich entweder die CPU meines Clients voll ausgelastet habe. Ich habe also auf meinem Anwendungsserver etwa 50 Prozent erreicht. Ich kann also definitiv weitere Stresstest-Tools hinzufügen. Sobald ich die maximale Anzahl an Clients erreicht habe, füge ich einen weiteren Client hinzu. So kann ich es also. So erledigen wir beispielsweise bereits jetzt etwa 5,000 Anfragen pro Sekunde mit nur drei Stresstest-Tools. Also, mit diesem und dann können Sie hier zum Beispiel auch all diese Dinge überwachen. Damit können Sie tatsächlich sehen, wie ein Cache aussieht. Lassen Sie uns nun aus der Entwicklerperspektive näher darauf eingehen.
ASP.NET-spezifisches Caching
Nachdem Sie nun wissen, wie ein Cache aussieht, sehen wir uns nun an, wie Sie diesen Cache in Ihrer Anwendung verwenden. Für ASP.NET sollten Sie also, wie gesagt, als Erstes den Cache für Sitzungen verwenden. Warum? Weil es am einfachsten ist. Es gibt keine Programmierung, es gibt keinen Aufwand dafür. Ich habe Ihnen gerade gezeigt, wie schnell Sie einen Cache mit Interesse konfigurieren können NCacheNehmen wir an, wenn ich hierher käme und auf einige der Beispielcodes eingehen würde, hätten sie bereits geöffnet sein sollen, aber das tue ich nicht. Hier ist also eine ASP.NET-Anwendung, die Sie verwenden können NCache mit ASP.NET für Sitzungen. Sie müssen einfach web.config ändern. Also, ich habe die web.config. Das erste, was Sie tun müssen, ist, dieses Fließband bei der Montage hinzuzufügen. NCache, dieser Sitzungsspeicheranbieter ist NCache Assembly, die die ASP.NET-Sitzungsspeicheranbieterschnittstelle implementiert hat. Das ist es also, was erlaubt NCache zum Einstecken. Sie können also einfach die Zeile hierher kopieren und gelangen dann zum Sitzungsstatus-Tag, das sich genau hier befindet. Im Falle von NCache, du kopierst einfach dieses Tag. Stellen Sie sicher, dass dieser Modus benutzerdefiniert ist, da dies die Einbindung des Drittanbieter-Cache ermöglicht. Das Timeout ist das, was Sie möchten, und dann das Einzige, was Sie für den Fall benötigen NCache dient dazu, sicherzustellen, dass der Cache-Name angegeben wird.
Also, sobald Sie installiert haben NCache Anschließend installieren Sie auf den Cache-Servern den Serverteil und auf dem Anwendungsserver den Clientteil NCache, Sie erstellen den Cache wie wir es gerade getan haben, aktualisieren diesen und das ist alles. Das ist der ganze Aufwand, den Sie brauchen, um mit der Nutzung zu beginnen NCache und dann ist jede Sitzung ein Objekt im Cache. Wenn Sie dies in diesem PerfMon-Zähler tun, sehen Sie, wie viele Sitzungen Sie sehen. Normalerweise erstellen unsere Kunden drei Caches. Wir haben hier also nur einen Cache erstellt, oder? Unsere Kunden werden also drei Caches erstellen. Einer der Caches ist für Sitzungen. Sie verfügen also über einen separaten Cache für Sitzungen. Einer der Caches und zwei Caches sind für Anwendungsdaten vorgesehen. Eines davon nennt man Referenzdaten. Das andere sind die Transaktionsdaten. Transaktionsdaten ändern sich sehr häufig. Und der Grund, warum sie das tun, sind einige der anderen Funktionen, auf die ich näher eingehen werde. Auf denselben VMs können Sie jedoch mehr als einen Cache erstellen. Das ist also alles, was Sie für die Speicherung des Sitzungsstatus tun müssen. Es ist ganz einfach, es ist keine Programmierung erforderlich, und schon kann es losgehen.
App-Daten-Caching
Wenn Sie jedoch Anwendungsdaten zwischenspeichern möchten, bietet EF Core im .NET-Bereich nun leider endlich eine Architektur, in die Sie einen Drittanbieter-Cache einbinden können.
NCache unterstützt es auch. Aber bis EF6 einschließlich EF6 unterstützte die Architektur das Einbinden eines Drittanbieter-Cache nicht wirklich. NHibernate unterstützte diese Architektur lange Zeit. Also für NHibernate NCache Kann ohne Programmierung angeschlossen werden. Selbst beim Zwischenspeichern von Anwendungsdaten mit minimalen Funktionen können Sie also einfach auf API-Aufrufe verzichten. Aber zum größten Teil muss man dort mental auf das Zwischenspeichern von Anwendungsdaten vorbereitet sein, man muss programmieren. Aber es ist eine sehr einfache API. Diese API sieht einem ASP.NET-Cache-Objekt sehr ähnlich. Sie verbinden sich mit dem Cache über einen Cache-Namen.
Lassen Sie mich Ihnen kurz zeigen, wie das aussieht. Lassen Sie mich öffnen ... Ich bin auf einige Azure-VM-Probleme gestoßen. Ich fange diese anderen Dinge an, alles offen. Nehmen wir an, ich habe diese wirklich einfache Konsolenanwendung. Als erstes müssen Sie zwei davon verknüpfen NCache Versammlungen, eine ist NCache.Runtime, das andere ist NCache.Netz. NCache.Web ist die eigentliche API, die Sie aufrufen. Dann verknüpfen Sie diese beiden oder Sie verwenden diese beiden Namensräume erneut NCache.Runtime und dann .Web.Caching. Zu Beginn Ihrer Anwendung stellen Sie anhand eines Namens eine Verbindung zum Cache her und erhalten ein Cache-Handle, genau wie für die Datenbank. Natürlich werden Sie dies in einer ASP.NET-Anwendung wahrscheinlich in global.ASAX beim Anwendungsstart oder in der InIt-Methode tun. Dann erstellen Sie einfach Ihr Objekt und führen Cache.Add aus. Das Cache.Add verwendet einen Schlüssel, eine Art Zeichenfolge. Das ist kein guter Schlüssel, Ihr Schlüssel muss viel spezifischer sein und dann ist hier Ihr Objekt und das war's. Sie machen diesen Anruf und hinter den Kulissen läuft nun alles ab. Nehmen wir an, wenn Sie diese partitionierte Replikat-Topologie hätten, würde Ihre Anwendung verbunden sein. Jede Box ist also mit allen Cache-Servern verbunden. Sie haben also gerade einen Cache.Add erstellt, oder? Cache.Add schaut sich also die Verteilungskarte an, die der Bucket-Karte ähnelt. Jeder Bucket verfügt über einen Schlüsselwertebereich im Sinne eines Hash-Schlüsselwertebereichs im Hinblick darauf, welche Schlüssel in diesen Bucket aufgenommen werden können. Es wird also diese Bucket-Map verwenden, um zu wissen, mit welchem Server es kommunizieren soll, weil es mit allen verbunden ist, oder?
Nehmen wir an, Sie fügen hier Element Nummer drei hinzu. Hier wird Element Nummer drei hinzugefügt. Wenn Sie die asynchrone Replikation aktiviert haben, kehrt die Anwendung zurück und die Anwendung ist abgeschlossen. Der Cache erkennt nun, dass diese Partition weiß, dass sie dies hier replizieren muss. Dies wird also in einem Massenvorgang asynchron auf die andere Box repliziert und Sie haben dieses Element sofort an zwei Orten. Das ist es also, was Cache.Add im Verborgenen getan hat.
Okay, ich gehe hin und her, weil ich Ihnen nur einen Überblick geben wollte, wie ein Cache aussieht, wie man ihn erstellt, wie eine API aussieht.
App-Daten-Caching-Funktionen
Lassen Sie uns nun auf die Probleme eingehen, die Sie bei der Verwendung des Caches für das Zwischenspeichern von Anwendungsdaten lösen müssen.
Halten Sie den Cache frisch
Wir haben darüber gesprochen, den Cache frisch zu halten, oder? Wie hält man den Cache also frisch? Wie stellen Sie sicher, dass ein Cache frisch ist?
Die gebräuchlichste und die, die jeder unterstützt, einschließlich Redis ist Ablauf. Der absolute Ablauf. Wenn Sie also beispielsweise etwas zum Cache hinzufügen, geben Sie auch hier ein Ablaufdatum an, das heißt, Sie sagen, dass es nach einer Minute ablaufen soll. Wenn Sie dies im Falle von sagen NCache, NCache erstellt Indizes auf dem Server, überwacht diese Daten und verfällt nach einer Minute. Tatsächlich wird also ein absoluter Datums-/Uhrzeitwert angegeben, der eine Minute in der Zukunft liegt. NCache weiß, dass der Artikel an diesem Tag ablaufen muss. Auf diese Weise sorgt der Cache automatisch dafür, dass Daten entfernt werden. Und was bedeutet das wirklich? Das bedeutet, dass Sie dem Cache mitteilen, dass es mir wirklich unangenehm ist, diese Daten länger als eine Minute oder länger als fünf Minuten aufzubewahren, weil ich glaube, dass jemand sie in der Datenbank ändern wird. Daher ist es nur sicher, es so lange im Cache zu behalten. Es gibt noch einen anderen Ablauf, den sogenannten gleitenden Ablauf, der ähnlich klingt, aber einen völlig anderen Zweck hat. Der Schiebeablauf dient hauptsächlich der Reinigung. Wenn Sie also Sitzungen haben, verwenden Sie den gleitenden Ablauf, um aufzuräumen, nachdem niemand diese Sitzung verwendet. Wenn sich also jemand nach 20 Minuten Inaktivität abmeldet, gilt die Sitzung als abgelaufen. Es wird also automatisch entfernt.
Verwenden von DatenbankabhängigkeitenDas hat jedoch nichts damit zu tun, den Cache frisch zu halten. Der absolute Ablauf ist derjenige, der den Cache frisch hält. Es gibt jedoch ein großes Problem mit dem absoluten Ablauf. Und das Problem besteht darin, dass Sie vermuten, dass es sicher ist, die Daten dafür so lange im Cache zu behalten, und dass diese Schätzung nicht immer korrekt ist. Was also tun Sie in diesem Fall? Dann muss in diesem Fall die Möglichkeit bestehen, dass sich der Cache selbst synchronisiert. Wenn eine Änderung in der Datenbank festgestellt wird, muss der Cache wissen, um welche Datenbank es sich handelt. Das bedeutet, dass der Cache eine Beziehung zwischen dem zwischengespeicherten Element und etwas an einigen Daten in der Datenbank haben muss, die Sie dem Cache mitteilen müssen, und dort gibt es in ADO.NET diese sogenannte SQL-Cache-Abhängigkeit NCache verwendet, was eine SQL-Abhängigkeit ist, die auch Oracle-Abhängigkeit genannt wird, was eigentlich auf sehr einfache Weise funktioniert. Aber es ist eine wirklich leistungsstarke Funktion. Und wir kommen hierher. Ich werde einfach die SQL-Abhängigkeit verwenden. Wenn Sie also etwas zum Cache hinzufügen, machen Sie dasselbe Cache.Add, oder? Sie haben einen Cache-Schlüssel. Anstelle des Werts geben Sie nun das Cache-Element an NCacheist eine eigene Datenstruktur und enthält dort den Wert, aber auch diese sogenannte SQL-Cache-Abhängigkeit.
Diese SQL-Cache-Abhängigkeit ist NCacheist eine eigene Klasse, die jedoch der ADO.NET SQL-Cache-Abhängigkeit zugeordnet ist. Beachten Sie, dass es hier eine Verbindungszeichenfolge und dann eine SQL-Anweisung gibt. In diesem Fall ist die SQL-Anweisung also eine Zuordnung zu einer Zeile in der Produkttabelle. Also, was passiert hier wirklich? Ich meine, Sie führen diesen Code tatsächlich genau hier aus. Ihre Datenbank ist hier, also fordern Sie den Cache-Cluster auf, sich jetzt mit der Datenbank zu verbinden, basierend auf der Verbindungszeichenfolge, die Sie ihm gerade übergeben haben, basierend auf dieser Verbindungszeichenfolge, und Sie übergeben den SQL-Server und sagen „Bitte“. Verbindung mit meiner SQL-Server-Datenbank herstellen. Und überwachen Sie den SQL-Server, um Sie als Cache-Server zu benachrichtigen, wenn an diesem Datensatz Änderungen vorgenommen werden. Das heißt, ob diese Zeile entweder aktualisiert oder gelöscht wird. In diesem Fall sendet der SQL-Server eine Datenbankbenachrichtigung an den Client, der in diesem Fall der Cache-Server ist. Einer von diesen. Und was macht dann der Cache-Server? Der Cache-Server entfernt dieses Element aus dem Cache. Das Entfernen bedeutet, dass Ihre Anwendung gezwungen ist, es aus der Datenbank abzurufen, die jetzt über die neueste Kopie verfügt, da es sich nicht mehr im Cache befindet. Auch wenn das Ablaufdatum eine fundierte Vermutung ist, ist dies keine Vermutung. Hierbei handelt es sich um eine tatsächlich vorhersehbare Synchronisierung, bei der sichergestellt wird, dass der Cache immer mit der Datenbank konsistent ist.
Nun, im Falle von NCache, es gibt drei verschiedene Möglichkeiten, dies zu tun. Eine davon ist die SQL-Abhängigkeit, die Datenbankereignisse verwendet, was einer Echtzeit ähnelt. Der Andere ist NCaches eigene DB-Abhängigkeit, die er Polling verwendet, und zwar für Datenbanken, die keinen Ereignisbenachrichtigungsmechanismus haben, oder sogar für SQL Server, wenn Sie der Meinung sind, dass Sie zu viele SQL-Abhängigkeiten haben und für jede SQL-Abhängigkeit eine SQL-Cache-Abhängigkeit erstellt wird SQL Server, eine zusätzliche Datenstruktur. Stellen Sie sich vor, Ihr SQL-Server würde ersticken, wenn Sie Hunderttausende davon erstellt hätten. Daher ist es möglicherweise keine gute Idee, diese Art der Synchronisierung zu verwenden, wenn Sie viele SQL-Abhängigkeiten haben. Dann ist vielleicht die DB-Abhängigkeit viel besser, wenn sie in einem Aufruf Tausende von Zeilen synchronisieren kann, weil sie über eine Abfragetabelle verfügt, die sie überwacht.
Und es gibt eine dritte Möglichkeit, die darin besteht, einfach eine gespeicherte CLR-Prozedur zu schreiben und sie von Ihrem Trigger aufrufen zu lassen. Wenn Sie also über einen Update-, Insert-, Update- oder Delete-Trigger verfügen, rufen Sie diese CLR-Prozedur auf. Und die CLR-Prozedur entnimmt die Daten aus dieser Zeile, erstellt das .NET-Objekt, das Ihre Anwendung verwendet, und speichert es im Cache. Hier ist eine asynchrone API sehr nützlich, da Sie nicht innerhalb der Datenbanktransaktion auf die Aktualisierung eines Caches warten möchten. Es verlangsamt lediglich die Datenbanktransaktionen, bei denen es sehr schnell zu Zeitüberschreitungen kommt. Daher ist es wirklich ratsam, dass Sie bei der Implementierung dieses Mechanismus die asynchronen Methoden verwenden, um die Daten zu aktualisieren.
Das sind also die drei Möglichkeiten, wie Sie den Cache synchronisieren können. Diese Funktion ist wirklich wichtig, da Sie so sicherstellen können, dass der Cache immer aktuell ist, ohne dass Sie nur Vermutungen anstellen. Und auf die gleiche Weise können Sie den Cache mit nicht relationalen Datenbanken synchronisieren. Es gibt eine benutzerdefinierte Abhängigkeitsfunktion NCache hat, was dein Code ist NCache Aufrufe, mit denen Sie Ihren benutzerdefinierten Datenspeicher überwachen können. Ihre benutzerdefinierte Datenquelle könnte ein Cloud-Speicher sein. Es könnte alles sein, es ist einfach ein beliebiger Code, den Sie überprüfen können. Daher ist es wirklich wichtig, den Cache aktuell zu halten, und auf diese Weise können Sie dies sicherstellen.
Durchlesen und Durchschreiben
Die nächste Funktion ist also das Durchlesen und Durchschreiben.
Beim Durchlesen handelt es sich im Grunde wieder um Ihren Code. Nun, all diese Funktionen, über die ich spreche NCache hat sie, aber sie sind es nicht NCache nur. Java-Caches haben sie alle. Redis kann sie haben oder auch nicht. Das ist es also, was Sie tun müssen, wenn Sie es im Detail machen wollen, wenn Sie wissen wollen, ob was Redis hat oder nicht, im Falle von NCache Kommen Sie einfach hierher und gehen Sie einfach zu den Vergleichen und da ist ein Redis gegen NCache Funktionsvergleich. Dies basiert auf deren Dokumentation und Cache-Dokumentation. Sie können es also tatsächlich herunterladen und alle diese Funktionen ausprobieren. Beim Durchlesen handelt es sich also im Wesentlichen um Ihren Code, der sich auf dem Cache-Server befindet. Es sieht also so aus. Es ist also so, dass Sie es umsetzen. Lassen Sie mich Ihnen also einfach diese Schnittstelle zeigen, damit die Durchleseschnittstelle so aussieht ... Hier ist also eine Durchleseschnittstelle, oder? Handcursor hinein NCache und es gibt ein InIt, das eine Verbindung zu Ihrer Datenquelle herstellt, dispose und es gibt eine Lademethode. Load gibt Ihnen also einen Schlüssel und Sie geben ein Objekt zurück, basierend auf den Daten, die Sie erhalten haben. Und dann können Sie angeben, wann es ablaufen soll und so weiter. Das Gleiche gilt für das Durchschreiben: Sie haben InIt und entsorgen und dann erfolgt ein Schreiben in die Quelle. Der Schreibvorgang könnte also entweder „Hinzufügen“, „Aktualisieren“ oder „Löschen“ sein. Wo verwenden Sie Read-Through-Write-Through und warum sind sie so wichtig?
Zunächst einmal ermöglicht das Durchlesen die Art und Weise, wie es funktioniert: Sie haben einen Cache.Get und der Cache verfügt nicht über die Daten. Der Cache ruft Ihr Lesegerät auf, um es aus der Datenbank abzurufen. Das ist ein Vorteil. Der zweite Vorteil besteht darin, dass Sie das Durchlesen mit Ablauf und Datenbanksynchronisierung kombinieren können. Anstatt es also aus dem Cache zu entfernen, laden Sie es neu. Das Durchschreiben funktioniert auf die gleiche Weise, außer dass es ein Write-Behind gibt, was bedeutet, dass Sie den Cache nur aktualisieren, indem der Cache Ihre Datenbank aktualisiert. So werden auch Ihre Updates superschnell. Wenn also die Datenbankleistung zu einem Engpass wird, steht Ihnen ein Cache zur Verfügung, der Sie quasi aus der Fassung bringt. Sobald Sie das Durchlesen und Durchschreiben implementiert haben, können Sie den gesamten Persistenzcode oder einen Großteil davon in der Caching-Ebene konsolidieren und von beiden Funktionen profitieren, über die wir gerade gesprochen haben.
Datengruppierung und Datensuche
Sobald Sie also den Cache frisch halten und auch das Durchlesen und Durchschreiben durchführen, beginnen Sie jetzt, viele Daten zwischenzuspeichern. Der Cache ist also nicht mehr nur ein Schlüsselwertspeicher. Ich meine, es ist nicht bequem, alles als Schlüssel zu holen.
Man muss suchen können. Sie müssen in der Lage sein, eine SQL-Suche durchzuführen. Sie müssen also in der Lage sein, mit der Datenbank das zu tun, was Sie gewohnt sind.
Wenn Sie in einem Cache keine SQL-Suche durchführen können, wird dies sehr eingeschränkt. Da Sie in einem Cache keine Verknüpfungen durchführen können, da es sich um einen verteilten Cache handelt, gibt es andere Funktionen zum Gruppieren und Untergruppieren sowie Tags, mit denen Sie Daten gruppieren können Holen Sie alles in einem Anruf ab.
Auch hier ist es wirklich wichtig, dass Sie die Daten im Cache leichter finden können, wenn Sie viele Daten zwischenspeichern möchten. Daher sind diese Funktionen sehr wichtig.
Verteilte Cache-Funktionen
Ich werde nur kurz auf einige eingehen. Eine Funktion, die ich unbedingt ansprechen wollte, heißt „Near Cache“ oder „Client Cache“.
Sobald die Leute, die es gewohnt sind, einen eigenständigen InProc-Cache zu verwenden, zu einem verteilten Cache wechseln, sinkt plötzlich die Leistung, weil sie über das Netzwerk laufen. Sie müssen eine Serialisierung durchlaufen und plötzlich ist die Leistung nicht mehr schnell. Viele unserer Kunden beschweren sich. Nun, ich hatte erwartet, dass meine Leistung steigt, sie ist jedoch tatsächlich gesunken. Der Grund dafür ist, dass Sie nicht mit dem eigenständigen InProc-Cache konkurrieren können, in dem das Objekt auf Ihrem Heap gespeichert ist. Wenn Sie also über eine Client-Cache-Funktion verfügen, bei der es sich im Wesentlichen um einen lokalen Cache handelt, der das Objekt lokal hält, aber mit dem Cluster-Cache verbunden ist.
Auch dies ist eine Funktion, die NCache hat und die meisten Java-Caches haben, dass Sie wirklich die gleiche schnelle Leistung erhalten, ohne das Ding zu verlieren.
Aussichten für NCache, Sie können auf unsere Website gehen und den Open-Source-Cache herunterladen. Sie können also den Open-Source-Cache oder die Enterprise Edition herunterladen und, wie gesagt, alle Vergleiche zwischen ihnen erhalten NCache und Redis auf das.