Wie skaliere ich EF Core-Apps auf extreme Leistung?
Aufgezeichnetes Webinar
Von Ron Hussain und Zack Khan
EF Core wird zunehmend in .NET-Serveranwendungen mit hoher Transaktionsdichte (ASP.NET, Webdienste, Microservices und andere Server-Apps) verwendet. Und diese Anwendungen sind mit Skalierbarkeitsengpässen von Datenbanken konfrontiert, die sie durch die Verwendung von verteiltem Caching in EF Core beseitigen können.
- Einführung in die neuen Funktionen von EF Core (Modell, Abfrage, Speichern von Daten)
- Wie der verteilte Cache Engpässe in der EF Core-Datenbank löst
- Verschiedene Möglichkeiten zur Verwendung von verteiltem Caching in EF Core-Apps
- Details zur Verwendung von EF Core-Erweiterungsmethoden für das Caching
- Umgang mit dem Caching von Sammlungen und Datenbeziehungen
Entity Framework Core oder EF Core ist die neue plattformübergreifende und einfache objektrelationale Mapping-Engine von Microsoft für .NET, die den Großteil des Datenzugriffscodes, den Entwickler sonst schreiben, überflüssig macht. Ähnlich zu .NET Core, EF Core ist auch plattformübergreifend, d. h. Sie können es unter Windows, Linux und Mac verwenden und wird in der Entwickler-Community immer beliebter.
Wie können Sie Ihre Anwendung skalieren, um eine extreme Leistung sowie ein lineares Wachstum der Kapazität zur Bearbeitung von Anfragen zu erreichen? So können Sie Ihre App, die Entity Framework Core-Anwendung, horizontal skalieren NCache Erweiterungsmethoden. Deshalb haben wir einige zusammengestellt, die Sie verwenden können. Verschiedene Szenarien, die ich malen werde und die ich dann darauf aufbauend vorstelle NCache Erweiterungsmethoden sowie Objekt-Caching-Features, die Sie in einer typischen Entity Framework Core-Anwendung in Ihrer Umgebung verwenden können.
Was ist Entity Framework/EF Core?
Zunächst würde ich allgemein über Entity Framework und Entity Framework Core sprechen. Ich bin mir ziemlich sicher, dass jeder über EF und EF Core Bescheid weiß, aber nur der Vollständigkeit halber, um einige einführende Details zu erstellen.
Entity Framework ist ein ORM, das Sie für .NET und mit EF Core sowohl für .NET als auch für verwenden können .NET Core. Entity Framework vereinfacht Ihre Datenbankprogrammierung. Sie können am konzeptionellen Objektmodell arbeiten. Sie müssen also nicht direkt mit dem Datenmodell arbeiten und es vereinfacht die Programmierung des gesamten Datenzugriffs. Sie müssen nicht selbst persistenten Code schreiben. Es könnte viele Interaktionen zwischen Ihrer Objektschicht innerhalb Ihrer Anwendung mit dem Datenmodell, das Sie haben, und der Verwendung des Datenbankzugriffs erzeugen, der von Entity Framework Core generiert wird.
Es ist sehr beliebt für Ihr .NET und .NET Core Anwendungen. Sie können es in jeder Art von Anwendung verwenden, sei es eine Webanwendung, eine typische Serveranwendung, .NET oder .NET Core Webdienste, IOT-Anwendungsfälle oder andere Serveranwendungen können dies aufgrund seiner Popularität und auch wegen seiner Benutzerfreundlichkeit nutzen. Es ist sehr einfach einzurichten und Sie können damit loslegen.
Entity Framework Core ist eine neue Variante. Das ist die neue Richtung, in die Microsoft vor allem Open Source geht, es ist plattformübergreifend. Sie können also eine Anwendung ausführen, die verwendet wird .NET Core oder Sie kennen .NET. Es kann unter Windows mit .NET und mit ausgeführt werden .NET Core Es kann sowohl auf Windows- als auch auf Linux-Umgebungen und ähnlichem ausgeführt werden Entity Framework-Kern folgt dem Anzug, richtig? Es ermöglicht Ihnen also, sowohl auf Windows- als auch auf Linux-Umgebungen zu laufen, wenn dies erforderlich ist, und es ist sehr leicht und modular in der Natur. Was im Wesentlichen bedeutet, dass Sie nicht alle Komponenten innerhalb von Entity Framework durchgehen müssen, die Sie früher hatten. Mit EF Core können Sie mit der Komponente arbeiten, die Sie benötigen. Sie können NuGet Package nur dafür erhalten und basierend darauf können Sie inkrementell Komplexität innerhalb Ihrer Anwendung aufbauen.
Wenn Sie also komplexe Szenarien innerhalb Ihrer Anwendung verwalten müssen, wissen Sie, was das angeht. Und obendrein ist es superschnell, weil .NET Core Es gibt auch einen bestimmten Fokus oder eine Leistungsseite. Daher wurde Entity Framework Core nach denselben Richtlinien entwickelt, bei denen die Leistung einer der Schlüsselfaktoren ist, die Sie erreichen können.
Architekturdiagramm von Entity Framework
Hier ist also ein Architekturdiagramm für Entity Framework Core.
Ich habe ein Entity Framework-Diagramm gefunden, das immer noch gilt, viele Dinge gelten auch noch für die Entity Framework Core-Architektur. Dies ist von MSDN. Mit EF Core haben Sie einen ADO.NET-Datenanbieter. Ich verwende SQL Server als Beispiel für eine Datenquelle, und dann haben Sie einen Entity Client-Datenleser, der Befehlsbäume und ein Datenzugriffsszenario aufbaut, und dann haben Sie Objektdienste, und auf der Anwendungsseite arbeiten Sie entweder mit Entity SQL-Abfrage oder LINQ zu Entitäten. Sie arbeiten also wieder mit dem Objektmodell und hinter den Kulissen kümmert sich der Entity Framework Core um alle anderen Details.
Es gibt einen Befehl, den Sie ausführen, um Ihre Zuordnung und Ihr Modell zur Laufzeit zu generieren, also, konzeptionelles Modell, EDMX, all diese Zuordnungsdateien, sie wurden von denen in Entity Framework Core entfernt. Es ist also sehr einfach, es wieder einzurichten. Wieder ist es modular. Sie können also NuGet-Pakete einführen und innerhalb weniger Minuten eine sehr einfache Entity Framework Core-Anwendung erstellen.
Was ist Skalierbarkeit?
Als nächstes werde ich über Skalierbarkeit sprechen, das ist ein weiteres Konzept, das ich hervorheben wollte. Warum benötigen Sie Caching in einer Anwendung, die Entity Framework Core verwendet? Zunächst einmal gibt es ein Konzept der Skalierbarkeit. Das ist ein sehr gutes Feature innerhalb einer Anwendung, wo man eine hohe Anwendungsleistung erreichen kann und das auch noch unter Lastspitzen, oder? Also, wenn Sie in der Lage sind, eine niedrige Latenz und die niedrigstmögliche Latenz zu haben und diese niedrige Latenz bei geringer Benutzerlast beibehalten, sagen wir fünf bis zehn Benutzer, und wenn Sie ein Anwendungsarchitekturdesign so haben, dass Sie dasselbe verwalten können Art niedriger Latenz bei einer großen Anzahl von Benutzeranfragen, dann würde diese Anwendung als sehr skalierbare Anwendung kategorisiert.
Und lineare Skalierbarkeit ist ein weiteres zugehöriges Konzept, bei dem Sie mehr und mehr Server hinzufügen und Ihre Last verteilen können, und durch die Verteilung der Last auf mehrere Server würden mehr Server tatsächlich die Kapazität zur Verarbeitung von Anfragen erhöhen, und diese Zunahme sollte linear wachsen. Wenn Sie also eine Anwendung haben, deren Kapazität wächst, wenn Sie weitere Server hinzufügen und das Banner linear erhöht, würde dies als linear skalierbare Anwendung kategorisiert werden.
Welche Anwendungen benötigen Skalierbarkeit?
Typischerweise handelt es sich also um Anwendungen mit hoher Transaktionsdichte wie ASP.NET oder ASP.NET Core Web-Apps, Webdienste, IoT, Big-Data-Anwendungen oder andere allgemeine .NET- bzw .NET Core Anwendungen, die den Entity Framework-Kern verwenden, erfordern eine hohe Skalierbarkeit, richtig? Daher benötigen sie innerhalb ihrer Architektur eine hohe Transaktionslast an Verarbeitungskapazität.
Wo genau liegt das Skalierbarkeitsproblem?
Also, wo genau ist das Problem? Warum brauchen Sie ein Caching-System, um dieses Problem zu lösen? Sie können jederzeit eine Webfarm und eine App-Farm erstellen, in denen die Entity Framework Core-Anwendung linear auf sich selbst skalieren kann, indem Sie eine Webfarm oder eine App-Farm erstellen. Sie können einen Load Balancer vorschalten. Das ist also nicht das Hauptproblem. Ihre Anwendungsebene kann jederzeit horizontal skaliert werden. So lässt sich ein Entity Framework Core & ein typisches .NET bzw .NET Core Anwendungen konzipiert sind. Wo Sie Anfragen an mehrere Server weiterleiten und sie dennoch in Kombination miteinander verwenden können.
Das Hauptproblem ist Ihr Datenspeicherengpass. Wenn es sich um eine relationale Datenbank handelt, verwenden wir normalerweise dieses Beispiel. Datenbanken sind normalerweise eine einzige Quelle für Ihre gesamte Datenspeicherung. Sie eignen sich sehr gut zur Aufbewahrung. Darin sind sie am besten. Aber wenn es darum geht, eine extreme Menge an Anforderungslasten zu bewältigen, haben Sie beispielsweise eine Menge Transaktions- und Referenzdatenlast, die von Ihren Anwendungen eingeht, und die Datenbank ist nicht dafür ausgelegt, diese erhöhte Menge an Anforderungslast zu bewältigen. Es würde bei geringer Benutzerlast gut funktionieren, aber wenn es beginnt, Kapazität auf der CPU-Seite zu verbrauchen, auf der Speicherseite, und dann gibt es einen DBMS-Tunnel, in dem alle Anforderungen weitergeleitet werden. Es besteht die Möglichkeit, dass Ihre Datenspeicherung zu einem Skalierbarkeitsengpass wird. Es würde zu Leistungseinbußen führen, wenn es Anfragen in die Warteschlange stellt, die zur Laufzeit generiert werden. Sie können also keinen weiteren Datenbankserver hinzufügen.
Erstens ist der Anfang teuer und dann können Sie auf keinen Fall zwei Server in Kombination miteinander verwenden. Es würde sich also nicht zum Leistungswert addieren, es würde Ihre Leistung verschlechtern, und das würde sich auch auf Ihre Endbenutzererfahrung auswirken und dies wiederum kann sich auch auf Ihr Unternehmen auswirken. Denn wenn Ihre Anwendungen langsam sind, würden viele Benutzer dieses träge oder langsame Verhalten Ihrer Anwendung nicht mögen. Anwendungen benötigen also immer eine niedrige Latenz und einen hohen Durchsatz, und die Aufrechterhaltung eines hohen Durchsatzes ist mit Leistungseinbußen verbunden, und das sehen Datenbanken in der Regel, wenn sie Ihre Anwendungen einfach verlangsamen oder in den meisten Fällen auch vollständig ersticken.
Die Lösung
In diesem Abschnitt werden wir darüber sprechen, wie Sie dies angehen können. Die Lösung ist sehr einfach. Sie können verwenden Verteiltes Caching-System von NCache. Es ist sehr schnell, weil es In-Memory ist. Es ist sehr skalierbar, weil es nicht nur eine einzige Quelle ist. Sie können beliebig viele Server zum Cache-Cluster hinzufügen und diese Server in einem Cache-Cluster arbeiten in Kombination miteinander. Sie können Ihre Daten und dann die Anforderungsbearbeitungslast verteilen und durch das Hinzufügen weiterer Server erreichen Sie auch eine bessere Skalierbarkeit des Systems. Es ist kein Ersatz für Ihre herkömmlichen relationalen Datenbanken. Sie verwenden einen verteilten Cache innerhalb Ihrer EF Core-Anwendung in Kombination mit einer Datenbank. Sie cachen also entweder die am leichtesten zugänglichen Daten, Ihre Referenzdaten, oder Sie cachen auch einige Ihrer Transaktionsdaten.
Und ich werde darüber sprechen, wie Sie mit verschiedenen Caching-Szenarien und Caching-Strategien umgehen, die Sie in Ihrer Anwendung verwenden können.
Bereitstellungsarchitektur
Hier ist die Bereitstellungsarchitektur, die einige Dinge weiter verdeutlichen würde, warum sie im Vergleich zu relationalen Datenbanken die bessere Option ist.
Zunächst einmal befindet sich der verteilte Cache zwischen Ihrer Anwendung und der Datenbankebene. Und wenn Sie dazwischen sagen, dass Ihre Anwendung im Wesentlichen zuerst den Cache verwenden würde, wenn sie hier Daten findet, sollte sie zurückkehren, wenn sie hier keine Daten findet, sollte sie erst dann zur Backend-Datenbank gehen, oder? Logischerweise befindet es sich also zwischen Ihrer Anwendung und der Datenbank.
In Bezug auf die Bereitstellung können Sie Ihre Anwendung auf VMs, auf physischen Boxen, vor Ort oder in der Cloud bereitstellen. NCache wird sowohl auf Microsoft Azure als auch auf AWS in Form eines vorkonfigurierten Images oder jeder anderen Cloud unterstützt. Sie können unser Installationsprogramm verwenden, das von unserer Website heruntergeladen werden kann, und dann können Sie mit der Installation beginnen, die sehr einfach ist aufstellen. NCache kann auf einer eigenen jeweiligen Ebene sein, separate dedizierte Server für NCache oder es kann auf den gleichen Boxen laufen. Wenn Sie Boxen haben, in denen Ihre Anwendung bereitgestellt wird, können Sie sie bereitstellen NCache auch auf der gleichen Ebene. Wir empfehlen, separate Boxen zu haben, und Sie können zu Beginn zwei bis drei Server hinzufügen und dann je nach Ihren Anforderungen an die Bearbeitung von Anfragen immer mehr Server hinzufügen.
Wenn Sie beispielsweise 10,000 Benutzer und die damit verbundene Anforderungslast bewältigen müssen, können Sie einige Tests durchführen und sehen, wie viele Server Sie benötigen. Im Allgemeinen konnten wir basierend auf kürzlich durchgeführten Tests mit nur 4 bis 5 zwei Millionen Anfragen pro Sekunde erreichen NCache Server, richtig? So können Sie sehen, wie viele Server Sie benötigen, um Ihre Anwendungslastanforderungen zu bewältigen. Nur Voraussetzung für NCache ist entweder .NET oder .NET Core. Es läuft auf Windows, auf Windows Nano sowie auf Linux-Servern. Ebenso können sich Ihre Anwendungen auf der Windows-Plattform oder auf der Linux-Plattform befinden.
Und es gibt auch einige leistungsstarke Funktionen zur Datenbanksynchronisierung. Wie ich bereits sagte, ist es kein Ersatz für Ihre herkömmlichen Datenbanken. Es verwendet Ihre Datenbank, es wird zusammen mit Ihrer Datenbank verwendet, richtig? Einige Daten würden also im Cache gespeichert, aber alle Ihre Daten würden immer in Ihrem permanenten Speicher vorhanden sein, der Ihre relationale Datenbank ist. Und ich werde gleich darüber sprechen, wie man mit dem Caching umgeht.
3 häufig verwendete Anwendungsfälle für verteiltes Caching
Hier sind einige häufige Anwendungsfälle. Allgemeine Anwendungsfälle für verteilten Cache und am bekanntesten ist das Caching Ihrer App-Daten. Wir haben hier Entity Framework Core.
Zwischenspeichern von Anwendungsdaten
Der erste Anwendungsfall, der unser häufigster Anwendungsfall ist, ist unser App-Daten-Caching-Anwendungsfall. Dabei cachen Sie typischerweise Daten, die in die Datenbank gehören. Motivation dabei ist, dass Sie sich möglichst teure Datenbankreisen ersparen und die Vorteile, die Sie erhalten, eine hohe Performance für Ihren Datenabruf sind. Da Datenbanken im Vergleich zum In-Memory-Zugriff langsam sind, ist es In-Memory, also superschnell, und dann haben Sie mehrere Server, die Ihre Anfrage von Ihrer Anwendung aus hosten und bedienen. So erhalten Sie mehr Skalierbarkeit, mehr Durchsatz aus dem System und unter Beibehaltung einer niedrigen Latenz, die für den verteilten Cache gegeben ist, und in den meisten Fällen ist er auch hochverfügbar und zuverlässig, basierend auf der von Ihnen gewählten Topologie, im Gegensatz zu Datenbanken, die möglicherweise nicht repliziert werden über andere Server.
Mit dem App Data Caching können Sie fast alles zwischenspeichern. Sie können direkte APIs verwenden. Sie können Ihre Domänenobjekte, Sammlungen, Datensätze, einzelnen Elemente, Ergebnisse, welche Daten auch immer Sie zwischenspeichern möchten, zwischenspeichern, und Sie benötigen diese Daten erneut. Sie sollten in Betracht ziehen, unser Objekt-Caching zu verwenden, und mit Entity Framework Core können Sie wiederum direkte APIs oder Erweiterungen verwenden Methoden, die ich Ihnen zeigen werde.
ASP.NET-Sitzungscaching und SignalR Backplane
Dann ein weiterer Anwendungsfall für NCache ist es ASP.NET und ASP.NET Core spezifisches Caching. Wir haben unser Session-Caching. Sitzungs-Caching in ASP.NET Core ist durch IDistributedCache sowie zu unserem NCache Sitzungsanbieter ebenfalls. Das ist also die zweite Option und dann haben wir SignalR Backplane. Das ist eine weitere Option, die Sie nutzen können. Wenn Sie über eine SignalR-Anwendung verfügen, können Sie diese verwenden NCache als Backplane. Dies ist wiederum eine Option ohne Codeänderung, und dann haben wir Antwort-Caching, Anzeigestatus und Ausgabe-Caching. Das sind also alle Funktionen, die spezifisch für ASP.NET sind, und darüber hinaus können Sie bei Bedarf auch App-Daten-Caching innerhalb Ihrer Webanwendung verwenden.
Pub/Sub-Messaging und kontinuierliche Abfragen
Und dann haben wir leistungsstarkes Pub/Sub-Messaging und kontinuierliche Abfrageereignisse, oder ich würde sagen, Pub/Sub-Messaging und -Ereignisse. Sie können verwenden NCache als Ihre Messaging-Plattform, auf der mehrere Anwendungen verbunden sind und diese Anwendungen über unser Pub/Sub-Messaging miteinander kommunizieren können. Eine Anwendung kann Nachrichten an veröffentlichen NCache, die als Kommunikationskanal fungiert. Es hat ein Konzept von Themen und dann können diese Abonnentenanwendungen diese Nachricht empfangen, wenn sie mit diesem Thema verbunden sind. So können sie sich gegenseitig koordinieren, indem sie Daten sowie bei Bedarf benutzerdefinierte Nachrichten austauschen. Und wir können Social-Media-Systeme aufbauen. Sie können ein Chat-System haben. Sie können Ranglisten haben. Sie können es je nach Bedarf in jeder Art von Industrie einsetzen, in der Sie verschiedene Komponenten Ihrer Anwendung aufeinander abstimmen müssen.
Kommunikation zwischen Microservices
Microservices sind ein weiterer Anwendungsfall, bei dem Sie serverlose Microservices-Anwendungen benötigen, die miteinander interagieren und sie verwenden können NCache für ihre Kommunikationsbedürfnisse und dann haben wir auch Continuous Query Events. Regelmäßige Veranstaltungen, bei denen Ihre Daten hinzugefügt, aktualisiert oder entfernt werden. Anstelle von Anwendungen, die Ereignisse senden, NCache kann basierend auf Datenänderungen Ereignisse an Ihre Anwendungen senden, und zwar für alle Elemente oder für ausgewählte Elemente oder basierend auf der kontinuierlichen Abfrage, in der Sie einen Datensatz abbilden NCache und NCache sendet nur Ereignisse für diesen angegebenen Datensatz.
Es gibt auch einen vierten Anwendungsfall. Wir haben eine Volltext-Suchfunktion. Es ist sehr verbreitet in E-Commerce-Anwendungen. Mit NCache Wir haben die Lucene .NET API implementiert. Wenn Sie also an der Volltextsuche interessiert sind, NCache ist auch damit voll ausgestattet.
Zwischenspeichern von App-Daten in EF Core
Lassen Sie uns darüber sprechen, wie Sie das Caching in einer typischen Entity Framework Core-Anwendung verwenden würden.
Musteranwendung einrichten
Also, zuallererst habe ich diese Anwendung. Beispielanwendung direkt hier aufgereiht. Es ist eines der Samples, die mit installiert werden NCache auch. Wenn Sie also zu C:\Program Files\ gehenNCache\, diese Beispiele sind hier verfügbar.
.NET und .NET Core Proben werden separat platziert. Also ich würde weitermachen .NET Core und Entry Framework haben wir hier ein EF Core-Beispiel. Das ist also das Beispiel, das ich verwende.
Ich habe es ein wenig geändert, um einige dieser Szenarien zu demonstrieren, die ich in diesem Webinar präsentieren möchte. Andernfalls erledigt es die grundlegende Arbeit für Ihren POC. Richtig, das ist also die Probe. Als Nächstes würde ich mich bei unserer Demoumgebung anmelden und damit beginnen, einen Cache-Cluster für Sie zu erstellen, damit Sie tatsächlich einen Cache-Cluster verwenden und von dort aus weitermachen können.
Erstellen Sie einen geclusterten Cache
Für die Cache-Erstellung haben wir also unser Web-Management-Tool eingerichtet und ausgeführt. Ich werde schnell einen erstellen. Lassen Sie uns also fortfahren und einen geclusterten Cache hinzufügen. Nennen wir es Democache. Ich werde ein paar Ganzzahlen anhängen, democache111. Sie können übrigens das JSON- oder Binärformat beibehalten, was die Serialisierung betrifft. Los geht's. Sie können also das Binär- oder JSON-Serialisierungsformat haben. Ich werde mit Binary fortfahren, da dies die Standardoption ist. Es gibt vier Caching-Topologien, aus denen Sie wählen können, und wir haben andere Webinare wie z NCache Architektur, die speziell darauf abzielt, Sie wissen schon, zu erklären NCache die Architektur. Ich werde also mit Partitioned Replica Cache fortfahren, da dies sehr gut für Lesevorgänge und sehr gut für Schreibvorgänge funktioniert und für die Lese- und Schreibanforderungskapazität super skalierbar ist, wenn Sie weitere Server hinzufügen und es auch mit Repliken ausgestattet ist , sodass auch für Ihre Anwendung keine Ausfallzeiten oder Datenverluste auftreten.
Also würde ich alles einfach halten, Standard. Asynchrone Replikation zwischen aktiver Partition und ihrer Sicherung. Also werde ich das wählen, es ist schneller. Größe des Cache-Clusters und hier habe ich Server angegeben, die meinen Cache-Cluster hosten werden. Wie ich bereits sagte, werde ich schnell einen Cache erstellen, da unser Hauptaugenmerk auf Entity Framework Core liegt. Ansonsten in unseren regelmäßigen Webinaren NCache Architektur oder Skalierung von Azure-Anwendungen mit NCache, sprachen diese Webinare ausführlich über all diese Funktionen. In diesem speziellen Webinar werde ich also einfach weitermachen und schnell einen Cache erstellen. Richtig, also würde ich den Standardport TCP/IP angeben und diesen Cache starten und automatisch starten, damit er automatisch gestartet wird, wenn Ihr Server neu gestartet wird. Das ist es also schon.
Stress simulieren und Cache-Statistiken überwachen
In Bezug auf Cache-Konfigurationen müssen Sie nur diesem Assistenten folgen, und das würde einen Cache auf mehreren Servern erstellen. Ich glaube, es hat auch angefangen. Ich würde das Statistikfenster öffnen und dann würde ich öffnen NCache Monitorfenster, das ein weiteres Tool ist, das mit installiert wird NCache. Derzeit gibt es keine Aktivität, aber ich kann fortfahren und eine Belastungstest-Tool-Anwendung ausführen. Es heißt Test-Stress-Tool und simuliert eine Dummy-Aktivität, eine Dummy-Last auf meinem Cache-Cluster. Nur um zu überprüfen, ob alles richtig konfiguriert wurde. Richtig, Sie können ungefähr tausend bis fünfzehnhundert Anfragen pro Sekunde von Server eins sowie von Server zwei sehen. Insgesamt werden also etwa dreitausend Anfragen pro Sekunde verarbeitet, und Sie können die Latenz überprüfen. Wir haben eine sehr minimale durchschnittliche Mikrosekunde pro Cache-Vorgangslatenz. Ich denke, es liegt irgendwo dazwischen, irgendwo zwischen vier und fünf Mikrosekunden.
Diese Grafik würde also aktualisiert und die Einheit würde abfallen. Sobald wir, wissen Sie, etwas mehr Ladung hinzufügen. Lassen Sie uns tatsächlich weitermachen und das tun. Recht. Also, ich habe eine andere Instanz am Laufen. Nur um Ihnen zu zeigen, dass es jetzt genau hier den erhöhten Wert anzeigen sollte, los geht's. Also, wir haben ungefähr, vorher wurden ungefähr XNUMX Quests pro Sekunde von jedem Server gehandhabt. Jetzt sind es irgendwo zwischen zweitausend und dreitausend Anfragen pro Sekunde von jedem Server, und Sie können sehen, dass die durchschnittliche Mikrosekunde pro Cache-Operation etwa fünfzig bis sechzig Mikrosekunden pro Operation beträgt. Das ist ein enormer Leistungsgewinn. Wenn man bedenkt, dass Ihre Anwendungen nicht ausgelastet sind oder Server überhaupt nicht ausgelastet sind. Sie können also bei der Verwendung von Ihren Anwendungen Antworten unter einer Millisekunde oder Mikrosekunde erwarten NCache. Unsere Umgebung ist also konfiguriert. Alles ist eingerichtet. Ich denke, wir können loslegen. Lassen Sie mich diese Tests beenden und weitermachen und unsere Beispielanwendung erstellen und überprüfen, die sich mit Caching-Szenarien befasst.
Welche EF Core-Entitäten sollen zwischengespeichert werden?
Lassen Sie uns zunächst darüber sprechen, wie das Caching in Entity Framework Core durchgeführt wird. Welche EF Core-Entitäten sollen zwischengespeichert werden? Sie haben normalerweise zwei Möglichkeiten. Möglicherweise haben Sie eine einzelne Entität oder ein Abfrageergebnis, bei dem es sich um eine Entitätssammlung handelt, richtig? Einzelne Entität zurückgegeben oder es könnte eine Sammlung sein. Einzelne Entität wird so gespeichert, wie sie ist. Die Sammlung kann als einzelnes Element gespeichert werden, oder jedes Sammlungselement kann auch einzeln im Cache hinzugefügt werden. Lassen Sie uns darüber sprechen, wie das geht.
Caching-Optionen für EF Core-Entitäten
Direkt NCache APIs. Es gibt zwei Ansätze. Zunächst einmal können Sie verwenden NCache APIs direkt, richtig? Das ist also etwas, das Sie auch in Open Source, Enterprise oder Professional verwenden können. Und dann haben wir Entity Framework Core Extension Methods, denen ich einige Zeit widmen werde.
Zwischenspeichern einer einzelnen EF Core-Entität: NCache Direkte APIs
Direkte APIs. Hier ist ein Detail der direkten APIs. Lassen Sie mich Ihnen das von hier aus zeigen, richtig?
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}Normalerweise ist dies also Ihre Get-Customer-Methode. Wenn Sie direkte APIs verwenden, haben Sie möglicherweise eine Kunden-ID. Also müssen Sie zuerst einen Cache-Schlüssel erstellen, richtig. Das ist also etwas, das Sie unbedingt tun müssen. Denn innen NCache alles wird in einem Schlüssel-Wert-Paar gespeichert. Key ist Ihr Zeichenfolgenschlüssel, um ein Objekt zu identifizieren. Ein Objektteil ist der tatsächliche Wert, die tatsächliche Eigenschaft, die Sie dem Cache hinzufügen möchten. Tatsächliche Daten, die Sie für Ihre Anwendung zwischenspeichern möchten.
Also, ich habe mir diese Schlüsselorganisation ausgedacht, wo ich Kunde als Schlüsselwort habe und dann Kunden-ID und dann gebe ich einen Laufzeitparameter an, der an mich weitergegeben wird, richtig? Das würde also diesen bestimmten Kunden genau hier identifizieren, mit der Kunden-ID etwas Einzigartiges, oder? Damit Sie diese Kunden eindeutig identifizieren können, rufen Sie dann cache.Get auf, um Elemente aus dem Cache abzurufen. Recht? Wenn Sie also Caching verwenden, müssen Sie zunächst sicherstellen, dass Sie den Schlüssel erstellt haben, und dann zuerst überprüfen, ob Daten im Cache verfügbar sind, indem Sie cache.Get aufrufen, und dieser Cache-Handle ist etwas das wird zurückgegeben, wenn Sie den Cache initialisieren, richtig?
Also, ich benutze diesen Cache genau hier, NCache.Cache initialisieren. Es ermöglicht Ihnen, den Cache zu initialisieren und sich mit ihm zu verbinden. Wenn Sie die Artikel im Cache finden, was bedeutet, dass der Kunde nicht null war, müssen Sie einfach von hier zurückkehren. Sie ersparen sich teure Fahrten zur Datenbank und das ist die Hauptmotivation, das Caching-System dort einzusetzen NCache hätte deine daten. So sparen Sie Ihre teuren Fahrten durch die Backend-Datenbank. Sie müssen nicht in die Datenbank gehen. Aber da es das erste Mal ist, dass diese Anwendung gestartet wird. In diesem Fall hätte der Cache also nicht die Daten.
In diesem Fall würden Sie also Entity Framework Core ausführen und innerhalb von Entity Framework Core verlinken. Es würde entweder ein einzelnes Element oder eine Sammlung zurückgeben. Es handelt sich um ein Einzelelement-Szenario, und dann rufen Sie cache.Insert auf, um dies tatsächlich für die nächste Verwendung hinzuzufügen und den Kunden ebenfalls zurückzugeben. Beim nächsten Mal würden Sie diese Daten also immer im Cache finden, solange sie nicht geändert oder nicht mit den Daten synchronisiert werden. Das ist also unsere einzige Verwendung von Entity, Direct APIs.
Zwischenspeichern der EF Core-Entitätssammlung: NCache Direkte APIs
Im Falle von Sammlungen sind direkte APIs sehr ähnlich.
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} Wir haben Kunden nach Stadt. Der Ort des Kunden ist ein Laufzeitparameter. Wir erstellen eine Kundenliste und versuchen, diese Sammlungsliste abzurufen NCache cache.Get, eine Kundenliste abrufen. Wenn das von hier nicht null ist, müssen wir es, wenn es null ist, aus der Backend-Datenbank abrufen und es für die nächste Verwendung auch in den Cache einfügen. So ist es also, und wenn Sie diese Kundenartikel einzeln speichern möchten, können Sie auch zu dieser custList iterieren und den Cache einzeln aufrufen. Einfügen, indem Sie auch für jeden Sammlungsartikel eindeutige Schlüssel angeben. Das ist also eine weitere Option, die Sie nutzen können.
Aber sehen Sie, Sie müssen zuerst einen Schlüssel konstruieren, um das Objekt aus dem Cache zu holen. Wenn es vorhanden ist, führen Sie die Nullbehandlung durch, und wenn es nicht vorhanden ist, holen Sie es aus der Datenbank, führen die Datenlogik aus und fügen es dann auch hinzu. Das ist also etwas, das Sie mit Direct zu tun haben NCache APIs. Dies ist der häufigste Anwendungsfall für ein typisches Datenbank-Caching. Für das Zwischenspeichern von App-Daten ist dies das, was Sie normalerweise tun würden.
Zwischenspeichern einer einzelnen EF Core-Entität – EF Core-Erweiterungsmethoden
Aber es gibt einen anderen Ansatz, nämlich durch unsere Erweiterungsmethoden, und das ist das wichtigste Highlight. Sie können die gesamte Sammlung als ein Element zwischenspeichern oder jedes Sammlungselement erneut separat zwischenspeichern, jedoch durch Erweiterungsmethoden.
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} Hier ist unsere erste Erweiterungsmethode, die ich Ihnen zeigen möchte. In Ordnung, es heißt From Cache, aber es erledigt eine Menge Automatisierung für Sie, richtig. Es funktioniert so, dass Sie zunächst einige Caching-Optionen erstellen können, richtig? Sie erstellen also zunächst Caching-Optionen, und eines der Attribute, die ich an dieser Stelle einführe, ist Store As. So, NCache würde es Ihnen ermöglichen zu wählen, ob eine Sammlung als einzelnes Exemplar, als einzelne Exemplare oder als Sammlungsexemplare gespeichert werden soll. Nehmen wir an, es gab 10 Artikel in der Sammlung. Diese würden also als 10 separate Elemente hinzugefügt NCache oder Sie möchten es als Sammlung speichern, die genau hier ist, oder? Das ist also die zweite Möglichkeit. In diesem Fall würde es als ein Element im Cache gespeichert.
Also verwende ich separate Entitäten. Also, wenn ich diesen Code hier ausführe, habe ich eine Erweiterungsmethode, die From Cache sagt, und wenn ich Ihnen die Definition davon zeige, kommt sie NCache Alachisoft .NCache.EntityFrameworkCore. Das ist der Hauptnamespace und wenn ich hierher komme und Ihnen die NuGet-Pakete zeige. Unter Installiert haben wir Alachisoft .NCache.EFCore NuGet-Paket. Das ist also das NuGet-Paket, das Sie einführen müssen, und danach können Sie mit diesen Erweiterungsmethoden beginnen. Zunächst einmal ist es ein Out-Reference-Cache-Schlüssel, also wird der Cache-Schlüssel von generiert NCache und dir gegeben. Das ist also die Flexibilität, und dann nimmt es einfach die Optionen als Parameter, richtig. Es erledigt also eine Menge Automatisierung und hinter den Kulissen erledigt es eine Menge Arbeit für Sie. FromCache funktioniert so, dass es zuerst automatisch Daten im Cache überprüft, das ist das Verhalten, wenn es feststellt, dass es nicht in die Datenbank geht.
Wenn es sich jedoch nicht im Cache befindet, würde es in der Regel zur Datenbank gehen und die Abfrage ausführen, die Ergebnismenge abrufen und dann im Cache hinzufügen, indem dieser Cache-Schlüssel ausgefüllt und dann diese Caching-Optionen für dieses Element eingerichtet werden . Wenn Sie es also mit diesem vergleichen, müssen Sie den Cache-Schlüssel nicht konstruieren. Sie müssen die Nullbehandlung oder das Abrufen aus dem Cache nicht selbst überprüfen. Sie müssen es nicht in den Cache einfügen. Sie müssen nur diese Erweiterungsmethode verwenden. Das macht viele Dinge automatisiert und das sehr vereinfachte Programmiermodell auch für Ihre Anwendungen.
Zwischenspeichern der EF Core-Entitätssammlung: EF Core-Erweiterungsmethoden
Und im gleichen Fall, in dem Sie es als Sammlung speichern möchten, geben Sie einfach die Caching-Optionen für die Sammlung an und in diesem Fall haben Sie eine Liste von Kunden, die Sie zurückgeben würden. Sie führen also einfach die Abfrage aus und rufen dann erneut FromCache auf. Damit ist unsere erste Erweiterungsmethode und Einführung in sie abgeschlossen.
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} Welche Daten sollen in EF Core zwischengespeichert werden?
Als nächstes werde ich über Referenz- und Transaktionsdaten sprechen. Dies ist das Hauptsegment.
Sie würden es mit Anwendungen zu tun haben, die viele Lesevorgänge haben, Daten mit vielen Lese- als Schreibvorgängen, und dann könnte es Anwendungsszenarien geben, in denen wir sowohl Lese- als auch Schreibvorgänge haben, richtig? So zum Beispiel Lookup-Datenprodukte, Mitarbeiter, die sich nicht so häufig ändern, aber es sind keine statischen Daten, es ist etwas, das sich ändert, aber die Änderungshäufigkeit ist nicht so groß, und ganze Daten sollten im Cache vorhanden sein. In diesem speziellen Szenario werde ich erklären, warum und Sie sollten dies nach einigen Stunden oder Tagen ablaufen lassen. So halten Sie den Cache frisch, das ist ein anderes Segment.
Dann haben wir Transaktionsdaten. Ich werde darüber sprechen, wie das Caching von Transaktionsdaten gehandhabt wird. Es wird dynamisch erstellt. Bestellungen, Konten, das sind Beispiele. Es ändert sich sehr häufig und typischerweise wurden Transaktionsdaten in der Vergangenheit nicht für das Caching bevorzugt. Da es sich ändern und von Ihrer Anwendung entfernen sollte, während Ihr Benutzer aktiv ist, wird es nur an diesem Punkt benötigt. Aufgrund unserer Erfahrung empfehlen wir Ihnen jedoch dringend, das Caching auch für Transaktionsdaten zu aktivieren. Denn obwohl Sie es nicht ändern, dass Daten noch aktiv sind, können Sie sie viele Male lesen, und wenn Sie Millionen von Benutzern angemeldet haben, würden dies zu Millionen von Anfragen nach diesen Daten führen, die an die Datenbank zurückgehen, und wenn Es wird zwischengespeichert und selbst wenn es zwei oder drei Anfragen sein könnten, während es sich ändert, wird es aus Leistungssicht immer noch von Vorteil sein. Wir empfehlen Ihnen daher dringend, einige Ihrer Transaktionen zwischenzuspeichern, wenn nicht sogar alle.
Zwischenspeichern von Referenzdaten in EF Core
In Ordnung, wie geht man mit dem Zwischenspeichern von Referenzdaten in EF Core um?
Ich habe dafür einen zweistufigen Prozess. Sie können ganze Daten in den Cache laden, das ist ein Muss. Daher sollten alle Ihre Referenzdaten in den Cache geladen werden, das empfehlen wir als ein Muss. Wieso den? Weil Sie überhaupt nicht in die Datenbank gehen wollen, oder? Sie sollten fortfahren und alle Ihre Daten aus der Datenbank laden NCache und wir haben eine Erweiterungsmethode, die sich sofort darum kümmert und dann nur den Cache verwendet und Datenbankausflüge vermeidet.
Schritt zwei ist immer das Cachen als separate Entitäten. Das ist ein weiterer Tipp, den ich Ihnen geben würde, dass Sie nicht alle Produkte oder andere, alle Produkte als Sammlung zwischenspeichern sollten, oder? Es können Tausende von Produkten oder Millionen von Produkten sein. Aber wenn Sie sie einzeln speichern, können Sie Teilmengen der Daten zu einem späteren Zeitpunkt abrufen, richtig. So laden Sie beispielsweise alle Produkte, benötigen aber später aus dem Cache nur noch abgekündigte Produkte. Also, wenn Sie sie einzeln im Cache gespeichert haben, sagen wir, sechzigtausend Produkte, das ist das Beispiel, das ich Ihnen zeigen werde. Sie können nur die finden, die Sie zu diesem Zeitpunkt benötigen. Sie müssen sich also nicht mit dem gesamten Produktdatensatz auseinandersetzen und sparen sich erneut teure Fahrten zur Datenbank.
Zwischenspeichern von Referenzdaten in EF Core: Preload-CacheWir haben also eine Erweiterungsmethode namens LoadIntoCache, die ich Ihnen als Nächstes zeigen werde, und ich werde Ihnen auch ein funktionierendes Beispiel dafür zeigen.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
Nun, LoadIntoCache, zunächst sollten die Caching-Optionen als „als separate Entitäten speichern“ festgelegt werden, und dann sollten Sie eine Abfrage ausführen, die alle Produkte laden sollte, und dann sollten Sie LoadIntoCache aufrufen und dann die Optionen bereitstellen, und es würde wiederum nur Cache-Schlüssel erstellen für alle diese einzeln, automatisch. Und es würde weiterhin all diese Elemente in den Cache laden, und dann können Sie LINQ-Abfragen wie diese ausführen, und diese LINQ-Abfrage ist dagegen NCache. Es verwendet keine Erweiterungsmethode. Es ruft Produkt in Datenbankprodukten auf, bei denen product.Discontinued und wir nur FromCache haben. Es geht überhaupt nicht in die Datenbank. Es kommt von NCache direkt.
Zwischenspeichern von Referenzdaten in EF Core: Suche nach Referenzdaten nur aus dem CacheWenn Sie Referenzdaten haben, sollten Sie zuerst separate Entitäten laden. Verwenden Sie Load into Cache, um alle Produkte hineinzuladen NCache. Sobald Sie das getan haben, müssen Sie nicht mehr zur Datenbank gehen. Dann verwenden Sie FromCacheOnly anstelle von FromCache. Die erste Erweiterungsmethode war FromCache, die den Cache eincheckt und dann zur Datenbank wechselt, wenn sie sich nicht im Cache befindet. Aber LoadIntoCache würde alle Produkte laden und dann würde FromCacheOnly sicherstellen, dass es nur mit dem Cache kommuniziert, wobei angenommen wird, dass alle Daten in den Cache geladen werden.
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}Lassen Sie mich diesen Code ausführen, damit Sie dies in Aktion sehen. Ich habe einen Cache, der genau hier für diesen Test konfiguriert ist, und ich werde Ihnen Statistiken zeigen. Ich habe damit herumgespielt. 60,000 Produkte werden geladen. Also, lassen Sie mich einfach fortfahren und den Inhalt löschen. Richtig, also schauen wir uns die Statistiken an. Wo ist mein Cache? Los geht's. Richtig, es sind also null Elemente und dann werde ich weitermachen und das ausführen. Es würde nur das einzelne Element zwischenspeichern und dann alle Codebeispiele sammeln, die ich Ihnen gezeigt habe, aber ich möchte Ihnen zeigen, wie LoadIntoCache funktioniert, und darauf basierend werde ich dort auch einen Haltepunkt setzen, los geht's.
Die ersten beiden Beispiele waren also das Laden eines einzelnen Artikels und dann das Laden einer Sammlung, des ursprünglichen Codes, den ich Ihnen gezeigt hatte, und dann lädt das hier tatsächlich alle Produkte, um Ihnen ein Referenzdatenszenario zu zeigen. Zunächst einmal speichert es als separate Entitäten und richtet einige Prioritäten ein, einige Abhängigkeiten, es ist in dieser Hinsicht aufwändig, und dann wird es weitermachen und alle Produkte laden, es aus der Datenbank holen, und ich empfehle Ihnen dringend, weiterzumachen Ladeprodukt, das nach einigen Intervallen in den Cache geladen wird, damit Sie Daten aus der Datenbank abrufen und das Laden in den Cache immer gegen die Datenbank arbeitet. Es wird immer in die Datenbank gehen und was auch immer Sie in der Datenbank haben, es wird gegen die Datenbank ausgeführt und diese Daten zurückgeholt NCache und anschließend FromCacheOnly verwenden.
So gehen Sie also mit Referenzdaten um. Zunächst einmal lagerst du sie einzeln, separat. LoadIntoCache unter Verwendung dieser Erweiterungsmethode LoadIntoCache, die immer für die Datenbank ausgeführt wird. Es hat keinen Cache als Priorität. Es würde immer gegen die Datenbank ausgeführt und dann alles zurückgeholt NCache und verwenden Sie dann FromCacheOnly. So einfach ist das.
Zwischenspeichern von Transaktionsdaten in EF Core
Transaktionsdaten. Sie können nur Arbeitssätze laden. Es ist für das Zwischenspeichern von Ergebnismengen, richtig?
Ich persönlich empfehle, dass Sie, wenn Sie an Kunden nach einer Stadt oder Bestellungen basierend auf einem Produkt interessiert sind, eine Art Ergebnissatz-Caching haben sollten, und genau das sollten Sie tun. Sie sollten sie als Sammlung oder getrennte Entitäten speichern, basierend auf der Größe der Ergebnisse. Wenn eine Sammlung nicht so groß ist, sagen wir, sie behandelt maximal 100 oder 200 Elemente, speichern Sie sie als Sammlung, und aber wenn vorhanden sind mehrere Produkte, mehrere Bestellungen oder Kundeninformationen, die als Transaktionsdaten kategorisiert würden. Speichern Sie sie als separate Einheit. Damit Sie davon eine Teilmenge erhalten und Ihre Caching-Nutzung maximieren können.
Zwischenspeichern von Transaktionsdaten in EF Core – Abrufen und Zwischenspeichern als SammlungDer Anwendungsfall dafür ist wieder sehr einfach. Sie speichern es einfach als Sammlung oder verwenden FromCache, Sie verwenden FromCacheOnly nicht, weil Sie zur Datenbank wechseln möchten, wenn sie sich nicht im Cache befindet.
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}Bisher haben wir drei Erweiterungsmethoden eingeführt. FromCache, das automatisch mit Cache und Datenbank arbeitet und nicht im Cache, den Sie aus der Datenbank erhalten würden. LoadIntoCache würde immer gegen die Datenbank ausgeführt werden. Holen Sie Objekte und bringen Sie sie in den Cache, und FromCacheOnly wird immer gegen den Cache ausgeführt, und das ist die einzige wahre Datenquelle. Es würde nicht in die Datenbank gehen. So, ich hoffe, das klärt einiges.
Cache frisch halten
Das nächste Segment basiert darauf, wie der Cache in Entity Framework Core aktualisiert wird, und das ist ein weiteres wichtiges Konzept, das Sie verstehen müssen, wenn Sie mit zwei verschiedenen Quellen arbeiten.
Sie haben Caching aktiviert. Sie haben eine Backend-Datenbank, die Ihre Hauptdatenquelle ist, einen persistenten Datenspeicher, und dann haben Sie Caching, das auch eine Kopie der Daten enthält. So stellen Sie sicher, dass der Cache im Vergleich zur Datenbank frisch ist. Also, lasst uns etwas Zeit hier verbringen.
Cache frisch halten: Referenzdaten
Zunächst einmal sollten Sie, da Sie den gesamten Datensatz im Cache haben, was tun, wenn es eine Änderung in der Datenbank gibt, richtig?
Sie müssen also Daten aus dem Cache verfallen lassen, und dafür empfehlen wir, dass Sie den Ablauf verwenden und dann die Daten automatisch neu laden. Dies könnte eine Option sein. Strategie eins ist also, dass Sie das Ablaufdatum verwenden, aber ohne Neuladen. Jedes Mal, wenn Daten abgelaufen sind, werden sie automatisch auch in den Cache neu geladen, und dafür haben wir dieses Setup hier, Alle Produkte laden.
Strategie 1: Verwenden Sie Expiration, aber mit Auto-Reloadvoid LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Lassen Sie mich Ihnen das hier zeigen, richtig. Sie speichern sie also zunächst als separate Entitäten, da dies der Anwendungsfall für Referenzdaten ist. Sie laden sie wie alle Produkte und richten dann eine Art Ablauf und dann Optionen ein.SetResyncProvider, es sollte einen Reloading-Anbieter geben und dann Optionen einrichten.IsSyncEnabled auf true. Also, automatisches Neuladen, damit es automatisch neu in den Cache geladen wird, falls es abläuft, richtig. Dies sind also die beiden Eigenschaften, zusammen mit SetResyncProviderName, die das Auto-Reload-Flag automatisch auf „true“ setzen würden.
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}Und dann brauchen Sie ResyncProvider genau hier, das heißt, unsere Beispielimplementierung ist genau hier, die ich zeige.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}Los geht's. Sie müssen unseren IReadThruProvider implementieren. Initialisieren Sie Ihre Datenquelle, entsorgen Sie sie am Ende, und dann können Sie mit LoadFromSource den Schlüssel abrufen, und basierend auf diesem Schlüssel konstruieren Sie einen SQL-Befehl und holen die Elemente aus der Datenbank. Ich habe hier eine Beispielimplementierung angegeben, in der wir a konstruieren SQL-Abfrage aus dem Cache-Schlüssel, den wir haben.
Richtig, dieser Schlüssel in dieser Beispielimplementierung ist also auch auf GitHub verfügbar. Es funktioniert also so, dass Ihre Elemente, die in den Cache geladen werden, ein Ablaufdatum haben, wenn ich das Laden in den Cache noch einmal ausführe. Sie würden also nach fünf bis zehn Stunden ablaufen, je nachdem, was die Ablaufzeit ist, und danach würde dieser Anbieter eingreifen und LoadFromSource mithilfe des Read-Through-Handlers automatisch aufrufen und aktualisierte Daten einbringen NCache. Richtig, Ihr Cache wäre also automatisch frisch, nachdem die Elemente abgelaufen sind.
Strategie 2: Verfall nicht verwenden, manuell neu ladenDer zweite Ansatz, den ich persönlich empfehle, ist, keinen Ausdruck zu verwenden und manuell neu zu laden, indem Sie LoadIntoCache aufrufen. Und das ist etwas sehr Einfaches, dass Sie sich diese LoadIntoCache-Methode einfallen lassen sollten, wenn ich es Ihnen noch einmal zeige. Rufen Sie diese Methode nach einigen Intervallen immer wieder auf und verwenden Sie keinen Ausdruck. Lassen Sie uns diese loswerden.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}Sie wissen also, dass dies die Referenzdaten sein werden, die nur für eine Stunde, zwei Stunden, fünf Tage, eine Woche oder einen Monat gültig sind. Darauf aufbauend wiederholen Sie das Laden aller Produkte. Dies sollte nach einigen Intervallen aufgerufen werden, oder?
Das ist also die Idee, dass Sie Daten manuell neu laden sollten, basierend auf einer intelligenten Schätzung des Ablaufintervalls, richtig? Sie sollten sich also eine Arbeitszeit einstellen, nach der Sie automatisch alle Produkte laden sollten. Damit es die Daten automatisch aus der Backend-Datenbank holt und Ihre Referenzdaten aktuell bleiben.
Also werde ich diese wiederholen. Es gibt also zwei Möglichkeiten. Wenn Sie Ablaufdaten verwenden, werden diese aus dem Cache entfernt. Sie würden also mit Teilsätzen enden, also müssen Sie unbedingt automatisch neu laden. Wenn Sie jedoch kein Ablaufdatum verwenden, haben Sie alle Daten immer im Cache für Referenzdaten und können diese Daten dann nach bestimmten Intervallen manuell neu laden. Ich hoffe, das klärt auf.
Halten Sie den Cache frisch: Transaktionsdaten
Als nächstes würde ich darüber sprechen, den Cache für Transaktionsdaten frisch zu halten, und das ist ziemlich einfach. Sie sollten immer eine kurze Ablaufzeit ohne automatisches Neuladen verwenden. Denn das sind wieder kurzlebige Daten, die nur fünf bis zehn Minuten gültig sein können, und Sie sollten FromCache verwenden, sodass Sie sie, wenn sie nicht im Cache sind, immer aus der Backend-Datenbank holen sollten.
Und hier ist ein Beispiel dafür, wo wir Kundenaufträge haben, sie als Sammlung oder Einzelstücke lagern, es liegt ganz bei Ihnen. Kurzes Ablaufdatum, falls erforderlich, oder verwenden Sie kein Ablaufdatum, oder verwenden Sie das Ablaufdatum und verwenden Sie dann kein automatisches Neuladen für diese Angelegenheit. Damit es aus der Datenbank abgerufen wird, sobald es abgelaufen ist. Ich persönlich empfehle, einen konfigurierbaren Ablauf zu verwenden oder sich den Ablauf auszudenken, von dem Sie sicher wissen, dass dies eine Arbeitszeit für diesen Datensatz ist. Damit es danach nicht mehr benötigt wird. Es sollte also automatisch ablaufen und dann würden Sie an diesem Punkt einen Datenbankzugriff erzwingen und Sie erhalten es automatisch von der Backend-Datenbank.
Kurze Ablaufzeit, kein automatisches Neuladen private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}Wir haben also den Umgang mit Referenzdaten und Transaktionsdaten behandelt. Dann haben wir auch behandelt, wie Sie den Cache als Referenz sowie Transaktionsdaten aktuell halten.
Umgang mit Beziehungen im Cache
Eins zu viele
Ein paar andere Dinge, auf die Sie beim Caching stoßen können. Umgang mit Beziehungen im Cache für EF Core. Wieder ist es sehr einfach. Include wird unterstützt, wenn Sie also eine Region mit Datenbankregionen haben, erhalten Sie neben ihnen region.Territories, richtig? Sie können also FromCache aufrufen und es würde Regionen separat und Territorien separat speichern und sie würden eine Beziehung zwischen Region und Territorien formulieren. Wenn ich Ihnen also zeige, erhalten Sie eine Region mit Gebieten.
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}Das ist ein Beispiel hier. Recht. Diese Regionsdetails beinhalten also und dann verwenden wir FromCache. Also werden wir sowohl Regionen als auch Regionsgebiete separat speichern, separate Elemente und dann werden wir eine schlüsselbasierte Abhängigkeit konstruieren. Wenn Regionen einen Wandel durchlaufen, werden auch Territorien entwertet und umgekehrt. So würden Sie also Eins-zu-eins- oder Eins-zu-viele-Beziehungen handhaben.
Zwischenspeichern von aggregierten Operationen
Aggregatoperationen werden ebenfalls unterstützt. Sie können diese Erweiterungsmethoden also mit einem Deferred First oder Default, FromCache, ausführen. Es kann auf Deferred Count, FromCache basieren. Also würde es sie als Ergebnismenge speichern, richtig? Es spielt also keine Rolle, ob Sie sie als Sammlung oder einzelne Elemente speichern, da dies nur das Ergebnis von Aggregatoperationen ist. Das ist also eine weitere Möglichkeit mit unserem Entity Framework.
Zwischenspeichern von aggregierten Vorgängen – Zurückgebende Entitäten
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}Zwischenspeichern von aggregierten Operationen – Rückgabe von Werten
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}Verteilte Caching-Architektur
Gegen Ende möchte ich also über einige architektonische Details zum verteilten Caching sprechen. Warum Sie darüber nachdenken sollten. Es ist hochverfügbar, es ist super zuverlässig, mit Replikation. Es ist ein Cache mit Peer-to-Peer-Architektur. Es gibt keinen Single Point of Failure. Sie können beliebige Server zur Laufzeit hinzufügen oder entfernen, und für Clients ist Verbindungs-Failover-Unterstützung aufgebaut. Es ist also hochverfügbar und superzuverlässig mit 100 % Betriebszeit. Es enthält viele Caching-Topologien, Client-Cache, WAN-Replikation, partitionierte und partitionierte Replikate, und ich kann speziell auf architektonische Details eingehen, wenn es sonst noch Fragen gibt, an dieser Stelle endet unsere Präsentation.
Hochverfügbarkeit
Caching-Topologien
Client-Cache (in der Nähe von Cache)
WAN-Replikation des Cache
Zusammenfassung
Dazu möchte ich eine kurze Zusammenfassung geben. In diesem Webinar haben wir über Caching-Optionen, direkte APIs und Entity Framework Core-Erweiterungsmethoden gesprochen. Wir haben also die Möglichkeit, zwischen diesen zu wählen. Wir haben uns mehr auf Entity Framework Core Extension Methods konzentriert, weil wir das gerne projizieren würden. Es ist einfacher zu bedienen. Umgang mit Referenz- und Transaktionsdaten. Wir haben also über Ansätze gesprochen, ganze Daten für Referenzdaten zu laden und dann den Ansatz mit separaten Entitäten zu verwenden und dann den Cache nur für alle Daten zu verwenden, die Sie im Cache haben. Für Transaktionsdaten empfehlen wir, nur die Ergebnismenge zwischenzuspeichern und dann die FromCache-Erweiterungsmethode zu verwenden, damit Sie zur Datenbank wechseln können, wenn sie sich nicht im Cache befindet. Und um den Cache frisch zu halten, haben wir darüber gesprochen, dass Sie den Ablauf mit automatischem Neuladen für Referenzdaten verwenden oder den Ablauf nicht verwenden, sondern nach bestimmten Intervallen manuell neu laden sollten, und für Transaktionsdaten sicherstellen, dass Sie den Ablauf verwenden, richtig? Das sollte ein kurzer Ablauf sein, aber ohne automatisches Neuladen, sodass Sie zur Datenbank zurückkehren und Ihren Cache bei der nächsten Verwendung aktualisieren können.
Sie erreichen uns jederzeit unter support@alachisoft.com. Bei technischen Fragen erreichen Sie uns auch unter sales@alachisoft.com. Wenn Sie sich das Produkt ansehen möchten, können Sie es herunterladen NCache Enterprise für eine 30-tägige kostenlose Testversion.