Boston Code Camp 27
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
Mein Name ist Iqbal Khan. Ich bin Technologie-Evangelist bei Alachisoft. Wir sind ein Softwareunternehmen mit Sitz in der San Francisco Bay Area. Ich wohne persönlich in Tampa, aber wir haben dieses Produkt namens NCache. Es ist ein verteilter .NET-Cache. Heute werde ich darüber sprechen, wie Sie .NET-Anwendungen mit verteiltem Caching skalieren können. Darüber wird nicht gesprochen NCache, geht es um das Problem der Skalierbarkeit und wie man es mit verteiltem Caching lösen kann. Was tun? Wie sollten Sie es verwenden? Was sind einige der Best Practices? Wenn Sie Fragen haben, können Sie mich gerne anhalten. Damit wir interaktivere Diskussionen führen können. Lassen Sie mich anfangen.
Was ist Skalierbarkeit?
Lassen Sie uns also ein paar Definitionen aus dem Weg räumen. Nummer eins ist die Skalierbarkeit. Skalierbarkeit ist nicht Leistung. Sie haben vielleicht eine Anwendung, die mit fünf Benutzern wirklich gut funktioniert, aber sie ist nur skalierbar, wenn sie mit 5,000 oder 50,000 oder 500,000 Benutzern die gleiche Leistung erbringt. Skalierbarkeit ist also eine wirklich hohe Leistung unter Spitzenlasten. Wenn Ihre Anwendung mit 5 Benutzern nicht gut funktioniert, müssen Sie an einigen anderen Vorträgen teilnehmen.
Lineare Skalierbarkeit und nichtlineare Skalierbarkeit
Lineare Skalierbarkeit ist eher ein Anwendungsbereitstellungskonzept. Wenn Sie beim Bereitstellen Ihrer Anwendung weitere Server zur Bereitstellung hinzufügen und durch Hinzufügen weiterer Server die Transaktionskapazität linear erhöhen können, ist Ihre Anwendungsarchitektur linear skalierbar, andernfalls nicht linear skalierbar.
Das bedeutet, dass nach einer bestimmten Anzahl von Servern das Hinzufügen weiterer Server die Sache tatsächlich verschlimmert, was bedeutet, dass es irgendwo in Ihrer Anwendung einige Engpässe gibt, die nicht einfach durch das Hinzufügen weiterer Server gelöst werden können. Sie möchten definitiv keine nichtlineare Skalierbarkeit und Sie möchten definitiv eine lineare Skalierbarkeit in Ihrer Anwendung.
Welche Art von Anwendungen benötigen Skalierbarkeit?
Welche Art von Anwendungen benötigen Skalierbarkeit? Dies sind ASP.NET-Anwendungen. Dies sind Webdienste. Dies sind IOT-Backends, bei denen es sich wiederum hauptsächlich um Webdienste handelt. Dies sind große Datenverarbeitungsanwendungen, die in .NET nicht so verbreitet sind, immer mehr davon werden in Java ausgeführt, aber dennoch sind dies die Anwendungen, die auch Skalierbarkeit und jede andere Serveranwendung benötigen. Vielleicht arbeiten Sie zum Beispiel für eine große Bank mit Millionen von Kunden, und sie, Sie wissen schon, Kunden rufen an, um Adressänderungen vorzunehmen, oder sie möchten vielleicht eine neue Karte ausgestellt haben oder vielleicht überweisen sie Geld von einer Konto zum anderen und alle diese Transaktionen müssen innerhalb eines vorgegebenen Zeitrahmens für Compliance-Zwecke verarbeitet werden. Sie müssen also wieder Millionen von Anfragen innerhalb eines Zeitrahmens bearbeiten, den Sie möglicherweise nicht von einem einzelnen Computer aus erledigen können. Sie müssen also auch in diesem Fall skalieren können. Wenn Sie also eine dieser Anwendungen haben, die Skalierbarkeit benötigen, dann ist dies der richtige Vortrag, zu dem Sie gekommen sind.
Das Skalierbarkeitsproblem
Lassen Sie uns also auch das Skalierbarkeitsproblem definieren. Was ist das Skalierbarkeitsproblem? Nun, die Anwendungsschicht skaliert linear. Möglicherweise verfügen Sie über eine Webanwendung ASP.NET oder Webdienste. Sie haben einen Load Balancer davor, der den Datenverkehr gleichmäßig an alle Server weiterleitet. Sie können weitere Server hinzufügen, kein Problem. Alles funktioniert einwandfrei. Ich habe vorhin mit jemandem darüber gesprochen, dass die Datenbank zu einem Engpass wird, und sie waren nicht meiner Meinung. Daher denke ich, dass dies eine gute Gelegenheit ist, diese Diskussion zu führen.
Die Datenbank selbst arbeitet also superschnell. Es gibt kein Problem mit der Leistung. Datenbanken sind sehr intelligent, sie führen viel Zwischenspeichern im Arbeitsspeicher auf ihrem eigenen Server durch, aber Skalierbarkeit ist etwas, das sie konstruktionsbedingt nicht erreichen können, da Sie beispielsweise 10, 20, 30, 40, 50 Server hinzufügen können Ebene. Wir haben Kunden mit 50 oder mehr Servern in ihrer Anwendungsebene, weil sie so viele Benutzer haben. Stellen Sie sich vor, Sie sind eine große Bank oder eine Fluggesellschaft. Sie haben Millionen von Menschen, die auf Ihre Website kommen. Du hast diese große Werbeaktion für ein Ticket nach Hawaii oder so gemacht. Alle werden kommen, sie werden die Flugsuche machen, sie wollen die Tickets kaufen. Sie können hier problemlos weitere Server hinzufügen. Die Datenbank war superschnell und die Software ist großartig, aber von Natur aus ist die Datenbank keine verteilte Datenbank. Es wird an einem Ort aufbewahrt. Vielleicht können Sie einen Cluster aus zwei Servern haben, aktiv-aktiv, aktiv-passiv, aber sie dienen eher der Zuverlässigkeit als der Skalierbarkeit.
Sie können hier also nicht wirklich 10 Server haben, es sei denn, es handelt sich um einen NoSQL database, dann kannst du. Aber für eine relationale Datenbank könnte jeder von ihnen SQL Server, Oracle, Db2, MySQL sein, sie sind superschnell. Sie können sogar viel im Speicher verarbeiten, aber sie werden zum Engpass, wenn Sie immer mehr skalieren müssen. Und im Grunde genommen bemerken Sie Leistungsprobleme, wenn Sie tausend oder mehr gleichzeitige oder gleichzeitige Benutzer haben, und wenn Sie von 1,000 auf 5,000, 5,000 auf 10,000 wachsen, sehen Sie mehr. Was wir also gesehen haben, ist, wissen Sie, wenn Sie 1000 Benutzer haben, können Sie Caching verwenden oder nicht, aber wenn Sie auf 5,000, 10,000, 15,000 Benutzer anwachsen, spüren Sie definitiv den Schmerz und Sie enden mit dieser Skalierbarkeit Engpässe.
Jetzt haben relationale Datenbanken oder Mainframe-Legacy-Datenbanken dieses Problem. Es ist einer der Gründe NoSQL databases Bewegung begann, war deswegen. Allerdings hat es auch andere Vorteile und wir haben ein Produkt. Lassen Sie mich nur kurz zu Referenzzwecken kommen. Wir haben also ein Caching-Produkt, aber wir haben auch ein NoSQL Dokumentendatenbank. Genau wie Document DB ist es eine Open-Source-Datenbank.
Damit NoSQL database definitiv nicht die Skalierbarkeitsprobleme. Aber es ist nicht immer die Antwort. Warum ist das so? Denn damit es eine Antwort ist, a NoSQL database möchte, dass Sie alle Daten darin speichern. Also, es sei denn, Sie speichern Ihre Daten in a NoSQL database was bedeutet, dass Sie die Verwendung einer relationalen Datenbank für mindestens diesen Teil der Daten einstellen, es wird Ihr Problem nicht lösen. In vielen Fällen können Sie also einige der Daten, viele der Daten in eine verschieben NoSQL database und das ist es, was die antreibt NoSQL Bewegung. Aber relationale Datenbanken, ältere Mainframe-Daten, sie sind hier, um zu bleiben. Sie sind nicht etwas, das Sie aus technischen und geschäftlichen Gründen einfach wegwünschen können. Welche Skalierbarkeitsprobleme Sie auch immer lösen müssen, Sie müssen sie also mit relationalen Datenbanken im Bild lösen. Deshalb NoSQL database ist nicht immer die Antwort.
Die Lösung: Verteilter In-Memory-Cache
Und die Art und Weise, wie Sie dieses Problem lösen, ist eine neue bewährte Methode, die sich in den letzten fünf bis zehn Jahren herausgebildet hat, nämlich der verteilte In-Memory-Cache. Manche Leute nennen das auch In-Memory-Datenraster. Microsoft nannte das Data Fabric früher. Allerdings ändern sie ständig ihre Definitionen. Aber es ist ein verteilter Schlüsselwertspeicher im Arbeitsspeicher und jetzt ein wesentlicher Bestandteil Ihrer Architektur. Wenn Sie eine skalierbare Anwendung wünschen, müssen Sie programmieren, Sie müssen Ihre Anwendungen mit Blick auf einen verteilten Cache entwickeln. So stellen Sie sicher, dass die Anwendung nie zum Flaschenhals wird.
Was ist nun ein verteilter Cache? Es handelt sich im Wesentlichen um zwei oder mehr kostengünstige Server. Dies sind keine High-End-Datenbankserver, sondern Webserver-Boxen. Normalerweise ist eine Konfiguration mit zwei CPUs und 8 Kernen ziemlich typisch. 16 GB RAM sind ziemlich durchschnittlich. Wir sehen, dass 16 bis 32 Gigs wie der Sweet Spot der Erinnerung sind. Mehr als 64 Gig empfehlen wir unseren Kunden nicht einmal. Wir sagen, fügen Sie eine weitere Box hinzu, anstatt diese Box stärker zu machen. Denn wenn Sie mehr als 64 GB hinzufügen, hat eine .NET-Anwendung so etwas wie Garbage Collector, das viel Rechenleistung benötigt. Je mehr Speicher Sie also haben, desto schneller muss die CPU sein, damit der Garbage Collector den gesamten Speicher sammeln kann.
Es ist also besser, mehr Server zu haben, als wenige wirklich hochwertige Server zu haben. Mindestens 2 natürlich, weil Sie Zuverlässigkeit wollen. Für den Fall, dass ein Server ausfällt, aber danach ein Verhältnis von 4 zu 1 oder 5 zu 1, also hätten Sie normalerweise, sagen wir, 2, 3, 4 oder 5 Server in der Anwendungsebene. Am häufigsten sehen wir Werte zwischen 4 und 10, und dann gibt es natürlich viele Kunden, die mehr als 10 verwenden, aber 4 und 10 sind so ziemlich das, was wir als diesen Sweet Spot ansehen. Und dafür verwenden Sie einen 2-Server-Cluster. Wenn Sie mehr als 10 oder 12 wachsen, fügen Sie eine dritte oder vierte hinzu und so und so weiter. Und da ein verteilter Cache ein Schlüsselwertspeicher ist, ist er verteilt. Es repliziert Daten auf intelligente Weise über mehrere Server hinweg, sodass Sie Zuverlässigkeit erhalten, aber gleichzeitig nicht viel Zeit mit der Replikation verbringen. Wenn beispielsweise alle Daten auf alle Server repliziert werden müssen, ist das eine Menge zusätzlicher Verarbeitung, die Sie nicht benötigen. Es ist also diese Art von intelligenter Replikation, die es leisten muss. Manchmal müssen Sie auf diese Weise replizieren, aber das sind Spezialfälle. Wenn Sie also einen verteilten Cache eingerichtet haben, werden Sie ungefähr 80% der Zeit darauf zugreifen. Alle Lesevorgänge werden von dort aus durchgeführt, und alle Aktualisierungen und einige der Lesevorgänge werden für die Datenbank und auch für den Cache durchgeführt. Wenn Sie also etwa 80 % Ihres Datenbankverkehrs in Ihrem Cache abfangen können, ist Ihre Datenbank plötzlich sehr dünn. Es hat nicht viel zu tun. Was auch immer es zu tun hat, es wird viel schneller erledigt. Die Leistung wird sich also ebenso verbessern wie die Skalierbarkeit.
Dieser In-Memory-Cache verteilt, ob das so ist NCache, ob das so ist Redis Auf der .NET-Seite, auf der Java-Seite gibt es mehr Spieler, welches Produkt Sie auch wählen, verteilter Cache ist jetzt so ziemlich eine gegebene Best Practice. Das müssen Sie in Ihre Architektur integrieren.
Irgendwelche Fragen dazu bisher, bevor ich fortfahre? Also, ja, ein logischer Cache kann mehrere Server umfassen. Im Falle von NCache Sie können mehrere Caches auf denselben Servern haben. Jeder Cache wird also zu Isolationszwecken zu einem eigenen Container, aber jeder Cache kann alle fünf Server umfassen. Wenn ich Spanne sage, bedeutet das, dass sich einige Daten auf einem Server befinden, einige auf den anderen, wissen Sie, und die Replikation ist ein separater Teil davon, der je nach Ihren Vorlieben durchgeführt werden kann oder nicht. Aber ja, alle Server werden zum Speichern dieses Caches verwendet und der Cache muss kohärent sein. Es muss immer richtig sein, oder man kann sagen, es muss irgendwann richtig sein, aber ziemlich nahe daran, immer richtig zu sein. Was auch immer Sie im Cache speichern, wenn Sie aktualisieren, ist es Ihnen egal, wo sich die Daten befinden, Sie wissen wahrscheinlich nicht einmal, wo sich die Daten befinden. Alles, was Sie wissen, ist, dass dieser Cluster meine Daten enthält, und wenn ich sie abrufe, habe ich sie möglicherweise von diesem Server gespeichert und ich versuche, sie sofort danach hier zu lesen, und ich sollte in der Lage sein, dieselbe Kopie zu erhalten. Wenn ich das kann, wird daraus ein konsistenter oder kohärenter Cache. So viel Datenintegrität für Updates ist also immer gewährleistet.
Das ist Ihre Präferenz, und ich werde im Hinblick darauf, wie Sie den Cache tatsächlich verwenden, näher darauf eingehen. Also, eine Sache, die Sie … Ich meine, das Hauptziel bis jetzt war es, Sie davon zu überzeugen, dass Sie die Skalierbarkeit als Teil Ihrer Architektur haben müssen, wenn Sie Skalierbarkeit wollen.
Allgemeine Verwendung von verteiltem Cache
Nun, da wir, sagen wir, uns einig sind, dass Sie einen verteilten Cache benötigen, stellt sich als Erstes die Frage, wie Sie ihn verwenden. Wo verwenden Sie es? Wofür verwendest du es? Welche Daten darin gespeichert sind und alle Probleme im Zusammenhang mit diesen Daten.
Zwischenspeichern von Anwendungsdaten
Es gibt also drei Anwendungsfälle auf hoher Ebene. Nummer eins ist das Zwischenspeichern von Anwendungsdaten, worüber ich gerade gesprochen habe, dh Sie haben Daten in der Datenbank, Sie rufen sie ab und speichern sie zwischen. Das Ziel beim Zwischenspeichern von Anwendungsdaten ist also … aber ich habe gerade erwähnt, dass Sie nicht so viel zur Datenbank gehen möchten, Sie möchten diesen Datenbankverkehr reduzieren, damit Ihre Anwendung skaliert. Aber die Daten existieren jetzt an zwei Orten. Es existiert im Cache und es existiert in der Datenbank. Wenn also Daten an zwei Orten vorhanden sind, was ist die erste Sorge, die Ihnen in den Sinn kommt? Synchronisation zwischen den beiden. Ist es also konsistent? Denn wenn die Daten nicht konsistent sein werden, können Sie den Cache nur für schreibgeschützte Daten verwenden. In der Tat, die meisten Leute, wenn Sie sie fragen, wofür verwenden Sie einen Cache? Die reflexartige Reaktion sind schreibgeschützte Daten. Weißt du, ich fühle mich nicht wohl dabei, den Cache für irgendwelche Daten zu verwenden, die sich wirklich in Echtzeit oder zur Laufzeit ändern werden. Aber wenn Sie den Cache nicht für Transaktionsdaten verwenden können, die ich den Begriff für Daten verwende, die sich häufig ändern, machen diese Daten wahrscheinlich 80 % bis 90 % Ihrer Daten aus. Das bedeutet also, dass Sie in 80% bis 90% der Fälle nicht einmal den Cache verwenden können, und wenn Sie den Cache nicht einmal verwenden können, wird es wie ein NoSQL database. Es ist nicht immer die Antwort, wissen Sie. Und Sie möchten, dass es die Antwort ist, also wissen Sie, dass ein guter verteilter Cache Ihnen die Gewissheit geben muss, dass alles, was Sie zwischenspeichern, mit der Datenbank konsistent ist. Wenn dies nicht der Fall ist, ist dieser Cache nicht der richtige Cache für Sie. Das ist also das Erste, das ist der erste Anwendungsfall.
ASP.NET-spezifisches Caching
Der zweite Anwendungsfall ist, wenn Sie ASP.NET-Anwendungen haben.
- ASP.NET-Sitzungscaching
Sie können Ihre Sitzungen im Cache speichern. Sitzungen sind etwas, das fast alle ASP.NET-Anwendungen haben. Sie werden entweder in einem In-Proc-Modus oder im SQL-Server-Modus gehalten. SQL Server ist aus zwei Gründen nicht der richtige Ort, um Sitzungen zu halten, einer natürlich aus dem ersten Grund, nämlich je mehr Sie Daten in der Datenbank aufbewahren, desto größer ist der Skalierbarkeitsengpass. Zweitens werden Sitzungen als Blobs gehalten und relationale Datenbanken wurden nicht wirklich für Blobs entwickelt. Sie wurden für strukturiertere Daten entwickelt, die Sie indizieren und durchsuchen können. Während ein verteilter Cache der Schlüsselwert ist, ist der Wert immer ein Blob. Diese Sitzungen passen also sehr gut zu einem verteilten Cache.
- ASP.NET View State Caching
Der zweite Typ von ASP.NET-Daten ist, wenn Sie nicht das MVC-Framework verwenden, was viele der vorhandenen ASP.NET-Anwendungen immer noch nicht tun, dann haben Sie dieses Ding namens a Sichtzustand und ein Ansichtsstatus ist nichts anderes als eine verschlüsselte Zeichenfolge, die aufbewahrt und vom Webserver an den Browser gesendet wird, nur um zum Webserver zurückzukehren und ziemlich groß zu werden. Es kann leicht 100 Kilobyte groß sein und verbraucht daher viel zusätzliche Bandbreite. Es braucht mehr Zeit zum Reisen. Wenn Sie das mit Millionen von Anfragen multiplizieren, die Sie verarbeiten, steigen auch Ihre Kosten für den Bandbreitenverbrauch erheblich. Es ist also ein idealer Fall, um auf der Serverseite zwischenzuspeichern und nur einen kleinen Schlüssel zu senden. Wenn also der Ansichtszustand das nächste Mal verwendet werden soll, wird der Schlüssel zurückgesendet und der Ansichtszustand aus dem Cache abgerufen.
- ASP.NET-Ausgabecaching
Das dritte Beispiel für ASP.NET-spezifisches Caching ist die Seitenausgabe. Es ist Teil des ASP.NET framework wird als Ausgabecache bezeichnet, mit dem Sie die Ausgabe einer Seite zwischenspeichern können, wenn sie sich nicht ändert, und Sie können einen verteilten Cache verwenden, um sie zwischenzuspeichern, anstatt sie auf jedem Webserver separat zu speichern, was dann zu mehreren Kopien wird, die synchronisiert werden müssen. Diese drei Anwendungsfälle oder drei Beispiele beziehen sich also auf den ASP.NET-spezifischen Caching-Anwendungsfall.
Anders als beim Zwischenspeichern von Anwendungsdaten ist hier die Art des Problems sehr unterschiedlich. Hier existieren die Daten nur im Cache. Ich meine, all diese Daten werden nirgendwo mehr gespeichert. Es wird also nicht in der Datenbank gespeichert. Sie haben also kein Synchronisationsproblem mehr zwischen der Datenbank und dem Cache. Aber Sie haben jetzt ein anderes Problem. Wenn Sie über einen In-Memory-Cache verfügen, ist dies der einzige Speicher Ihrer Daten. Was ist die größte Sorge? Was könnte daran schief gehen? Es verschwindet. Ja, das kann weg. Wenn ein Server ausfällt und Server ausfallen, einschließlich Windows. Wenn also ein Server ausfällt, verlieren Sie Daten und insbesondere einige der, ich meine für den Anzeigestatus und den Sitzungsstatus, ich meine den Ausgabecache, selbst wenn Sie ihn verlieren, führen Sie die Seite einfach erneut aus, außer diesen beiden. Zum Beispiel, Sitzungsstatus, Sie hatten gerade diesen Airline-Kunden, der alle möglichen Flugsuchen durchgeführt hat und er ist dabei, die Bestellung aufzugeben, und der Server stürzt ab und seine Sitzung geht verloren, er muss sich wirklich anmelden. Wissen Sie, Sie könnten diesen Kunden verlieren. Sie wollen also auf keinen Fall verlieren. Sie möchten also nicht, dass diese Daten verschwinden. In diesem Fall war die Synchronisation das große Problem, hier ist die Zuverlässigkeit.
Die Zuverlässigkeit wird also durch Replikation gehandhabt. In jedem Cache, der keine Replikation durchführt, können Sie keine Sitzungen darin speichern. Das Schöne am ASP.NET-spezifischen Caching ist übrigens, dass keine Programmierung erforderlich ist. Es fügt sich vollständig in das ASP ein.NET framework. Leider müssen Sie für das Zwischenspeichern der Anwendungsdaten programmieren. Auf der Java-Seite müssen Sie dies nicht tun, oder es entstehen tatsächlich mehr Standards. Es gibt einen Standard namens JCache. Wenn Sie das programmieren, können Sie einfach einen der Caches von Drittanbietern anschließen, und Sie müssen sich nicht an einen Cache halten. Noch mehr, wenn Sie eine OR-Mapping-Engine wie Hibernate oder im Fall von .NET NHibernate verwenden, können Sie einen Cache einbauen. Entity Framework bis zum EF-Kern oder vor dem EF-Kern erlaubte es nicht, dass sich ein Cache eines Drittanbieters automatisch einfügt. Obwohl wir einen ADO .NET-Anbieter für EF6 implementiert hatten. Das war mehr Caching auf ADO.NET-Ebene, also haben Sie Abfragen zwischengespeichert, was besser ist als kein Caching, aber es ist nicht so leistungsfähig wie das Caching auf Entitätsebene, wo Sie auch Aktualisierungen verfolgen können.
Entity Framework oder EFCore-Caching
Das neue EF7 oder EF Core hat eine viel flexiblere Architektur. Es ermöglicht Ihnen, einen Drittanbieter-Cache anzuschließen. Wenn Sie also zu EF Core wechseln, können Sie einen verteilten Cache wie z NCache ganz ohne Programmierung. Sie haben also nur Ihre Standardprogrammierung und Cache-Plug-ins durchgeführt. Aber ansonsten müssen Sie es tun. Aber selbst in diesem Plugin können Sie nicht alle Funktionen nutzen, über die ich sprechen werde. Zumindest in ASP.NET-spezifisch ist dies der einfachste Gewinn. Wenn Sie einen Cache einbauen, müssen Sie, da keine Programmierung erforderlich ist, nur einige grundlegende Plausibilitätstests durchführen, und Ihre Anwendung erfährt plötzlich eine erhebliche Steigerung der Leistung und Skalierbarkeit.
Irgendwelche Fragen, bevor ich fortfahre? In Bezug auf die Anwendung oder in Bezug auf den Cache? Apropos Cache. Ein Cache ist wie eine Datenbank. Genauso wie Sie Aufrufe an die Datenbank tätigen und dann eine Ausnahmebehandlung haben. Wenn im Cache etwas schief geht, wirft der Cache eine Ausnahme, Sie fangen sie ab und müssen dann die entsprechenden Maßnahmen ergreifen. Im Gegensatz zu einer Datenbank, bei der eine Aktualisierung aufgrund der Datenintegrität fehlschlagen kann, weil Sie möglicherweise Überprüfungseinschränkungen oder andere Einschränkungen der referenziellen Integrität haben, existiert keine dieser Einschränkungen im Cache. Ein Cache akzeptiert alle Daten, die Sie ihm geben. Das einzige Mal, dass eine Cache-Aktualisierung oder -Operation fehlschlägt, ist, wenn etwas mit dem System schief geht. Ja, etwas Katastrophales. Sie müssen sich also keine Sorgen machen, dass der Cache Ihre Daten im normalen Betrieb nicht aktualisiert.
Sicherheit
Das hängt also davon ab, welches Cache-Produkt Sie verwenden. NCache hat alle diese Funktionen integriert. Sie können einschalten Sicherheitdienst, sodass jeder Benutzer, der den Cache verwendet, authentifiziert / autorisiert werden muss. Es hat auch viele andere Sicherheitsfunktionen wie Verschlüsselung eingebaut. Wenn Ihre Anwendung also sehr sensibel ist, können Sie die Daten verschlüsseln, bevor sie zwischengespeichert werden, und all dies wird einfach automatisch vom Cache erledigt, ohne dass Sie zusätzlichen Aufwand betreiben müssen. Denn, wie gesagt, einer der größten Nutzer von NCache ist die Finanzdienstleistungsbranche. Weil sie viel Online-Banking haben. Dort findet viel E-Business statt und ihre Daten sind sehr sensibel. Das hängt also davon ab, für welches Produkt Sie sich entscheiden.
Gemeinsame Nutzung von Laufzeitdaten durch Ereignisse
Der dritte Anwendungsfall ist Laufzeitdatenfreigabe durch Ereignisse. Genau wie Sie Nachrichtenwarteschlangen verwenden, ist MSMQ eine, RabbitMQ eine andere. Sie haben viel mehr Funktionen in Bezug auf das Messaging für eine verteilte Umgebung an mehr als einem Standort. Wenn sich Ihre Anwendung in einem Rechenzentrum befindet und Sie dies tun müssen Pub / Sub Art der gemeinsamen Nutzung von Daten ist ein verteilter Cache viel skalierbarer als alle anderen Nachrichtenwarteschlangen. Es hat möglicherweise nicht so viele Funktionen wie sie, aber Sie benötigen möglicherweise nicht alle diese Funktionen. Aber es ist viel schneller und viel skalierbarer und das stimmt für NCache das gilt auch für andere verteilte Caches, die diese Funktion bieten. Denn wieder wird dieser ganze Cluster zu einem Nachrichtenbus. Wenn Sie also viele Aktivitäten ausführen, breiten sich die Ereignisse sehr schnell aus, da es sich um mehr als einen Server handelt, der diese Ereignisse verarbeitet, und Sie können weitere Server hinzufügen, wenn die Last zunimmt.
Viele dieser Serveranwendungen haben heutzutage also integrierte Workflows, wissen Sie. Wo eine Anwendung etwas tut und wenn dies erledigt ist, tun andere Anwendungen etwas anderes. Hier kommt also das Pub/Sub- oder das Producer/Consumer-Konzept ins Spiel. Es gibt eine Ereignisbenachrichtigungsfunktion. NCache hat diese Funktion aufgerufen kontinuierliche Abfrage Das ist ein sehr mächtiges Feature, das auch auf der Java-Seite existiert, aber keiner der anderen .NET-Caches hat es.
Die gemeinsame Nutzung von Laufzeitdaten ist also auch etwas, das Sie unbedingt über einen verteilten Cache in Betracht ziehen sollten, da dies Ihr Leben viel einfacher macht, anstatt mehrere andere Produkte zu integrieren. Auch hier ist die Art des Problems normalerweise dieselbe, nämlich dass die Daten, die Sie teilen möchten, nur im Cache vorhanden sind. Es könnte in der Datenbank existieren, aber in einer anderen Form, weil Sie es konstruiert haben, Sie haben es produziert, wissen Sie, Sie haben eine Menge Daten zusammengebracht und in dieser endgültigen oder Zwischenform teilen Sie es mit jemandem anders. Wenn Sie also diese Daten verlieren, müssen Sie das Ganze wiederholen. Obwohl es nicht so schlimm ist wie Sitzungen, hat es dennoch viele Auswirkungen auf die Leistung. Sie möchten diese Daten also nicht verlieren. Auch hier geht es also darum, sicherzustellen, dass der Cache zuverlässig ist.
Das sind also die drei allgemeinen Anwendungsfälle, die ein verteilter Cache bietet. Wie gesagt, ein verteilter Cache ist im Wesentlichen eine verteilte In-Memory-Datenbank, ein Key-Value-Store.
Hands-on-Demo
Bevor ich näher darauf eingehe, wie Sie dies tun können, werde ich Ihnen nur schnell zeigen, wie ein verteilter Cache aussieht. Damit Sie sehen können, wie es wäre, wenn Sie es in Ihrer Anwendung verwenden würden. Ich werde natürlich verwenden NCache als das Beispiel. NCache ist ein Open-Source-Cache. Sie können es also verwenden, ohne es zu kaufen, wenn Sie nicht das Geld oder das Budget haben. Wenn Ihr Projekt geschäftssensibler ist, kaufen Sie natürlich die Enterprise Edition. Also habe ich einige VMs in Azure eingerichtet, die ich verwenden werde. Ich werde einen 2-Knoten-Cache-Cluster verwenden, also habe ich „demo1“ und „demo2“ als meine Cache-Server und „demo-client“ ist meine Anwendungsserverbox. Das ist also Ihre ASP.NET-Serverbox. Also, ein NCache Client ist wirklich Ihr Anwendungsserver.
Ich bin bei, sagen wir mal, Demo-Client angemeldet. Also, das erste, was ich tun werde, ist, einen neuen Cache zu erstellen. Also werde ich dieses Tool namens verwenden NCache Manager. Es ist also ein Tool im Explorer-Stil. Ich werde nur sagen, erstellen Sie einen neuen Cluster-Cache. In NCache Alle Caches sind benannt.
Ich wähle einen Speicher oder eine Replikationsstrategie aus.
Ich werde einfach weitermachen und hier meinen ersten Cache-Server angeben. Geben Sie meine zweite an.
Ich werde einfach fortfahren und sagen, wie viel Speicher mein Server verbrauchen sollte. In Ihrem Fall wird es viel mehr sein. Ich habe nur einen Gig angegeben.
Wenn dieser Speicher also verbraucht ist, können Sie Eviction-Richtlinien festlegen. Nehmen wir also an, die Richtlinie „Zuletzt zuletzt verwendet“ bedeutet, dass einige der Elemente entfernt werden, die am längsten nicht verwendet wurden.
Also, das habe ich gerade bekommen. Ich werde fortfahren und einen Client-Knoten hinzufügen, der meine Box ist, und ich werde einfach fortfahren und den Cache starten.
Also, auf welcher Maschine richten Sie das ein? Dies ist ein Azur. Also, diese beiden sind meine Demo1 und Demo2. Also, ich bin tatsächlich in diese Box eingeloggt und benutze sie NCache Manager hier und ich erstelle hier einen Cluster aus demo1 und demo2.
Jetzt, da ich damit begonnen habe, kann ich fortfahren und Statistiken anzeigen. Ich kann also einige PerfMon-Zähleraktivitäten sehen. Ich kann dieses Überwachungstool auch von starten NCache das lässt mich Dinge sehen und dann werde ich einfach schnell dieses Tool namens Stress Test Tool ausführen. Damit können Sie den Cache in Ihrer Umgebung schnell testen, um zu sehen, wie er funktionieren wird.
Dieses Tool ist also wie Ihre Anwendung. Sie können es verwenden, um verschiedene Arten von Lasten und verschiedene Arten von Operationen zu simulieren. Zum Beispiel mache ich hier etwa 600 Anfragen pro Sekunde und jeweils etwa 700 bis 800.
Lassen Sie mich hier eine weitere Instanz des Stress Test Tools ausführen. Sie werden also sehen, dass sich diese Last einfach verdoppelt. Wenn ich also immer mehr Instanzen der Anwendung hinzufüge, steigt die Belastung des Caches bis zu einem Punkt, an dem diese beiden Server ihre maximale Kapazität erreichen, und dann fügen Sie einfach einen dritten hinzu.
Und Sie können das alles zur Laufzeit tun, ohne irgendetwas anzuhalten. Also, plötzlich Ihre Infrastruktur … Denken Sie nur darüber nach, wenn Ihre Datenbank zu ersticken begann, können Sie wirklich einen weiteren Server hinzufügen und dieses Problem lösen? Du kannst nicht. Denn von Natur aus geht es nicht um eine bestimmte Datenbank, sondern um relationale Datenbanken. Aber im Falle eines Caches fügen Sie einfach einen weiteren Server hinzu und jetzt funktioniert der Cache.
So sieht also ein Cache aus. Es ist so einfach zu bedienen und zu konfigurieren, wie Sie sehen können. Ich meine, das einzige, was ich nicht getan habe, ist es zu installieren. Das war nur ein Windows-Installer, der nicht so lange dauert. Abgesehen davon habe ich ungefähr fünf Minuten gebraucht, um einen Zwei-Knoten-Cluster zu finden.
Und jetzt, da ich all diese Dinge konfiguriert habe, kann ich diesen Cache-Namen tatsächlich für die Anwendungen angeben, die auf dieser Box laufen. Wenn ich also mehr Kundenboxen hätte, würde ich sie hier einfach weiter hinzufügen.
In Ihrem Fall haben Sie für diese beiden wahrscheinlich 8 oder 10 davon. Sie würden sie also alle hinzufügen, und sobald Sie diesen Cache gemacht haben, ist der Demo-Cache dort verfügbar, und dann gehen Sie einfach und aktualisieren Ihr Ding.
So, jetzt wo wir wissen, wie ein Cache aussieht, lass mich jetzt schnell zum nächsten Thema übergehen. Wie gesagt, der einfachste Weg, den Cache zu verwenden, besteht darin, ihn für Sitzungen zu verwenden. Wie mache ich das? Also, ich habe die ASP.NET-Anwendung. Ich würde hineingehen und die web.config öffnen und zwei Dinge tun. Zuerst werde ich gehen und die Assembly hinzufügen.
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=1448e8d1123e9096" />
</assemblies>
</compilation>
...Im Falle von NCache das ist die Assembly, die die implementiert ASP.NET-Sitzungszustandsanbieter. Also, so ist es NCache Stecker in die ASP.NET framework. Jeder Drittanbieter-Cache müsste das tun. Sie fügen also einfach diese Zeile in den Assemblys hinzu und gehen zweitens einfach zum Sitzungs-Tag und geben dies spezifisch für den von Ihnen ausgewählten verteilten Cache an.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...Im Falle von NCache Sie kopieren dies einfach und es gibt ein paar Dinge, die Sie sicherstellen müssen. Zuerst müssen Sie sicherstellen, dass der Modus „Benutzerdefiniert“ ist. Weil benutzerdefiniert Speicher von Drittanbietern bedeutet. Und dann 'Timeout', stellen Sie sicher, dass es so ist, wie Sie es haben möchten, und alles andere können Sie als Standard beibehalten und geben Sie einfach hier und dort einen Cache-Namen an. Es sollte also nur 'demoCache' sein. Sobald Sie diese Änderung vornehmen und die Anwendung erneut ausführen oder eigentlich sobald Sie dies speichern, wissen Sie, dass der ASP.NET-Arbeitsprozess wiederverwendet wird. Es wird abholen NCache Konfiguration und plötzlich sehen Sie, dass jede Sitzung eine Zählung ist. Also, all die, wissen Sie, diese Zählung, die wir gesehen haben NCache in diesem PerfMon hier.
Das wären also 540 Sitzungen, die gespeichert werden, und wenn Sie weitere Sitzungen hinzufügen, erhöht sich natürlich die Anzahl.
Mit diesem kleinen Aufwand können Sie Ihrer Bewerbung also sofort einen großen Schub geben. Das Gleiche gilt für den View State. Beim Ausgabe-Cache ist etwas mehr Konfiguration erforderlich, aber den Ansichtsstatus und die Sitzung können Sie ohne Aufwand in wenigen Minuten erledigen, und plötzlich verbrauchen die Anwendungen einen enormen Schub.
Übersicht über das Zwischenspeichern von Anwendungsdaten (API)
Lassen Sie uns nun zum Zwischenspeichern von Anwendungsdaten übergehen, um das sich der Großteil dieses Vortrags dreht. Wenn Sie also den Cache für das Zwischenspeichern von Anwendungsdaten verwenden müssen, müssen Sie seine API programmieren. Das liegt daran, dass es noch keine Standard-API gibt. Wir haben also unsere API so ausgewählt, dass sie möglichst nahe am ASP.NET-Cache-Objekt liegt.
Cache-VerbindungCache 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");NCache gibt es seit 2005, also sind es jetzt fast 11 Jahre. Aber es sieht dem ASP.NET-Cache-Objekt sehr ähnlich. Es gibt einige zusätzliche Dinge, also sagen wir, Sie verbinden sich mit dem Cache über einen Cache-Namen. Sie erhalten einen Cache-Handle. Dann verwenden Sie diesen Cache-Handle Cache.Get. Get enthält Add, Insert, Remove und es gibt eine Async-Version davon, was bedeutet, dass Sie nicht warten müssen, bis der Cache aktualisiert wird, und dann können Sie natürlich beim Aufrufen von Async einen Rückruf angeben. Ihr Rückruf wird also angerufen, falls etwas schief geht.
Lassen Sie mich Ihnen zeigen, wie das in einer Grafik aussieht, wie in einer richtigen Anwendung. Wenn Sie also eine … Dies ist eine Standard-Konsolenanwendung. Sie müssten auf die Assembly Ihres Caches verweisen. Im Falle von NCache, es sind nur diese beiden Baugruppen, Alachisoft.NCache.Laufzeit, Alachisoft.NCache.Netz. Sie geben hier die gleichen Namensräume an und beginnen dann die Anwendung, die im Fall von ASP.NET wahrscheinlich in der sein wird global.asax in der Init-Methode oder der Anwendungsstartmethode. Aber sagen wir hier, Sie verbinden sich mit dem Cache basierend auf dem Cache-Namen und dem Cache-Namen, wie Sie wissen, ist das zumindest so NCache So wird der Cache erkannt und Sie erhalten ein Cache-Handle. Dann erstellen Sie Ihre Objekte und Sie tun a cache.Hinzufügen. Sie geben den Schlüssel an. Das ist kein guter Schlüssel. es sollte mehr Einzigartigkeit darin haben. Aber nehmen wir an, Sie geben den Schlüssel an und hier ist Ihr Wert das eigentliche Objekt.
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...Datenablauf
Und in diesem Fall NCache macht dieses Ding namens absoluter Ablauf. Also lass mich dazu kommen. Also sprachen wir über das Zwischenspeichern von Anwendungsdaten, um den Cache aktuell zu halten. Wenn Sie also den Cache nicht aktuell halten können, erzwingen Sie die Verwendung für schreibgeschützte Daten. Also, wie halten Sie den Cache frisch? Es gibt mehr als einen Weg. Der erste Weg, den so ziemlich jeder Cache hat, wird als absolutes Ablaufdatum bezeichnet. Hier geben Sie an, wie lange Sie diese im Cache behalten möchten. Sie sagen also zum Cache, ich fühle mich nur für eine Minute wohl, dass ich nicht denke, dass diese Daten länger als eine Minute im Cache bleiben sollten, weil ich denke, wenn sie länger als eine Minute im Cache aufbewahrt wurden, jemand anderes wird es aktualisieren und der Cache wird veraltet sein. Sie stellen also eine fundierte Vermutung darüber an, wie lange der Cache Ihre Daten enthalten sollte. Und natürlich sollten Sie für alle Daten, die Sie zwischenspeichern, eine Art Ablaufdatum haben. Ziemlich … ich meine einige Daten, von denen man ziemlich genau annehmen kann, dass sie niemals ablaufen werden, also kann man sagen, dass sie kein Ablaufdatum haben. Aber 99 % der Daten oder etwas mehr als 90 % der Daten müssen abgelaufen sein. Das absolute Ablaufdatum hält den Cache also frisch, basierend auf einer fundierten Vermutung.
Es gibt noch einen weiteren Ablauf namens gleitender Ablauf. Sein Zweck ist ein völlig anderer. Obwohl es den gleichen Namen verwendet, verfällt der Anruf. Die gleitende Ablaufzeit besagt, dass dies abläuft, wenn niemand dieses Objekt so lange berührt, sagen wir für 10 Minuten, für 20 Minuten. Und dies wird eher für transiente Daten verwendet. Dies wird also für mehr ASP.NET-spezifische Daten verwendet, bei denen Sie eigentlich nur aufräumen. Du sagst, weißt du, niemand sonst braucht es mehr. Wenn also ein Benutzer die Sitzung 20 Minuten lang nicht mehr verwendet, sagen Sie, dass sich dieser Benutzer sowieso abgemeldet hat, also entfernen Sie die Sitzung. Das ist also ein Bereinigungsablauf. Dann absoluter Ablauf, der ein Synchronisationszweck ist. Der Zweck des absoluten Ablaufs ist die Synchronisation. Und wieder können Sie es tun, Sie können Dinge in 10 Sekunden, 15 Sekunden, 1 Minute, 5 Minuten, 10 Minuten ablaufen lassen. Die häufigste Ablaufzeit beträgt wahrscheinlich eine oder zwei Minuten.
Aber es gibt ein Problem mit dem Ablauf. Es ist, dass Sie eine Vermutung anstellen. Sie sagen, ich denke, es ist in Ordnung, es so lange zwischenzuspeichern. Aber es gibt keine Garantie. In einigen Fällen kann dies der Fall sein, aber in vielen Fällen gibt es keine Garantie. Was ist, wenn eine andere Anwendung ebenfalls auf dieselbe Datenbank zugreift und diese Daten aktualisiert. Möglicherweise werden einige Skripts ausgeführt. Wann immer so etwas passiert, reichen Verfallsfristen also nicht aus. Und hier brauchen Sie den Cache, um Änderungen in der Datenbank überwachen zu können.
Wenn Sie eine Zuordnung zwischen dem, was sich im Cache befindet, und den entsprechenden Daten in der Datenbank angeben können, und Sie können dem Cache sagen, bitte überwachen Sie diesen Datensatz. Wenn sich dieser Datensatz ändert, fahren Sie fort und entfernen Sie dieses Element aus dem Cache.
Datenbankabhängigkeit
Lassen Sie mich Ihnen zeigen, wie das geht. Es gibt also eine Funktion namens SQL-Abhängigkeit in ADO.NET das NCache Verwendet. Welches erlaubt NCache Kunde Ihrer Datenbank zu werden. Und dies könnte eine SQL-Datenbank sein, dies könnte Oracle sein. Und dann NCache weist die Datenbank an, sie zu benachrichtigen, wenn sich dieser Datensatz ändert und dieser Datensatz eine von Ihnen angegebene SQL-Anweisung ist. Meistens entspricht es einer oder mehreren Zeilen in einer Tabelle, die verwendet wurden, um dieses zwischengespeicherte Objekt zu erstellen. Also, zum Beispiel hier, also, wenn ich zu der Sache mit den SQL-Abhängigkeiten gehen würde, wieder dasselbe. Sie haben einen Cache-Handle und dann, wenn Sie hinzufügen, diesen cache.Hinzufügen, die Sie jetzt angeben, im Falle von NCache Dieses Ding namens Cache-Element, das eine Art Struktur ist, die den Wert und einige andere Metadaten enthält. Eine der enthaltenen Metadaten wird als SQL-Cache-Abhängigkeit bezeichnet, bei der es sich um eine NCache -Klasse, die der ADO.NET SQL-Cache-Abhängigkeit auf der Serverseite zugeordnet ist. Sie übergeben ihm eine Verbindungszeichenfolge und eine SQL-Anweisung.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}Sie sagen also so etwas wie „Wählen Sie einige Spalten aus den Produkten aus, in denen die Produkt-ID unabhängig vom Wert ist“. Dies ist also ein Produkt, dem Sie dies zuordnen. Sie sagen also zu NCache Verwenden Sie diese SQL-Anweisung, verwenden Sie diese Verbindungszeichenfolge und überwachen Sie diesen Datensatz oder bitten Sie den SQL-Server, diesen Datensatz zu überwachen. Eigentlich läuft dieser Code hier, richtig. Denn dort ist die NCache ist.
Dieser hat dann also mit dem Cache-Cluster gesprochen und der Cache-Server führt dann tatsächlich den ADO.NET-Aufruf durch und der Cache-Server spricht nun mit der Datenbank und wird zum Client. Und der Cache-Server ist derjenige, der die Benachrichtigung erhält. Und der Cache-Server ist derjenige, der dieses Element tatsächlich aus dem Cache entfernt, wenn die Datenbank ihm mitteilt, dass sich diese Daten geändert haben. Wenn Sie also diese Funktion eingebaut haben, haben Sie plötzlich die Flexibilität, Daten im Cache zu behalten, von denen Sie nicht einmal vorhersagen können, wann sie sich ändern könnten, wissen Sie. Aber Sie wissen nur, dass es sich auf unvorhersehbare Weise ändern kann, also können Sie die SQL-Abhängigkeit angeben.
Dies ist eine wirklich leistungsstarke Funktion. Dies ist die Funktion, die es einem Cache ermöglicht, Transaktionsdaten zwischenzuspeichern. Selbst wenn Sie nicht ständig die Kontrolle über die Updates haben und deshalb alle möglichen Daten zwischenspeichern, wird dieser Cache tatsächlich nützlich. Und dies kann auf verschiedene Arten erfolgen, wenn die zugrunde liegende Datenbank Datenbankbenachrichtigungen unterstützt, was im Fall von SQL Server und Oracle der Fall ist, dann wird sie die SQL-Abhängigkeits- oder die Oracle-Abhängigkeitsfunktion verwenden, wenn nicht, die NCache hat zumindest einen eingebauten Polling-Mechanismus, bei dem Sie ihn auch angeben können. … Es gibt einen Mechanismus, bei dem Sie eine spezielle Tabelle angeben NCache überwacht es und alle Zeilen, die sich darin ändern, gibt es ein entsprechendes Cache-Element, das es dann entfernt.
Und eine dritte Option besteht darin, dass Sie tatsächlich Cache-Aufrufe innerhalb einer CLR-Prozedur tätigen. Immer wenn sich also Daten ändern, gibt es einen Datenbank-Trigger, der die Prozedur aufruft, die den Cache aufruft. Und das kann Daten hinzufügen, Daten aktualisieren oder Daten aus dem Cache entfernen. Das einzige, was mit dem CLR-Verfahren zu tun hat, ist, dass Sie keine … ich meine, Sie möchten Async-Anrufe tätigen. Denn wie auch immer Sie es genannt haben, es ist tatsächlich Ihre Datenbank, die jetzt ein Client des Caches geworden ist, genau wie das Gegenteil. Es wird also versucht, etwas zu aktualisieren, das hier reinkommt, und dann könnte es repliziert werden. Das alles passiert also innerhalb einer Datenbanktransaktion, und wie Sie wissen, laufen Datenbanktransaktionen ziemlich schnell ab. Durch asynchrone Aufrufe können Sie also sofort den Cache-Aufruf tätigen und dann die Kontrolle zurückgeben.
Das sind also die drei Möglichkeiten, wie Sie sicherstellen können, dass ein Cache mit Ihrer relationalen Datenbank synchronisiert bleibt. Natürlich gilt die gleiche Logik für nicht relationale. Was ist, wenn sich Ihre Daten irgendwo in einer Cloud befinden? Oder es ist im Mainframe. Wissen Sie, Sie haben immer einen Webmethodenaufruf, um ihn abzurufen. Dann ggf NCache Zumindest können Sie eine benutzerdefinierte Abhängigkeitsfunktion haben, bei der Ihr Code im Cache-Cluster registriert ist. NCache ruft es alle, sagen wir, 15 Sekunden auf und sagt, gehen Sie vor und überprüfen Sie bitte Ihre Datenquelle und sehen Sie, ob sich diese Daten geändert haben. Wenn dies der Fall ist, lösen Sie ein Ereignis aus, und dann tritt dieselbe Logik ein.
Also nochmal hält den Cache frisch ist das Wichtigste in einem verteilten Cache. Wenn Sie den Cache nicht frisch halten können, ist er in seiner Verwendung sehr eingeschränkt.
Durchlesen und Durchschreiben
Es gibt noch ein weiteres Feature namens Durchlesen und Durchschreiben. Read-Through ist eine Funktion, die wiederum eine sehr nützliche, sehr mächtige Funktion ist. Es ist im Wesentlichen wieder Ihr Code, der auf dem Cache-Server ausgeführt wird. Wo ist es? Hier. Nehmen wir also an, Sie implementieren eine Read-Through-Schnittstelle für den Fall von NCache. Jetzt ist Read-Through/Write-Through ein Konzept, das von implementiert wird NCache. Es wird auch von vielen Java-Playern implementiert, jedoch auf der .NET-Seite NCache ist der einzige der es hat. Die Durchleseschnittstelle ist also im Wesentlichen Ihr Code. Es hat eine Init-Methode, eine Dispose-Methode, also Connect und Disconnect und dann eine Load-Methode.
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...Es gibt Ihnen einen Schlüssel und basierend auf dem Schlüssel sollen Sie herausfinden, wohin Sie gehen und die Daten erhalten müssen. Und Sie geben nicht nur die Daten zurück, sondern auch einige der Metadaten, wie Ablaufzeiten und andere Dinge. Welchen Wert hat das Durchlesen? Also, dieser Code ist wieder etwas, das Sie implementieren und auf dem registrieren … Also ist es dieser Code, der hier auf dem Cache-Server läuft. Wir haben also über eine benutzerdefinierte Abhängigkeit gesprochen. Wenn Sie also über eine benutzerdefinierte Datenquelle verfügen, ist dies ein Code, der auf dem Cache-Server ausgeführt wird, und das Durchlesen wird ebenfalls auf dem Cache-Server ausgeführt.
Wozu ist das Durchlesen gut? Warum sollten Sie ein Durchlesen verwenden? Es gibt zwei oder drei Vorteile. Erstens konsolidieren Sie Ihren gesamten Persistenzcode an einem Ort. Wenn Sie also mehrere Anwendungen haben, die den Cache verwenden, sagen wir, Sie haben mehrere Anwendungen, wissen Sie, dass nicht alle diesen Code immer wieder implementieren müssen. Es wird also im Cache-Server selbst aufbewahrt. Das ist der erste Vorteil. Der zweite Vorteil ist, dass, wenn Sie etwas verfallen lassen, sagen wir, Sie verfallen etwas aufgrund von Verfallszeiten oder wegen der Datenbanksynchronisierung, anstatt dieses Element aus dem Cache zu entfernen, warum laden Sie es nicht einfach neu. Denn wenn Sie es entfernen, wird es das nächste Mal, wenn die Anwendung es wünscht, es sowieso neu laden. Sie können also das Read-Through damit abbilden lassen und sagen, wo der Cache OK sagt, wenn dieses Element abläuft oder wenn es … Wenn es sich um eine automatische Synchronisierung handelt und ich es entfernen muss, rufe ich stattdessen einfach das Read-Through auf. Warum ist es also gut, das Read-Through anzurufen? Ich meine, was ist die große Sache? Warum nicht einfach von der Anwendung neu laden? Nun, wenn Sie eine stark frequentierte Anwendung haben, besteht die Möglichkeit, dass viele Benutzer nach denselben Daten fragen werden. Sie haben Hunderttausende dieser Artikel und alle laufen zu ihrer eigenen Zeit ab. Jedes Mal, wenn ein Artikel abläuft, gehen Hunderte, wenn nicht Tausende von Anfragen für denselben Artikel in die Datenbank ein. Und das wird alles gehen und den Cache erneut aktualisieren. Daher wird viel unnötiger Datenverkehr zur Datenbank geleitet. Was, wenn Sie ein Read-Through hätten, es den Cache niemals verlassen würde. Es bleibt immer im Cache und irgendwann wird es einfach aktualisiert. Der Datenverkehr zur Datenbank findet also nie statt.
Die zweite Funktion ist Write-Through, das genau wie Read-Through funktioniert, außer natürlich zum Schreiben. Also, lassen Sie mich Ihnen das zeigen. Zum Beispiel haben Sie hier wieder das Init, Sie haben das Dispose, aber jetzt haben Sie ein Write und geben Ihnen das eigentliche Objekt und dann könnte das Write entweder Add, Update oder Remove sein, richtig. Alle drei heißen also schreiben. Je nachdem, um welchen Vorgangstyp es sich handelt, aktualisieren Sie also Ihre Datenbank oder Ihre Datenquelle.
#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
bool result = false;
OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
Customer value = (Customer)operation.ProviderCacheItem.Value;
if (value.GetType().Equals(typeof(Customer)))
{
result = sqlDatasource.SaveCustomer((Customer)value);
}
if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
return operationResult;
}
public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
throw new Exception("The method or operation is not implemented.");
}Jetzt hat das Durchschreiben einen weiteren Vorteil. Es hat den gleichen Vorteil wie Read-Through in Bezug auf die Gemeinsamkeit des Codes. Der zweite Vorteil von Write-Through wird als Write-Behind bezeichnet. Welches ist, können Sie aktualisieren. Es gibt also eine Funktion namens Write-Behind, mit der Sie den Cache sofort synchron aktualisieren können, die Datenbankaktualisierungen jedoch asynchron erfolgen. Warum ist das gut so? Nun, weil diese Datenbank langsam ist. Wenn Sie also sicher sind, dass die Datenbankaktualisierung rechtzeitig durchgeführt wird, ist es vorhersehbar, warum Sie sie nicht einfach in die Warteschlange stellen. Es wird in die Warteschlange gestellt und der Cache führt diese Operation tatsächlich im Hintergrund aus. Diese Warteschlange wird auch auf mehr als einen Server repliziert. Wenn also ein Server ausfällt, geht die Warteschlange nicht verloren.
Ich denke, alles, was Sie im Zusammenhang mit Skalierbarkeit sehen müssen. Was auch immer schnell ist, selbst wenn es sich um eine In-Memory-Datenbank handelt, es befindet sich alles auf einem Server. Je mehr Aktualisierungen gesendet werden, desto mehr Lesevorgänge werden gesendet, je mehr Last in die Datenbank gesteckt wird, desto langsamer wird sie. Genauso wie Single Point of Failure. Das ist es. Das ist der wahre Grund, warum all dies existiert, und im Kontext all dieses Existierens erhalten Sie alle zusätzlichen Vorteile. Wenn Sie eine Write-Behind-Funktion hatten, muss Ihre Anwendung plötzlich nur noch den Cache synchron aktualisieren. Denn sobald der Cache aktualisiert ist, kümmert sich der Cache asynchron um die Datenbankaktualisierung. Und diese Warteschlange hat ihre eigene Optimierung. Es kann Massenaktualisierungen durchführen, es kann replizieren. Write-Behind hat also die Leistung, der Geschwindigkeitsteil, über den Sie gesprochen haben, ist relevanter für Write-Through und Write-Behind als für Read-Through.
Read-Through ist auch etwas, das in einigen Fällen möglicherweise schneller ist als der Zugriff der Anwendung, aber beim Write-Behind ist es definitiv immer schneller.
Irgendwelche Fragen? Ich habe nur noch ein paar Minuten. Ich werde noch über ein weiteres Feature sprechen und dann zum Ende gehen. Also, Leute, die es gewohnt sind, eigenständiges In-Proc-In-Memory-Caching wie ASP.NET-Cache-Objekte durchzuführen, rufen uns viele unserer Kunden an, wenn sie zu einem verteilten Cache wechseln, und sagen, Sie haben versprochen, dass der Cache es tun wird tatsächlich meine Leistung verbessern. Meine Leistung ging tatsächlich zurück. Warum ist das so? Kann jemand erraten? Warum verlangsamt sich das eigentlich, sobald Sie zu einem verteilten Cache im Vergleich zu einem In-Proc-Cache wechseln? Netzwerk-Latenz. Netzwerklatenz ist eins. Ein größeres Problem ist die Serialisierung und Deserialisierung, die enorme Kosten verursacht.
Client-Cache oder Near-Cache
Also, was einige der verteilten Caches tun, einschließlich NCache, implementieren sie dieses Ding namens a Client-Cache, manche nennen es Near Cache. Es ist eine Teilmenge dieses Caches, die innerhalb des Anwendungsservers gehalten wird. Es kann sogar In-Proc oder OutProc sein. Aber oft ist es In-Proc. Es bietet Ihnen also den gleichen Vorteil wie ein eigenständiger In-Proc-Cache, außer dass es mit diesem synchronisiert wird.
Und dies ist eine kleinere Teilmenge, also sagen wir, dies könnten 16 GB pro Server sein, dies könnte nur ein GB sein. Und es ist ein sich bewegendes Fenster, richtig? Also, was auch immer Sie zwischenspeichern, wird behalten und dann, wenn Sie weitermachen, laufen die älteren Elemente entweder ab oder sie werden entfernt und dann werden neue Daten zwischengespeichert.
Ein Client-Cache gibt Ihnen also die wirkliche Leistung. Es hält Daten in einer Objektform innerhalb des Bewerbungsprozesses. Wenn Sie es also hunderte oder zehnmal abrufen, müssen Sie es natürlich beim ersten Mal aus dem verteilten Cache abrufen. Vielleicht holen Sie es beim ersten Mal aus der Datenbank. Es geht zum verteilten Cache und dann zum Client-Cache, aber sobald das erledigt ist, werden alle weiteren Lesevorgänge in Ihrem eigenen Heap durchgeführt, was superschnell ist. Das ist also eine Funktion, die wirklich mächtig ist. Davon wollen Sie unbedingt profitieren.
Es gibt also ein paar Dinge, auf die Sie achten müssen. Ein verteilter Cache läuft genau wie eine Datenbank in Ihrem Rechenzentrum in Ihrer Produktionsumgebung. Es muss also einige der architektonischen Anforderungen erfüllen. Es muss eine hohe Verfügbarkeit haben. Es muss Datenzuverlässigkeit und Skalierbarkeit bieten. Daher muss es eine intelligente Replikation durchführen.
Ich werde hier nicht auf die Details eingehen. Da kann man reinschauen. Sie können die Recherche online durchführen. Wenn Sie beispielsweise mehrere Rechenzentren haben, erwarten Sie, dass Ihre Datenbank repliziert wird, warum nicht auch der Cache? Du weisst. Warum sollte der Cache nicht auch über mehrere synchronisiert verfügbar sein… Also, ja, ein guter Cache sollte es sein.
.NET Distributed Caching-Optionen
Wenn Sie .NET-Anwendungen machen, wissen Sie, dass es zu diesem Zeitpunkt so ziemlich zwei Optionen gibt, die Sie für das Caching haben. Einer ist Redis die Microsoft auf Azure gesetzt hat. Der Andere ist NCache. Auf der Java-Seite gibt es, wie gesagt, eine Reihe von Spielern, die ziemlich gut sind.
Ich möchte also nur einen Vergleich auf wirklich hohem Niveau durchführen.
NCache ist der älteste .NET-Cache. Es ist seit 2005 auf dem Markt. Es ist natives .NET. Es ist auch Open Source, genau wie Redis. Es ist auch auf Azure oder Amazon verfügbar. Redis … Es gibt also zwei Versionen von Redis, eine, die von entwickelt wird Redis Labs, das nur unter Linux läuft. Tatsächlich verwendet Microsoft diese Version in Azure. Und die Version, die Microsoft auf Windows portiert hat, verwenden sie nicht einmal selbst. Tatsächlich haben wir viele Beschwerden von Kunden gehört. Es ist nicht sehr stabil. Aber außerhalb von Azure ist die einzige Version, die Sie für Windows haben, die, die Microsoft portiert hat, MS Open Tech. Aber ansonsten, wenn Sie gehen Redis Sie geben Ihnen nur die Linux-Version. Auf Azure selbst gibt es zwei Unterschiede zwischen NCache und Azure, das ist das NCache gibt Ihnen tatsächlich einen Cache-Server als VM. Sie können also den ganzen serverseitigen Code selbst ausführen und die Dinge überwachen. Redis bietet Ihnen Cache als Service. Der Cache ist also eine Blackbox. Sie haben nur eine sehr einfache API, die Sie aufrufen. Und die Einschränkung besteht darin, dass Sie nicht alle Funktionen erhalten, über die wir gerade gesprochen haben. Wie führen Sie eine Datenbanksynchronisierung durch? Read-Through-Write-Through. Eigentlich habe ich mich nicht einmal mit der SQL-Suche befasst, weil wir keine Zeit hatten. Dies sind also die zwei Möglichkeiten, wie Sie dies tun können. Wenn Sie mehr darüber erfahren möchten, besuchen Sie unsere Website und wir haben eine vollständige ausführliches Vergleichsdokument. Also, wenn ich hineingehen würde Redis vs NCache Hier können Sie ein vollständiges Dokument sehen. Sie können es auch herunterladen. Es ist ein Feature-by-Feature-Vergleich basierend auf ihrer und unserer Dokumentation, und dann können Sie sehen, welche Ihren Anforderungen entspricht. Irgendwelche Fragen? Das ist das Ende meines Vortrags. Danke.
Gibt es eine Abhängigkeit von .NET Core Framework oder können Sie es mit .NET 4.0 verwenden? Gute Frage. So, NCache Server unterstützt .NET frameworks. Es ist 4.0 oder höher. Das NCache Client ist standardmäßig .NET framework selbstverständlich. Wir stehen kurz vor der Veröffentlichung von .NET …. Also unterstützen wir ASP.NET Core. Also, die .NET Core das unter Linux laufen kann, unterstützen wir noch nicht, da es Einschränkungen hat. Aber die .NET Core das läuft auf ASP.NET framework, darunter nur unter Windows, insbesondere ASP.NET Core NCache wird es unterstützen. Vielen Dank Jungs.