Vortrag bei Live 360 Orlando 2016
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
Was ist Skalierbarkeit?
Beginnen wir also mit einigen Definitionen. Ich bin mir sicher, dass die meisten von Ihnen das bereits wissen, aber wir werden es der Vollständigkeit halber nur durchgehen. Die erste Definition ist Skalierbarkeit. Was ist also Skalierbarkeit? Oft wird Skalierbarkeit mit Leistung verwechselt. Bei der Leistung handelt es sich um eine wirklich schnelle Reaktionszeit pro Anwendung, aber das könnte auch bei nur fünf Benutzern der Fall sein. Wenn Sie die Zahl von fünf Benutzern auf fünftausend oder 50,000 Benutzer erhöhen und die Leistung gut bleibt, ist Ihre Anwendung skalierbar. Das ist der Kern dessen, was wir erreichen wollen.
Egal welche Anwendung Sie haben: Wenn Sie die gleiche Leistung wie mit fünf Benutzern oder einer wirklich geringen Transaktionslast erreichen können, wenn Sie die gleiche Leistung mit hoher Transaktionslast erreichen können, dann sind Sie skalierbar. Wenn Sie mit fünf Benutzern keine gute Leistung erzielen, liegen andere Probleme vor.
Lineare Skalierbarkeit
Lineare Skalierbarkeit ist eher eine Infrastrukturdefinition. Das heißt, wenn Ihre Anwendung so konzipiert ist, dass das Hinzufügen weiterer Server zur Bereitstellung, sei es das Hinzufügen weiterer Anwendungsserver oder Datenbankserver oder was auch immer, die Transaktionskapazität linear erhöhen kann Mode dann haben Sie eine linear skalierbare Anwendungsarchitektur.
Wenn Sie dazu jedoch nicht in der Lage sind und das Hinzufügen weiterer Server keinen Mehrwert bringt, liegt ein grundlegender Fehler vor und Sie können die Anwendung nicht linear skalieren. Das Ziel hier ist natürlich, linear skalieren zu können.
Nichtlineare Skalierbarkeit
Nichtlinear wäre, wenn Sie eine Steigerung feststellen, wenn Sie weitere Server hinzufügen, aber ab einem bestimmten Punkt danach keine weitere Steigerung mehr zu verzeichnen ist. Tatsächlich kommt es zu einem Leistungsabfall, selbst wenn weitere Server hinzugefügt werden, da es aufgrund der Architektur der Anwendung und der Bereitstellung zu einigen Engpässen kommt die du einfach nicht überwinden kannst.
Welche Anwendungen benötigen Skalierbarkeit?
Dabei handelt es sich in der Regel um Webanwendungen.
Das sind also ASP.NET für.NET-Leute, Webdienste, Back-End für das Internet der Dinge, das ein sehr stark aufstrebender Bereich ist, und die Verarbeitung großer Datenmengen. Die Verarbeitung großer Datenmengen ist auf der Java-Seite häufiger anzutreffen. Auf der .NET-Seite machen das nicht viele Leute, aber die Big-Data-Verarbeitung ist auch ein anderer Bereich. Und bei jeder anderen Serveranwendung könnte dies Ihre Stapelverarbeitungsanwendung sein. Sie sind möglicherweise ein Finanzdienstleistungsunternehmen und haben Millionen von Kunden, die anrufen und ihre Adressen ändern, oder vielleicht überweisen sie Gelder von einem Konto auf das andere und Sie haben bestimmte Compliance-Anforderungen, und zwar bis mitten in der Nacht oder so etwas Um diese Verarbeitung abzuschließen, findet im Backend in gewisser Weise eine Stapelverarbeitung in einem Workflow statt. Daher benötigen alle anderen Serveranwendungen, die unter Zeitdruck stehen, um eine bestimmte Anzahl von Transaktionen durchzuführen, Skalierbarkeit.
Skalierbarkeitsproblem
Wo liegt also das Skalierbarkeitsproblem? Wir haben über lineare und nichtlineare Skalierbarkeit gesprochen. Das Skalierbarkeitsproblem besteht also darin, dass die Anwendungsebene auf sehr schöne lineare Weise skaliert. Wenn Sie eine Webanwendung oder Webdienste haben, also Ihre Anwendungsebene, fügen Sie einfach weitere Server hinzu, kein Problem. Der Flaschenhals ist der Datenspeicher. Und wenn ich das Wort Datenspeicherung sage, meine ich relationale Datenbanken und Mainframe-Altdaten. Ich meine nicht NoSQL database. NoSQL databases sind großartig. Wir haben auch eine NoSQL Produkt genannt NosDB Aber keine SQL-Datenbanken sind nicht immer die Antwort. Sie sind eine Antwort, wenn Sie umso mehr Daten verschieben können, zu denen Sie wechseln NoSQL database ist die Skalierbarkeitslösung, die Sie erhalten. Das Problem besteht jedoch darin, dass Sie nicht alle Daten dorthin verschieben können NoSQL. Es gibt viele Daten, die aus technischen und geschäftlichen Gründen relational bleiben müssen.
Daher sind relationale Datenbanken von Dauer. Sie werden in Bezug auf dieses Problem nirgendwo hingehen. Sie müssen also diese Realität umgehen oder mit der Realität umgehen, dass Sie mit relationalen Datenbanken arbeiten werden, und trotzdem müssen Sie dieses Problem lösen. Und der Grund, warum Sie dieses Problem lösen müssen, ist, dass Sie alle von mir erwähnten Anwendungen haben, die Skalierbarkeit benötigen.
Verteilte Cache-Bereitstellung
Und die Antwort besteht natürlich darin, einen verteilten Cache zwischen der Anwendungsschicht und der Datenbankschicht einzufügen.
Ein verteilter Cache ist also im Wesentlichen ein sehr leistungsfähiges und dennoch sehr einfaches Konzept. Sie verfügen über zwei oder mehr kostengünstige Server, die zu einem Cluster zusammengefasst sind. Dieser Cluster bündelt den Arbeitsspeicher und die CPU-Ressourcen aller Server in einer logischen Kapazität. Der Engpass und die Skalierbarkeit treten in drei Bereichen auf. Einer ist der Speicher, der zweite ist die CPU, der dritte ist die Netzwerkkarte.
Wenn Sie also, sagen wir, hier einen Datenbankserver haben und 20 Anwendungsschichtboxen haben, die ein Datenbankserver in Bezug auf die Hardwarestärke in Anspruch nehmen kann, können Sie mehr Speicher und viel mehr CPUs hinzufügen, aber Dafür gibt es eine Grenze. Die Antwort lautet also: Um immer mehr Server zu haben, die nicht sehr hochwertig sind, sollten sie per Definition eigentlich auch nicht hochwertig sein. Und was wir in den letzten 10 oder mehr Jahren dabei beobachtet haben, ist, dass die häufigste Konfiguration ein gleichwertiger Dual-CPU-Quad-Core-Typ ist. Nehmen wir an, eine 8-Core-Box und eine 16-Core-Box sind eigentlich eine ziemlich hochwertige Konfiguration für einen Caching-Server. 8-Kerne sind so ziemlich die gängige Variante.
Speicher, natürlich braucht man viel Speicher, denn Speicher ist billig, also ist das kein großer Faktor. Sie benötigen viel Arbeitsspeicher, denn der Cache ist ein In-Memory-Speicher, also speichert er alles im Arbeitsspeicher. Eine typische Konfiguration würde etwa 16 bis 32 GB Arbeitsspeicher in jedem Cache-Server umfassen und 2 Cache-Server sind das Minimum, das Sie haben sollten aus Redundanzgründen. Mit dieser Architektur befinden Sie sich nun in einer Situation, in der Sie der Anwendungsebene weitere Server hinzufügen müssen. Sie fügen der Caching-Ebene proportional weitere Server hinzu. Normalerweise ist es also ein Verhältnis von 4 zu 1 oder 5 zu 1, was wir als das praktischste angesehen haben. In einigen Fällen können Sie viel mehr als 5 zu 1 verwenden. Das bedeutet 5 Anwendungsserver zu 1 Caching-Server, aber es gibt keine Begrenzung für die Anzahl der Server, die Sie haben können. Sie können 2, Sie können 4, 10, 20, 30 Server haben, aber damit Sie hier 20 Server haben, benötigen Sie wahrscheinlich hundert Server in der Load-Balancer-Umgebung.
Irgendwann wird das so ziemlich zu einer High-End-Anwendung, die wir im Web oder im E-Commerce- oder Online-Business-Szenario gesehen haben. Durch das Hinzufügen weiterer Server ist dies also kein Engpass mehr. Das verteilte Caching wird also tatsächlich zu einer bewährten Methode. Wenn Sie Skalierbarkeit benötigen. Denn jetzt verfügen Sie nicht nur über eine Datenbank, die für ihren eigenen Zweck da ist, sondern Sie benötigen auch eine permanente Datenspeicherpersistenz für alle Anwendungsdaten, sondern Sie verfügen auch über diese wirklich sehr schnelle und skalierbare Infrastruktur, die jetzt Teil Ihrer Anwendungsarchitektur ist. Wenn Sie also programmieren, programmieren Sie nicht mehr nur für die Datenbank. Sie denken immer an einen Cache, weil der Cache jetzt dafür sorgt, dass Ihre Anwendung auch bei Spitzenlasten nie langsamer wird. Auch wenn die Datenbank nicht auf die gleiche Skalierung ausgelegt ist. Das ist also ein typisches Bild.
Ungefähr 80 % des Datenverkehrs bleiben hängen oder werden in 80 % der Zeit in den Cache und in 20 % der Zeit in die Datenbank verlagert. Bei diesen 20 % handelt es sich hauptsächlich um Aktualisierungen und natürlich um einige Lesevorgänge, die auf Sie zurückzuführen sind Sie müssen Daten in den Cache laden, aber Sie können den Cache auch vorab füllen, und es gibt viele andere Möglichkeiten, dies zu tun. Durch die drastische Reduzierung des Datenverkehrs auf der Datenbankebene erreichen Sie jedoch Leistung und Skalierbarkeit.
Das trifft also auf die Verwendung eines verteilten Caches zu. Warum Sie dies als Teil Ihrer Anwendungsarchitektur behalten müssen.
Häufige Anwendungsfälle
Nachdem wir uns nun sozusagen für die Verwendung eines verteilten Caches ausgesprochen haben, lautet die nächste Frage: Wie nutzt man ihn? Wo verwenden Sie es?? Welche Art der Nutzung sollte ein verteilter Cache haben?
Zwischenspeichern von Anwendungsdaten
Nun, die häufigste Verwendung ist das Zwischenspeichern von Anwendungsdaten. Hier werden, wie ich gerade erwähnt habe, alle Daten, die Sie in der Datenbank haben, zwischengespeichert. Damit Sie nicht in die Datenbank gehen müssen. Beachten Sie, dass die Daten in einem Anwendungsfall für die Zwischenspeicherung von Anwendungsdaten an zwei Orten vorhanden sind. Auf diesen Punkt werde ich in den Folgefolien ausführlicher eingehen. Einer befindet sich in der Datenbank, wo er immer sein muss, und der zweite ist der Cache. Wenn also Daten an zwei Orten vorhanden sind, welches ist das erste Problem, das Ihnen in den Sinn kommt? Synchronisierung! Ja.
Jeder Cache, der diese Situation nicht bewältigen kann, zwingt Sie also dazu, schreibgeschützte Daten zwischenzuspeichern, Daten, von denen Sie wissen, dass sie sich nie ändern werden. Wenn man über Cache spricht, denken die meisten Menschen reflexartig: Warum ist er für schreibgeschützte Daten gedacht? Ich möchte meine Kunden und Konten und Daten, die sich alle 30 Sekunden ändern, wirklich nicht zwischenspeichern. Die Forschung zeigt jedoch, dass die größte Verwendung eines Caches in den Transaktionsdaten liegt und dass Sie ihn, sobald Sie ihn zwischengespeichert haben, wahrscheinlich in den nächsten ein oder zwei Minuten benötigen, unabhängig von der Aktivität, unabhängig von dem sich bewegenden Zeitfenster Ihrer Nutzung. Dann benötigen Sie erneut dieselben Daten, und wenn Sie sie aus dem Cache abrufen können, reduzieren Sie die Anzahl der Fahrten zur Datenbank und multiplizieren diese mit Millionen von Transaktionen, die in Ihrer Anwendung stattfinden, und das führt zu einer ziemlich erheblichen Steigerung. Behalten Sie dieses Problem also im Hinterkopf, denn jeder gute Cache muss damit sehr, sehr effektiv umgehen.
ASP.NET-spezifisches Caching
Der zweite Anwendungsfall besteht darin, dass bei einer ASP.NET-Anwendung viele vorübergehende Daten vorhanden sind. Transient bedeutet temporär und dass man sie in den Cache legen kann und diese Daten eigentlich nicht in die Datenbank gehören. Beispielsweise ist eine Datenbank dauerhaft vorhanden. Es ist ein permanenter Laden. Das ist Ihr Stammdatensatz. Also, a Sitzungsstatus, Sie müssen es wahrscheinlich nur so lange aufbewahren, wie der Benutzer angemeldet ist, vielleicht 20 Minuten danach, wissen Sie. Warum also in der Datenbank behalten? Die Datenbank ist nicht so schnell. Relationale Datenbanken sind nicht für die Speicherung von Blobs konzipiert und Sitzungen werden normalerweise als Blobs gespeichert. Wenn Sie Sitzungen in der Datenbank speichern, kommt es also zu großen Leistungseinbußen. Daher ist der Sitzungsstatus ein sehr guter Anwendungsfall für ASP.NET, um ihn im verteilten Cache abzulegen.
Und wenn Sie das MVC-Framework nicht verwenden, gibt es auch den Ansichtsstatus, einen ziemlich umfangreichen Datenteil, der nur zu einem Zweck vom Webserver zum Browser fließt, nämlich um bei einem Postback zum Browser zurückzukehren. Es ist also eine ziemlich lange Reise, umsonst, wie man sagt. Es wäre also viel schöner, wenn Sie es einfach auf der Serverseite belassen und nur einen kleinen Schlüssel senden würden. Das ist also ein sehr, sehr guter Anwendungsfall für Caching.
Der dritte Anwendungsfall ist die Seitenausgabe. Die Ausgabe vieler Ihrer Seiten ändert sich nicht jedes Mal. Wenn es sich also nicht ändert, warum dann die Seite ausführen, denn wenn Sie die Seite ausführen, verbrauchen Sie CPU, Speicher und alle anderen Ressourcen? Warum nehmen Sie nicht einfach die Ausgabe der letzten Ausführung und zeigen sie an? Daher verfügt Microsoft oder ASP.NET über ein Ausgabe-Cache-Framework, in das Sie einen verteilten Cache einbinden können. In diesem Anwendungsfall, in diesen drei Anwendungsfällen unter ASP.NET, hat sich die Art des Problems nun völlig geändert. Es gibt keine Synchronisierung mehr zwischen dem Cache und der Datenbank. Warum? Weil es keine Datenbank gibt. Cache ist die Datenbank.
Die Natur des Problems liegt nun darin, dass sich der Cache im Speicher befindet, in Ordnung? So erhalten Sie die volle Leistung. Wenn Sie also Daten im Speicher aufbewahren und dies der einzige Speicher ist, was ist dann Ihre größte Sorge? Du könntest es verlieren! Was passiert, wenn die Box neu startet? Es ist bekannt, dass Windows Arbeitsprozesse neu startet oder wiederverwendet. Was wäre, wenn und ich meine, selbst wenn eine Linux-Box neu starten müsste, aber was wäre, wenn Ihre Box neu starten würde? Sind Sie bereit, diese Daten zu verlieren? Was wäre, wenn Sie eine Fluggesellschaft wären und dieser Kunde auf der letzten Seite, auf der er auf „Einreichen eines 5,000-Dollar-Tickets“ klickte, das Familienurlaubsticket für Hawaii kaufen wollte, und plötzlich heißt es: „Tut mir leid, dass Sie noch einmal von vorne anfangen müssen!“ Wissen Sie, sie haben alle Arten von Flugrecherchen und Check-Zeiten durchgeführt und auch Google-Flüge durchgeführt, um zu sehen, welche übereinstimmen und all das andere Zeug, also keine gute Erfahrung.
Als Unternehmen möchten Sie keine Kunden verlieren, den Warenkorb möchten Sie nicht verlieren. Die Antwort darauf ist ein verteilter Cache. Sie sollten Sitzungen oder alle diese vorübergehenden Daten nur dann darin behalten, wenn dies die Zuverlässigkeit gewährleisten kann, wenn es sicherstellt, dass Sie diese Daten niemals verlieren, und wenn es dafür sorgt, dass die Replikation durchgeführt wird. Ein guter verteilter Cache führt also eine Replikation von Daten auf mehreren Servern durch. Nun ist die Replikation eigentlich Zeitverschwendung, es ist eine zusätzliche Sache, die nur für den Notfall erledigt wird, über den wir gerade sprechen. Der Nachteil der Replikation besteht also darin, dass sie einen Leistungseinbruch mit sich bringt. Wenn also ein Cache dies nicht intelligent erledigt, was bei vielen anderen nicht der Fall ist, wird es beim Einschalten der Replikation zu Leistungseinbußen kommen.
Gemeinsame Nutzung von Laufzeitdaten durch Ereignisse
Denken Sie also an diese beiden Punkte. Der dritte Anwendungsfall ist etwas, von dem die meisten Menschen nicht wissen, dass es sich bei einem verteilten Cache, sobald Sie diese Infrastruktur in Ihrer Umgebung haben, um eine sehr leistungsstarke ereignisgesteuerte Datenaustauschplattform handelt. Daher verfügen Sie möglicherweise über mehrere Anwendungen, die Daten in einem Arbeitsablauf gemeinsam nutzen müssen. Möglicherweise haben Sie eine Situation vom Typ Pub/Sub, für die Sie wahrscheinlich einen Nachrichtenbus, einen Enterprise Service Bus oder eine Nachrichtenwarteschlange verwenden werden. Ein verteilter Cache ist hierfür eine sehr leistungsstarke Plattform. Da Sie es bereits intern haben, ist es tatsächlich schneller und skalierbarer als die anderen Optionen, da es auf Leistung ausgelegt ist, während die anderen Anwendungen eher auf die gemeinsame Nutzung ausgelegt sind.
Also ereignisgesteuerter Pub/Sub-Typ einer gemeinsamen Nutzung zwischen mehreren Anwendungen. Eine Anwendung erzeugt einige Daten, legt sie im Cache ab und löst ein Ereignis aus. Es gibt andere Anwendungen, die Interesse an diesem Ereignis angemeldet haben, sodass ich diese Daten nutzen möchte, wann immer sie mir zur Verfügung stehen. Sie empfangen also das Ereignis und wieder könnte eine Anwendung hier sein, eine Anwendung könnte hier sein. Dies wird zu einer sehr, sehr leistungsstarken skalierbaren Ereignis-Engine, auf die sie alle zugreifen können.
Das ist also ein dritter Anwendungsfall. Selbst in dem Fall, dass in der Laufzeit-Datenfreigabefunktion oder im Anwendungsfall die meisten Daten vorübergehend sind. Es wird zwar aus permanenten Daten abgeleitet und könnte wahrscheinlich aus diesen permanenten Daten neu erstellt werden, aber es ist eine Menge Arbeit, dies zu tun, und diese Daten befinden sich normalerweise in diesem temporären Zustand, weil es ihrer Natur nach temporär ist. Dies ist normalerweise nicht der Fall, es muss nicht in der Datenbank gespeichert werden. Es muss nur verzehrt werden. Der Cache ist also wieder der einzige Speicher, der es sein wird, und genau wie bei den Sitzungen und anderen sind die Probleme die gleichen, die die Zuverlässigkeit zum Tragen bringen müssen. Das sind also die drei gängigen Arten, wie Sie einen verteilten Cache verwenden würden.
Das Schöne an diesen drei Anwendungsfällen ist, dass dafür keine Programmierung erforderlich ist, da der ASP.NET framework ermöglicht Ihnen die Einbindung eines Drittanbieters. Wenn Sie also zum Beispiel Sitzungen haben, zeige ich Ihnen schnell ein kurzes Beispiel, bei dem Sie lediglich zur Webkonfiguration und natürlich zum ASP gehen.NET core, dieses Paradigma wird sich leicht ändern, aber die Idee ist dieselbe.
Konfigurieren des ASP.NET-Sitzungscachings
Wenn Sie also zur Web.config gehen, ist dies nur eine einfache ASP.NET-Anwendung. Wenn Sie zu Web.config gehen, müssen Sie zunächst die Assembly des Caches hinzufügen, den Sie verwenden möchten NCache, Sie werden einfach die Add-Assembly auf dem ausführen NCache Session-Store-Anbieter und kopieren Sie einfach den Einfügen-Befehl. Als Zweites müssen Sie hier Änderungen vornehmen.
Daher gibt es in der Webkonfiguration ein Sitzungsstatus-Tag, bei dem Sie sicherstellen müssen, dass der Modus benutzerdefiniert ist und die Zeitüberschreitung Ihrem tatsächlichen Zeitlimit entspricht. Und im Falle von NCache, dann müssen Sie eigentlich nur diese Zeile hinzufügen und es gibt eine Reihe anderer Parameter, die Sie angeben können, auf die ich nicht näher eingehen werde, aber einer davon betrifft nur den Namen des Caches. Im Falle von NCache, alle Caches sind benannt und ich werde Ihnen tatsächlich auch eine Demo davon geben, aber. Sie geben also einfach den Namen des Caches an. Der Cache ist bereits erstellt. Das ist wie eine Verbindungszeichenfolge, die Ihnen sagt, zu welchem Cache Sie eine Verbindung herstellen müssen, da Sie möglicherweise mehrere Caches haben, einen für Sitzungen, einen für Anwendungsdaten und das ist alles. Ich meine, Sie nehmen diese Änderung vor und führen einfach einen Plausibilitätstest durch, gehen alle gängigen Anwendungsfälle Ihrer Anwendung durch und Ihre Anwendung ist plötzlich bereit, Sitzungen in einem zu speichern verteilter Cache ähnlich NCache. Der einfachste Weg, davon zu profitieren und den größten Gewinn zu erzielen, sind Sitzungen.
Das ist also alles, was Sie für die Verwendung des Sitzungsstatus in einem verteilten Cache tun müssen NCache oder irgendein anderes und das Gleiche gilt für den View-State-Ausgabecache. Es ist alles eine konfigurationsbasierte Änderung. Ich werde nicht auf jeden Einzelnen näher eingehen. Ich wollte Ihnen das nur als Beispiel zeigen.
App-Daten-Caching
Kommen wir also zum Kern eines verteilten Caches, und ich sage „Herz“, denn dort werden Sie die meiste Zeit verbringen. Wenn Sie sich für die Integration eines verteilten Caches entscheiden, verbringen Sie die meiste Zeit mit dem Zwischenspeichern von Anwendungsdaten. Wie sieht also eine typische API aus?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Wenn Sie das ASP.NET-Cache-Objekt kennen, NCache versucht es so nah wie möglich nachzuahmen, obwohl wir eine Obermenge sind, also gibt es noch mehr. Jeder Cache hat seine eigene API. Das ist es, was ein NCache API sieht aus wie. Wenn Sie eine Verbindung zum Cache herstellen, handelt es sich um einen benannten Cache. Sie erhalten ein Cache-Handle, behalten dieses Cache-Handle bei und führen innerhalb der Anwendung, die Sie behalten, einfach Cache.Get aus. Holen, Enthält, Hinzufügen, Einfügen, Entfernen, es gibt auch Asynchron hinzufügen, Asynchron einfügen. Einfügen bedeutet hinzufügen, wenn es nicht existiert, oder aktualisieren, wenn es bereits existiert. Das ist die gleiche Terminologie, die Sie für das ASP.NET-Cache-Objekt verwenden, deshalb haben wir sie auch verwendet. Und die Async-Methode bedeutet im Grunde, dass Sie nicht warten müssen, bis dieser Vorgang abgeschlossen ist. Tatsächlich gibt es einen dritten Parameter, mit dem Sie einen Rückruf angeben können. Ihr Rückruf wird also angerufen, falls etwas schief geht, sonst können Sie davon ausgehen, dass alles gut gelaufen ist.
Halten Sie den Cache frisch
Als wir hier waren, sprachen wir über das Caching von Anwendungsdaten. Die größte Sorge bestand darin, dass der Cache aktuell gehalten werden muss. Ein guter verteilter Cache muss Ihnen dies ermöglichen, denn wenn dies nicht der Fall ist, werden Sie gezwungen, schreibgeschützte Daten zwischenzuspeichern. Nur-Lese-Daten machen ohnehin etwa 10 bis 15 % Ihrer Daten aus. Wie können Sie also wirklich von diesem Cache profitieren, wenn Sie nur 10 bis 15 % von dem zwischenspeichern, was Sie zwischenspeichern sollten? Was Sie also tun möchten, ist, alle Daten zwischenzuspeichern, praktisch alle Daten, sehr, sehr wenige Datenstücke würden dort sein, wo Sie sagen, dass es wirklich keinen Sinn macht, zwischenzuspeichern. Aber fast alle Daten. Einige der Daten werden für kurze Zeit zwischengespeichert. Sobald Sie also diese Daten zwischengespeichert haben, handelt es sich hierbei ausschließlich um Anwendungsdaten. Der härteste Cache stellt sicher, dass der Cache aktuell ist. Die verschiedenen Möglichkeiten, die er erreichen kann, sind Abläufe.
Verwendung zeitbasierter Abläufe
Der Ablauf ist ein absoluter Ablauf und es gibt einen gleitenden Ablauf. Beide haben sehr unterschiedliche Bedeutungen, obwohl es sich bei beiden um Ablauffristen handelt. Um den Cache auf dem neuesten Stand zu halten, sollten Sie eine absolute Ablauffrist verwenden, da Sie vermuten, dass ich dieses Kundenobjekt im Cache speichere. Ich denke, es ist sicher, bei fünf Minuten zwischenzuspeichern. Sie machen nur eine Vermutung, die auf einer fundierten Vermutung basiert, aber es ist eine Vermutung. Innerhalb von fünf Minuten hoffen Sie, dass niemand Änderungen an der Datenbank vornimmt. Wenn dies jedoch der Fall ist, stimmt Ihr Cache nicht mit der Datenbank überein. Der gleitende Ablauf hat dagegen nichts mit der Synchronisierung des Caches zu tun. Es hat mit der Räumung zu tun oder es hat mit der automatischen Bereinigung des Caches zu tun.
Bei Sitzungen heißt es also, wenn niemand angemeldet ist, entfernen Sie die Sitzung nach 20 Minuten Inaktivität. Du machst also eine Art Aufräumarbeiten. Du sagst, der Cache, bitte räum ihn auf, räum ihn für mich auf. Ich möchte das alles nicht im Auge behalten müssen. Ich habe es in den Cache gelegt, ich habe angegeben, wie lange es im Cache bleiben soll, auch wenn niemand es berührt, und danach bereinige es. Es gibt also sehr unterschiedliche Ziele, die Sie verfolgen, vom permanenten über den absoluten Ablauf bis hin zum gleitenden Ablauf. Den gleitenden Ablauf würden Sie also für Sitzungen für vorübergehende Daten verwenden. Absoluter Ablauf, den Sie für dauerhafte Daten verwenden würden.
Ein anderer Begriff, den ich verwenden möchte, ist Referenzdaten versus Transaktionsdaten. Referenzdaten sind Daten, die sich nicht sehr häufig ändern, sich aber ändern und nicht schreibgeschützt sind. Es ist Ihre Produkttabelle, deren Preis sich jeden Tag, jede Woche oder so ändern kann, aber nicht so häufig wie ein Kundenobjekt oder ein Aktivitätsobjekt oder so etwas oder ein Bestellobjekt. Wir möchten also Transaktionsdaten zwischenspeichern. Natürlich sind Referenzdaten eine Selbstverständlichkeit, die wir zwischenspeichern wollen, aber auch Transaktionsdaten sind etwas, aus dem wir alle Daten erhalten. Wenn also der Ablauf nicht ausreicht, um sicherzustellen, dass Ihr Cache aktuell bleibt, müssen Sie über weitere Funktionen verfügen.
Verwenden von Datenbankabhängigkeiten
Die nächste Funktion, eine sehr leistungsstarke Funktion, die ein guter verteilter Cache haben muss, ist, dass er in der Lage sein sollte, den Cache mit der Datenbank zu synchronisieren, ohne Sie einzubeziehen, ohne dass Sie Dinge überwachen müssen. Sie sollten dem Cache also mitteilen können, dass ich dieses Objekt zwischenspeichere. Dies hängt mit diesem Datensatz in der Datenbank zusammen. Bitte überwachen Sie daher diesen Datensatz in der Datenbank. Überprüfen Sie, ob sich etwas ändert. Führen Sie bitte ein oder zwei Dinge aus: Entweder entfernen Sie dieses Element aus dem Cache. Das Entfernen bedeutet, dass die Anwendung es beim nächsten Mal, wenn es benötigt wird, nicht im Cache findet. Was passiert, wenn Sie es nicht im Cache finden? Sie erhalten es aus der Datenbank. Es ist also, als würde man eine neue Kopie erhalten, oder als zweites könnte es sein, dass eine neue Kopie automatisch neu geladen wird. Das automatische Neuladen einer neuen Kopie erfordert eine weitere Funktion namens „Durchlesen“, über die ich sprechen werde.
Also, ich komme noch einmal darauf zurück Datenbanksynchronisierung ist eine sehr, sehr leistungsstarke Funktion. Das gibt Ihnen die Gewissheit, dass Ihr Cache frisch bleibt. Dass Sie sich keine Gedanken darüber machen müssen, welche Daten Sie zwischenspeichern, und dass es verschiedene Möglichkeiten gibt, den Cache mit der Datenbank zu synchronisieren. Am häufigsten ist die SQL-Abhängigkeit, bei der es sich eigentlich um eine Funktion von ADO.NET oder SQL Server handelt NCache verwendet.
So zeige ich Ihnen zum Beispiel tatsächlich den Code, den ich zeigen sollte. Also, lassen Sie mich schnell... Ich werde Ihnen schnell zeigen, wie der Code aussieht. Wo ist das geblieben? Wenn Sie also eine .NET-Anwendung haben, nehmen wir an, dass dies der Fall ist NCacheNatürlich würden Sie auf zwei davon verweisen NCache Bibliotheken. NCache.Laufzeit und NCache.Netz. Deshalb haben wir erneut versucht, es so nah wie möglich am ASP.NET-Cache-Objekt-Namespace zu benennen NCache.Netz. Als wir 2005 auf den Markt kamen, war das ASP.NET-Cache-Objekt der einzige Cache, den es gab. Wir sind also die Ältesten in diesem Bereich. Deshalb haben wir diesen Namen gewählt, um es den Leuten einfacher zu machen. In die Bewerbung würden Sie also einige aufnehmen NCache Namensräume. Dann stellen Sie eine Verbindung zu Ihrem Cache her, erhalten ein Cache-Handle und haben nun ein Cache-Handle. Nehmen wir also an, Sie erstellen Ihr Objekt und möchten Cache.Add ausführen. Cache.Add benötigt also einen Schlüssel. Beachten Sie, dass es sich bei dem Schlüssel tatsächlich um eine Zeichenfolge handelt. Wir haben uns also daran gehalten. Nun, dies folgt nicht dieser Namenskonvention, aber normalerweise ist es Customer:CustomerID: was auch immer die ID für diesen Kunden war, also führen Sie Cache.Add danach aus und geben dann in diesem Fall einen absoluten Ablauf von einer Minute an. Wie gesagt, machen Sie keinen gleitenden Ablauf und all das andere Zeug. Es soll Ihnen also nur einen Eindruck davon vermitteln, wie ein Cache aussieht.
Sehr einfach zu verwenden, sehr einfache API, viel einfacher als ADO.NET oder jede andere Programmierung.
Wie sieht ein Cache aus?Lassen Sie mich Ihnen tatsächlich zeigen, wie ein Cache aussieht, aber mit einem echten Cache. Ich habe also diese VMs und Azure. Ich habe also Demo 1 und 2 zwei. Dies sind zwei Cache-Server, die ich verwenden werde. Dies sind Cache-VMs und ich werde meinen Anwendungsserver haben. Ich werde es einfach Demo-Client nennen. Meine Anwendung wird also auf dem Demo-Client ausgeführt. Okay! Ich habe also Remotedesktop dabei. Ich werde es für den Fall tun NCache Ich werde dieses Tool namens ausführen NCache Manager, ich habe es tatsächlich hier. Und ich werde weitermachen und etwas erschaffen. Lassen Sie mich schnell sicherstellen, dass es noch keinen Cache mit diesem Namen gibt. Okay! Also werde ich fortfahren und einen neuen Cache erstellen. Ich werde meinen Cache Demo-Cache nennen. Ich werde einfach alles andere als Standard übernehmen. Ich werde eine Caching-Topologie auswählen. Ich werde nicht ins Detail gehen, aber diese Caching-Topologie führt gleichzeitig Partitionierung und Replikation durch. Wenn Sie diese Topologie verwenden, sieht Ihr Cache also in etwa so aus.
Das sind also Ihre Cache-Server. Einige der Daten, diese 1 2 3 4, sind also die Datenelemente. Einige der Daten befinden sich also in Partition 1, andere in Partition 2, und jede Partition wird auf einem anderen Server gesichert. Wenn Sie also 3 Server hier hätten.
Nehmen wir an, Sie hätten Partition 1, 2 und 3, Server 2 hat das Replikat für Partition 1, Server 3 hat ein Replikat von Partition 2 und Server 1 hat ein Replikat von Partition 3. Der Cache ist also tatsächlich ein Server. Es handelt sich tatsächlich um mehr als einen Server, der sich in einem Cluster befindet. Sie kennen sich und ich werde Sie jetzt schnell darauf zurückbringen. Nehmen wir also an, ich habe eine Partitionsreplikattopologie ausgewählt. Ich werde Demo 1 als meinen ersten Cache-Server auswählen. Warum ist es so langsam? Demo 2 als mein zweiter Cache-Server. Ich denke, das liegt wahrscheinlich daran, dass das Internet langsam ist. Ich weiß nicht. Ich habe also einen Cache-Cluster mit zwei Knoten. Also, Demo eins und zwei wissen jetzt voneinander. Sie werden also an diesem Hafen miteinander reden. Auf Port 7802, den ich ändern könnte. Warum ist es so langsam? Stellen Sie sicher.
Okay! Als nächstes werde ich also angeben, wie viel Speicher der Cache haben soll. Es hat also einen Auftritt, Sie werden wahrscheinlich, wie gesagt, 13 Auftritte oder so haben. Und dann werde ich die Räumungsrichtlinie angeben, die zuletzt angewendet wurde. Ich spare 15 % ... Es tut mir leid, 5 % des Caches zu entfernen. Das ist wirklich langsam, ich weiß nicht, was passiert. Diese ganze Box ist langsam, selbst ein Klick ist langsam, nicht einmal die CPU ist es, ja! Schaut so aus. Ja, ist es!
Okay! Im Grunde haben Sie also einen Cluster von Servern, die logischerweise als Cache bezeichnet werden, und Sie kennen sie nur durch einen Demo-Cache. Auf Ihrer Box, sagen wir mal, Ihrer Anwendungsserver-Box, sagen wir mal NCache ist hier installiert. Sie erhalten eine Konfigurationsdatei mit diesem Cache-Namen und einer Liste der Server, die ihn darstellen. Das ist also nur ein Ausgangspunkt, aber Sie werden auch hier wissen, dass der gesamte Cluster nur ein Cache-Name ist, und Sie stellen eine Verbindung zu ihm her, und dann stellt Ihre Client-API eine Verbindung zu allen Cache-Servern in diesem Bild her. Bei Partitionsreplikaten kommuniziert jeder Client mit allen Servern, sodass er direkt dorthin gehen kann, wo sich die Daten befinden, den Partitionierungsteil.
Ich werde dafür einen Client hinzufügen, der mein Demo-Client ist. Ich klicke jetzt auf den Cache-Assistenten, der lange dauert, und sage „Cache starten“. Ich sage also einfach, dass der Cache auf beiden Boxen startet. NCache ist ein Windows-basierter Cache und verfügt daher über alle benutzerfreundlichen Funktionen, die ein gutes Windows-basiertes Produkt bietet. Sie können dies also alles von einem zentralen Ort aus erledigen, alles ist auch über Skripting möglich.
Datenbanksynchronisierung – DemoLassen Sie mich Ihnen zeigen, wie eine Datenbanksynchronisierung aussieht. Was Sie also zum Beispiel tun, ist, dass es sich wieder um denselben Anwendungstyp handelt, Sie haben den Cache und wenn Sie versuchen, Daten zum Cache hinzuzufügen, nehmen wir an, dass Sie Cache.Add hier ausführen, und das ist Natürlich NCache Code geben Sie eine SQL-Cache-Abhängigkeit an, die eine ist NCache Klasse, aber sie wird im Back-End der SQL Server-SQL-Abhängigkeitsklasse zugeordnet. Und Sie übergeben ihm eine SQL-Zeichenfolge, die dann von verwendet wird NCache um eine Verbindung zur Datenbank herzustellen und der Cache-Server wird nun zum Client Ihrer Datenbank. Wenn sich Ihre Anwendung beispielsweise hier befindet, sagen wir, Ihr Code wird hier ausgeführt, haben Sie gerade diesen Aufruf ausgegeben. Ups, Entschuldigung! Sie haben gerade diesen Cache-Aufruf dieser Anzeige ausgegeben und übergeben diese SQL-Cache-Abhängigkeit. Der Client sendet all dies an den Cache-Server.
Also einer der Cache-Server oder mehrere. Und der Cache-Server öffnet nun eine Verbindung zur Datenbank, da Sie auch hier eine Verbindungszeichenfolge angegeben haben. Und diese Verbindungsstärke ist natürlich Pool. So. Wenn Sie mehrmals dieselbe Verbindungszeichenfolge angeben, gibt es im Back-End einen Verbindungspool. Damit ist nun ein weiterer Cache zum Client Ihrer Datenbank geworden. Es überwacht Ihre Datenbank, sodass die Datenbank dies benachrichtigt NCache Server, dass sich diese Daten geändert haben, die Sie von mir überwacht haben, und die NCache Der Server kann zu diesem Zeitpunkt entscheiden, ob er das Element aus dem Cache entfernen oder es aus der Datenbank neu laden soll. Und um es neu zu laden, müssen Sie tatsächlich die Vorlesefunktion nutzen.
Okay! Das ist also eine Möglichkeit, es zu tun. Es ist wirklich mächtig. Es ist ereignisgesteuert. Sobald die Änderung eintritt, benachrichtigt die Datenbank den Cache, der Cache führt die Aktion sofort aus. Auf dieser Seite des Datenbankservers entsteht jedoch ein Overhead, da jedes Mal, wenn Sie eine SQL-Cache-Abhängigkeit durchführen, eine Datenstruktur innerhalb des SQL-Servers erstellt werden muss, um diesen Datensatz zu überwachen. Wenn Sie nun 1 Million davon hätten, kann ich Ihnen garantieren, dass Ihr SQL-Server abstürzen wird. Da es also um Skalierbarkeit geht, müssen Sie in wirklich großen Zahlen denken. Wenn Sie also Tausende oder Zehntausende davon haben, ist das kein Problem. Aber wenn Sie Hunderttausende oder Millionen davon haben, wäre eine andere Strategie die bessere Strategie.
DatenbankabhängigkeitEine andere Strategie heißt DB-Abhängigkeit und ist unsere eigene NCache Funktion, bei der es sich um eine abfragebasierte Abhängigkeit handelt. Wir haben dies wo implementiert. Es gibt eine spezielle Tabelle und wir bitten Sie, Trigger zu ändern, damit Sie das Flag in dieser Tabelle für die entsprechende Zeile aktualisieren können. Wenn Sie dann eine DB-Abhängigkeit vom Cache ausführen, erstellt der Cache einen Eintrag in dieser Tabelle und dann in einem Abruf , kann der Cache Tausende von Zeilen abrufen, bei denen das Flag wahr ist und die Aktualisierung durchgeführt wurde. Es ist also wie unsere eigene Art, den Überblick zu behalten. Es basiert auf Abfragen und erfolgt daher nicht sofort. Standardmäßig beträgt die Verzögerung etwa 15 Sekunden, Sie können diese jedoch neu konfigurieren. Sie möchten auch nicht zu häufig ziehen. Das ist also das andere, aber selbst da gibt es eine Einschränkung: Was wäre, wenn Sie 1 Million Zeilen in dieser Tabelle mit einem Flag von „wahr“ und „falsch“ hätten, der Index würde ziemlich groß aussehen, oder? Es gibt einen wahren und einen falschen Index, das sind die beiden Knoten eines Baums. Daher ist die DB-Abhängigkeit effizienter als die SQL-Abhängigkeit, aber nicht so in Echtzeit, aber auch sie weist Einschränkungen auf.
CLR-ProzedurenBei der dritten handelt es sich um die CLR-Prozeduren, bei denen Sie eine CLR-Prozedur tatsächlich über einen Auslöser in der Datenbank aufrufen können. Wenn also ein Element hinzugefügt, aktualisiert oder gelöscht wird, rufen Sie die Prozedur auf. Die Prozedur führt einen asynchronen Aufruf an den Cache durch. Es heißt: Bitte fügen Sie dieses Element hinzu, aktualisieren Sie es oder löschen Sie es aus dem Cache. Der Grund, warum Async wichtig ist, liegt darin, dass Sie die Transaktion, die Datenbanktransaktion, nicht verzögern möchten. Andernfalls kommt es zu einer Zeitüberschreitung. Ein Async-Aufruf wird also sofort zurückgegeben und zumindest die Datenbanktransaktion kann festgeschrieben und der Cache aktualisiert werden. Daher ist die Synchronisierung des Caches mit der Datenbank eine entscheidende Funktion.
Cache mit nicht relational synchronisieren
Sie müssen über dasselbe verfügen, und das Gleiche gilt, wenn Sie über eine nicht relationale oder einen Mainframe- oder Legacy- oder eine andere Datenquelle verfügen. Möglicherweise haben Sie eine Cloud-Datenquelle. Möglicherweise möchten Sie Webmethodenaufrufe durchführen, um überhaupt zu überprüfen, ob diese Daten vorhanden sind aktualisiert wird oder nicht und NCache ermöglicht Ihnen diese benutzerdefinierte Abhängigkeitsfunktion, bei der Ihr Code überwacht werden kann NCache, Ihren Code in jedem kleinen Intervall aufruft, überwachen Sie Ihre Datenquelle, um festzustellen, ob sich diese Daten geändert haben, und benachrichtigen Sie gegebenenfalls NCache und NCache wird auf die gleiche Weise entweder entfernt oder erneut geladen.
Umgang mit relationalen Daten
Daher ist es von entscheidender Bedeutung, den Cache aktuell zu halten. Jeder Cache, der dies nicht zulässt, schränkt Ihre Möglichkeiten ein, davon zu profitieren. Ich werde den Umgang mit relationalen Daten überspringen, obwohl selbst das nicht der Fall ist und es, lassen Sie es mich kurz sagen, Eins-zu-viele-Beziehungen, Eins-zu-eins-Beziehungen gibt. Wenn Sie also ein Element im Cache und viele Elemente auch im Cache haben, sollten beim Entfernen des einen Elements im Cache logischerweise auch die vielen Elemente entfernt werden, denn was wäre, wenn Sie das Element aus der Datenbank gelöscht hätten? Der Cache sollte also in der Lage sein, all dies zu verfolgen. Sie könnten dies in Ihrer Bewerbung tun, aber es verkompliziert nur Ihre Bewerbungsgutschrift, da Sie jetzt viel Buchhaltung für den Cache machen müssen. Es ist, als würden Sie Datenbanksynchronisierungs- oder Datenintegritätscode in die Anwendung einbauen, was nicht die Aufgabe Ihrer Anwendung ist. Für die Datenbank machen Sie das nicht. Die Datenbank erledigt das für Sie, also sollte es auch der Cache für Sie tun.
Durchlesen und Durchschreiben
Durchlesen und Durchschreiben ist also eine weitere sehr leistungsstarke Funktion, die Ihr Cache haben sollte. Das Durchlesen ist im Grunde genommen auch hier ein sehr einfaches Konzept.
Sie implementieren ggf. eine Schnittstelle NCache Sie implementieren hier eine Schnittstelle namens Read-Through-Provider. Kannst du das sehen?
Ja, und es gibt drei Methoden. Es gibt einen Init, der beim Starten des Caches aufgerufen wird, damit Sie eine Verbindung zu Ihrer Datenquelle herstellen können. Es gibt eine Entsorgung, wenn der Cache stoppt. Sie können Ihre Bereinigung durchführen und in den meisten Fällen rufen Sie diesen Ladevorgang von der Quelle auf. Es gibt also Ihren Schlüssel weiter. Der Schlüssel ist Ihr Schlüssel, um zu wissen, welches Element in Ihrer Datenquelle abgerufen werden soll, und geben Sie es dann zurück, falls dies der Fall ist NCache ein Anbieter-Cache-Element. Und Sie können Abläufe angeben und bei Ablauf alle möglichen Flags neu synchronisieren und diese dann an weitergeben NCache. NCache speichert es zwischen.
Wie funktioniert das Durchlesen? Wir arbeiten so, dass Ihre Anwendung immer den Cache abfragt. Es heißt Cache.Get. Wenn der Cache die Daten nicht enthält, sagt er nicht, dass ich sie nicht habe, sondern holt sie aus der Datenbank. So wird Ihre Bewerbung plötzlich viel einfacher. Einen Großteil des Persistenzcodes haben Sie gerade aus Ihrer Anwendung entfernt. Ein Vorteil des Durchlesens besteht also darin, dass Sie den Code irgendwie vereinfacht und alles in der Caching-Ebene gekapselt haben. Die Caching-Ebene verfügt nun über immer mehr Persistenzebene. Nicht der gesamte Code kann durchgelesen werden, aber ein großer Teil davon ist möglich.
Bei Ablauf neu laden
Der zweite Vorteil des Durchlesens ist das, worüber ich zuvor gesprochen habe, nämlich die Neuladefunktion. Stellen Sie sich nun vor, Sie haben eine E-Commerce-Anwendung und Ihre Preise ändern sich. Bei jeder Preisänderung müssen diese Artikel aus dem Cache entfernt und neu geladen werden, aber der Datenverkehr ist sehr hoch, sodass während des Entfernens viele Kundenanfragen eintreffen die Datenbank. Der erste ruft es ab und legt es in den Cache, aber bis zu diesem Zeitpunkt gibt es im Cache plötzlich viel unnötigen Datenverkehr, und wenn das so weitergeht, wird die Datenbank viele unnötige Zugriffe erhalten, wenn so viel passiert was Sie hätten vermeiden können, wenn Sie nur „Nach Ablauf neu laden“ gesagt hätten. Also, einen Ablauf neu laden, was bewirkt das? Der Artikel wird bei Ablauf nicht entfernt. Es lädt es einfach neu, sodass der Cache bei Ablauf das Durchlesen aufruft, es von Ihrer Datenquelle abruft und einfach aktualisiert. Es findet also nur ein Aktualisierungsvorgang statt. Es gibt keinen Vorgang zum Entfernen und Hinzufügen und daher befinden sich die Daten oder das Element immer im Cache. So wird der Cache jetzt plötzlich. Es kann für sich selbst sorgen und sich selbst neu laden, wann immer Daten neu geladen werden müssen.
Durchschreiben
Das ist also eine wirklich leistungsstarke Durchlesefunktion. Wenn Sie das also mit dem Ablauf kombinieren, können Sie das auch mit der Datenbanksynchronisierung tun. Wenn die Datenbanksynchronisierung erneut stattfindet, warum sollte man sie dann entfernen? Einfach neu laden. Die andere Funktion ist das Durchschreiben, das genau wie ein Durchlesen funktioniert, außer dass es geschrieben wird. Es gibt noch eine weitere Funktion: Es kann auch Massenschreibvorgänge durchführen. Und den Grund, warum es Massenschreibvorgänge gibt, werde ich gleich erklären. Es gibt also auf die gleiche Weise ein Init, ein Dispose und jetzt ein Schreiben in Datenquellen. Das Schreiben bedeutet nicht nur Hinzufügen oder Einfügen. Es könnte sich auch um „Löschen“ handeln, sodass der Schreibvorgang einen Vorgangstyp hat, der dann entweder „Hinzufügen“, „Aktualisieren“ oder „Entfernen“ sein kann. Und das hängt davon ab, um welche Cache-Operation es sich handelte. Und dann können Sie das auch in großen Mengen tun. Das Durchschreiben hat also die gleichen Vorteile wie das Durchlesen hinsichtlich der Vereinfachung Ihres Codes, hat aber noch einmal einen weiteren Vorteil. Das Durchlesen hatte also den Vorteil beim Neuladen, das Durchschreiben hatte den Vorteil, dass man zurückschreiben kann.
Hinterschreiben
Und Write-Behind ist eine sehr, sehr leistungsstarke Funktion. Warum? Denn die Datenbankaktualisierungen sind ein Flaschenhals. Auch hier ist die Datenbank das notwendige Übel, mit dem man leben muss. Sie können nicht ohne leben, aber es verursacht alle möglichen Engpässe in Ihrer Anwendung. Je weniger Sie sich also darauf verlassen können, desto besser ist Ihre Anwendung. Die Tatsache, dass man ohne es nicht leben kann, muss es trotzdem haben. Was macht also ein Write-Behind? Es heißt, Sie aktualisieren den Cache, was superschnell ist, mindestens zehnmal schneller als die Datenbank, wenn nicht sogar schneller, und dann kümmert sich der Cache um die Datenbankaktualisierung. Es gibt also ein asynchrones Durchschreiben, das ist ein „Write-Behind“. Also gehst du hin und aktualisierst den Cache, kommst zurück und machst mit deinen Sachen weiter und der Cache geht und aktualisiert die Datenbank.
Natürlich gibt es viele Probleme, die der Cache berücksichtigen muss. Sobald Sie sagen, dass der Cache die Datenbank aktualisieren muss, was passiert, wenn der Cache-Server abstürzt? Was passiert mit dieser Warteschlange? Also, im Falle von NCache, wird die Warteschlange selbst auf mehrere Server repliziert, wenn ein Server ausfällt, geht die Warteschlange nicht verloren. Dann gibt es auch Wiederholungsversuche. Wenn das Update fehlschlägt, können Sie es erneut versuchen. Sie können auch eine Stapelaktualisierung durchführen. Es gibt also eine Reihe davon, die Sie per Massenaktualisierung durchführen können. So können die Dinge weiter optimiert werden. Durchschreiben und Durchlesen sind also sehr, sehr leistungsstarke Funktionen. Das nennt man serverseitigen Code. Dies ist Ihr Code, der im Cache-Cluster gespeichert ist. Es befindet sich hier und das Speichern dieses Codes auf dem Server vereinfacht Ihre App. Je mehr Code Sie also verschieben, desto einfacher wird die Anwendung.
Datengruppierung
Okay! Nehmen wir an, Sie sind davon überzeugt, dass Sie Caching verwenden sollten. Sie haben verschiedene Anwendungsfälle, bei denen Sie jetzt sicher sind, dass Sie viele Daten zwischenspeichern können. Jetzt sieht der Cache nun wie die Datenbank aus. Es fängt an, eine Menge davon zu haben. Sie werden Millionen von Elementen im Cache haben. Wenn Sie also Millionen von Elementen im Cache haben, ist es dann sinnvoll, die Dinge einfach anhand eines Schlüssels zu lesen? NEIN! Wenn die einzige Möglichkeit wäre, Elemente aus dem Cache basierend auf dem Schlüssel zu lesen, wäre Ihre Anwendung sehr, sehr anspruchsvoll im Vergleich dazu, wenn Sie Dinge tun könnten, geben Sie mir alle Dinge basierend auf diesen Suchkriterien.
Das Suchen und Gruppieren wird also zu einem sehr, sehr wichtigen Bedürfnis oder einem sehr wichtigen Bedürfnis eines Caches. Wie gesagt, der Zweck besteht darin, dass Sie die Vorteile verstehen. Der Vorteil besteht darin, dass Sie immer mehr Daten zwischenspeichern können. Je mehr Daten Sie zwischenspeichern, desto häufiger müssen Sie sie sehen oder über mehr datenbankartige Funktionen verfügen. Eine dieser Funktionen besteht darin, Metadaten erstellen zu können. In der Datenbank können Sie Indizes für viele verschiedene Attribute haben. Hier können Sie Tags und benannte Tags erstellen und ggf. die Objekte zwischenspeichern NCache Sie können damit auch Indizes erstellen. Sie können also ein Objekt indizieren. Nehmen wir an, ein Kunde könnte nach dem Attribut „Stadt“ indiziert werden, da Sie nach der Stadt suchen und diese daher indiziert werden sollte. Wenn es nicht indiziert ist, wird die Suche sehr mühsam. Stellen Sie sich Millionen von Artikeln vor, die Sie zunächst deserialisieren müssen, um jedes Objekt zu überprüfen und herauszufinden, welche Kunden sich in Orlando befinden. Kein gutes Bild, kein schöner Anblick.
Das Gruppieren von Untergruppierungs-Tags und Namens-Tags ist aus Codierungsperspektive also sehr einfach. Ich werde Ihnen das nur schnell zeigen. Aus der Aufnahmeperspektive sehr einfach zu bedienen. Sie fügen eine Reihe von Elementen hinzu, weisen ihnen Tags zu und dann tut es mir leid! Gruppe und Untergruppe, Gruppenuntergruppe und dann sagen Sie „Gruppendaten abrufen“, oder Sie können auch eine SQL-Suche durchführen und sagen: „Gib mir das gesamte Produktobjekt, bei dem der Gruppenname „Elektronik“ lautet.“ Das Gruppieren und Untergruppieren von Tags und Tags ist also ebenfalls etwas AppFabric übrigens vorgesehen AppFabric wird im Februar eingestellt. Wir haben mehr Minuten, ich werde es beschleunigen.
Daten suchen
Auch hier hängt das Finden von Daten mit der Gruppierung von Daten zusammen. Sie möchten Daten auf der Grundlage von SQL durchsuchen können. Ich denke also ... wo ist die Objektabfragesprache? Da ist es. Im Grunde könnte ich also eine Menge Daten haben und eine SQL-Anweisung ausgeben und mehrere Attribute angeben und Parameter übergeben, und im Falle eines Falles würde ich einen Datensatz zurücksetzen NCache und genau wie SQL Server, obwohl es eine Teilmenge des vollständigen SQL ist. Es werden keine Verbindungen erstellt, aber anstelle von Verknüpfungen können Sie Gruppierungen und Markierungen vornehmen und so mehrere Objekte gruppieren.
Also, im Fall von LINQ, NCache hat einen LINQ-Provider implementiert, also die Iqueryable-Schnittstelle. Du gehst und holst die Sammlung ab NCache Und dann führen Sie eine LINQ-Abfrage durch, genau wie bei jeder anderen Objektsammlung, und Sie erhalten eine Sammlung dieser Objekte, die Produktobjekte, zurück. Wenn LINQ also Ihre Komfortzone in Bezug auf die Suche ist, verwenden Sie LINQ für die Suche. Wenn Sie diese Abfrage ausgeben, gehen Sie zum Cluster, die gleiche Abfrage wird an alle Server gesendet und die Ergebnisse werden zusammengeführt und Ihnen dann angezeigt. Obwohl es hier sehr einfach aussieht, kann es sein, dass hinter den Kulissen eine Menge Arbeit geleistet wird NCache.
Wir haben also SQL und LINQ. Wir haben auch Bulk und wie gesagt, Sie können eine Indexierung durchführen.
Gemeinsame Nutzung von Laufzeitdaten
Ich möchte nur kurz darauf eingehen: Es gibt schlüsselbasierte Ereignisse, es gibt Ereignisse auf Cache-Ebene, es gibt Pub-Sub-Ereignisse und es gibt eine kontinuierliche Abfrage.
Kontinuierliche Abfrage ist eine Funktion, die einer SQL-Abhängigkeitsfunktion ähnelt, nur dass sie sich auf den Cache bezieht. Sie bitten den Cache, einen Datensatz für Sie zu überwachen. Genauso wie wir die SQL-Abhängigkeit verwendeten und den SQL-Server gebeten haben, diesen Datensatz zu überwachen, und gesagt haben, wenn sich dieser Datensatz ändert, benachrichtigen Sie mich bitte. Jetzt fragen Sie NCache, sagen Sie bitte, hier ist meine SQL-Anweisung, wählen Sie Kunden aus, bei denen Customer.City gleich New York ist, und Sie sagen: Wenn ein Kunde, der diese Kriterien erfüllt, zum Cache hinzugefügt, aktualisiert oder aus dem Cache gelöscht wird, benachrichtigen Sie mich bitte. Das könnte ein beliebiger Ort sein Das Netzwerk, jeder Ort im Cache-Cluster und Sie können beliebige andere Clients sein. Sie werden benachrichtigt. Wenn Sie nun über diese Art von Funktionen verfügen, können Sie plötzlich überwachen, was mit dem Cache geschieht, und benachrichtigt werden, anstatt Dinge abzufragen, und das ist es, was ich gesagt habe, der Cache wird zu einer wirklich leistungsstarken Plattform für die gemeinsame Nutzung von Laufzeitdaten.
Hochverfügbarkeit
Okay! Ich werde das auch überspringen. Ich meine, jeder Cache, den Sie verwenden, muss dynamisch sein. Es muss eine hohe Verfügbarkeit bieten, was im Fall von NCacheEs verfügt über eine Peer-to-Peer-Architektur.
Client-Cache
Ich möchte, dass Sie eine Funktion kennen, die aufgerufen wird Client-Cache. Manche Leute nennen es „Near Cache“.
Dabei handelt es sich tatsächlich um einen Cache, der sich lokal auf Ihrer Anwendungsserver-Box befindet. Es ist wie ein eigenständiger Cache, nur dass er nicht eigenständig ist. Es kann also sogar InProc sein. Dies kann innerhalb Ihres Bewerbungsprozesses geschehen, was bedeutet, dass Sie tatsächlich Dinge wie auf Ihrem Objektheap abrufen. Ihr Heap enthält Daten in Objektform. Nichts geht über diese Leistung, oder? Wenn Sie diese Daten einfach vom Heap abrufen können, anstatt sie in eine lokale Cache-Box zu übertragen, OutProc, denn wenn Sie prozessübergreifend gehen, müssen sie IPC durchlaufen, es muss Serialisierung und Deserialisierung durchführen, wenn Sie über das Netzwerk gehen, ist es sogar noch mehr, wann Wenn Sie in die Datenbank gehen, ist das im Vergleich phänomenal teuer.
Es handelt sich also um einen lokalen Cache innerhalb Ihres Bewerbungsprozesses oder lokal auf der Box. Aber es bleibt synchron. Sie führen keine spezielle API-Programmierung für den Client-Cache durch. Für den Fall, dass dies der Fall ist, rufen Sie einfach den Cache auf NCache, es fügt sich einfach in die Konfigurationsänderung ein und fängt die Aufrufe ab und speichert lokal eine Kopie davon, was auch immer Sie abrufen. Wenn Sie es also das nächste Mal abrufen, wird es automatisch aus dem lokalen Cache abgerufen. Enorme Leistungssteigerung. Das ist etwas, das nur NCache hat auf der .NET-Seite. Auf der Java-Seite gibt es andere Produkte, die über einen Client-Cache verfügen, aber auf der .NET-Seite ist dies nur der Fall. Das ist wie ein Cache über einem Cache, und das ist der Grund, warum sich viele Leute beschweren, wenn sie vom eigenständigen InProc-Cache zu einem verteilten Cache wechseln, meine Leistung ist tatsächlich gesunken, meine Anwendung ist langsamer, ich dachte, der verteilte Cache wäre das soll meine Leistung steigern und wir sagen ihnen, nein, es soll die Skalierbarkeit erhöhen. Nichts passt zu einem lokalen InProc-Cache, das kann niemand. Ich meine, das ist nichts, was wir erfinden und tun können. Man geht prozessübergreifend vor, das ist mit Kosten verbunden.
Also, dann sagen wir: Eine Möglichkeit, diese Herausforderung zu meistern, ist die Verwendung eines Client-Cache. Ein Client-Cache ist also wiederum eine Teilmenge. Normalerweise verfügt jeder Cache-Server über 16 bis 32 GB. Wenn Sie also über drei bis vier Server verfügen, verfügen Sie möglicherweise über mehr als hundert Gigabyte an zwischengespeicherten Daten, und der Client-Cache kann jeweils ein Gigabyte, vielleicht zwei Gigabyte, vielleicht drei oder vier Gigabyte maximal sein und hängt davon ab, wie viele Worker Sie verarbeiten haben. Wenn Sie nur einen Arbeitsprozess haben, machen Sie ihn zu viert. Wenn Sie über acht Worker-Prozesse verfügen, die viele unserer High-End-Kunden auf ihrer Webebene haben, möchten Sie nicht vier mal acht nur im Client-Cache haben. Dann ist es vielleicht gut, einen Out-of-Process-Cache mit vier GB zu haben, was immer noch besser ist, als auf die Caching-Ebene zu wechseln. Es ist immer noch schneller, oder Sie können einen kleineren Cache mit einem Gig oder weniger als einem Gig verwenden, was InProc ist. Jetzt haben Sie acht Kopien davon, aber auch diese sind synchronisiert. Wenn Sie also den Nutzen aus einem Cache ziehen wollen, sollten Sie auf jeden Fall die Verwendung eines Client-Cache in Betracht ziehen.
Mein Ziel ist es nicht, Ihnen irgendwelche Cache-Funktionen zu verkaufen, sondern zu sagen, was ein guter Cache haben muss und viele dieser Funktionen finden Sie auf der Java-Seite. Java ist im Caching-Bereich ein viel ausgereifterer Markt. Sie verwenden das Wort „In-Memory-Data-Grid“ anstelle von „Distributed Cache“, unabhängig von der Funktion, die Sie sehen NCache, Sie werden viele davon auch auf der Java-Seite sehen, aber auf der .NET-Seite NCache ist der Einzige.
WAN-Replikation
Eine weitere Funktion ist: Wenn Sie über mehrere Rechenzentren verfügen, möchten Sie, dass Ihre Datenbank repliziert wird. Warum also nicht der Cache? Was werden Sie tun? Wirst du den gesamten Cache neu erstellen? Was ist mit dem Warenkorb? Was ist mit den Sitzungen? Mehrere Rechenzentren sind also Realität und die Cloud hat es noch einfacher gemacht, da für Sie kein Aufwand erforderlich ist. Sie sagen einfach Region eins und Region zwei und schon haben Sie zwei Rechenzentren, oder? Aber das zugrunde liegende Problem verschwindet nicht: Wenn Sie einen verteilten Cache verwenden, der die WAN-Replikation nicht unterstützt, stecken Sie fest. Sie können keine Aktiv-Aktiv- oder gar Aktiv-Passiv-Lösung mit mehreren Rechenzentren haben, ohne dass der Cache repliziert wird, also eine sehr wichtige Funktion.
NCache hat das natürlich. Ich habe Ihnen bereits die praktische Demo gegeben. NCache ist der älteste .NET-Cache auf dem Markt. Wir wurden 2005 gegründet, viel älter.
NCache vs Redis
Also werde ich es schnell durchgehen NCache gegen Redis, sehr sehr hohes Niveau und das liegt daran Redis Es kommen viele Leute und fragen uns, wie Sie im Vergleich abschneiden Redis Seitdem hat Microsoft sie für Azure ausgewählt.
Redis, ist ein tolles Produkt. Es ist superschnell. Es kommt hauptsächlich von der Linux-Seite. Es verfügt nicht über viele Funktionen. Es gewinnt nicht an Funktionen. Es gewinnt einfach dadurch, dass es von der Linux-Seite kam und Microsoft den AWS-Markt erobern wollte, sodass sie keine .NET-Lösung einführen konnten. Sie mussten eine plattformübergreifende Lösung einführen. Ihre Linux-Version ist also sehr stabil, sehr gut, aber die Windows-Portierung, die Microsoft selbst erstellt hat, ist eine Art verwaiste Portierung. Microsoft selbst verwendet es nicht. Wenn Sie sich in Azure befinden und verwenden Redis, Sie verwenden nicht den Windows-Port von Redis, Sie verwenden die Linux-Version. Wenn Sie also nicht auf Azure arbeiten und den Windows-Port von verwenden möchten Redis, in acht nehmen. Ich meine, niemand besitzt es. Redis labs, wenn man auf deren Website geht, gibt es nicht einmal einen Windows-Download. Ich meine, sie haben nur Linux-Downloads, deren Ersteller ist Redis. Microsoft hat, wie ich selbst gesagt habe, in Bezug auf die Nutzung der Zusage keinen großen Wert darauf gelegt.
Damit NCache ist die einzig praktikable Option für Sie und es ist Open Source. Wenn Sie also nicht das Geld haben, entscheiden Sie sich für die kostenlose Open-Source-Version. Wenn Ihr Projekt wichtig ist und Sie Unterstützung und weitere Funktionen benötigen, dann sind das die Unternehmensfunktionen. Das Unternehmen NCache basiert auf Open Source. Es ist keine separate Sache. Open Source ist kein Waisenhaus. Ich meine, wir besitzen es, wir pflegen es und das Unternehmen baut darauf auf. Open Source muss also stabil sein, aber wenn Sie Unterstützung und mehr Funktionen wünschen, kaufen Sie einfach die Enterprise Edition.
Wir sind natives .NET. Wir haben in C-Sharp entwickelt und sind für Windows Server 2012 r2 zertifiziert. Wir werden auch bald das nächste bekommen. Wir meinen also, dass wir für Microsoft nicht an der Spitze stehen. Wir sind so ziemlich .NET, das ist, was wir sind. Wir haben einen Java-Client, aber fast alle unsere Java-Anwendungen werden von Kunden verwendet, die etwas kaufen NCache für .NET und da sie es intern haben, nutzen sie es auch aus Java. Unser Lebensunterhalt und unser gesamtes Überleben basiert also auf .NET. Deshalb werden wir immer die Neusten und Besten, die Ersten und Einfachsten sein.