Programmiertechnologie-Cache-Schreibmethode (2)

Das letzte Mal haben wir hauptsächlich die verschiedenen Code-Implementierungen zum Lesen und Schreiben von Caches besprochen. Dieser Artikel setzt die letzte Frage fort und befasst sich weiterhin mit unseren verschiedenen Cache-Nutzungen im Laufe der Jahre.

1: Cache-Aufwärmen

Ein Klassenkamerad hat letztes Mal danach gefragt. Beim ersten Laden ist unser Cache leer, wie man ihn aufwärmt.

In eigenständigen Websituationen verwenden wir im Allgemeinen RunTimeCache. Im Vergleich zu dieser Situation:

1: Wir können im Startereignis aktualisieren

void Application_Start(object sender, EventArgs e)
{
       //刷新
}

2: Schreiben Sie eine einzelne Aktualisierungs-Cache-Seite, aktualisieren Sie sie manuell, nachdem Sie online gegangen sind, oder automatisch, wenn Sie den Anruf veröffentlichen aktualisieren oder einfach durch den Benutzer auslösen.

Im Fall von verteiltem Cache (Redis, Memcached):

Zum Beispiel: Wenn Dutzende von Servern zwischengespeichert werden, dauert es eine ganze Weile, bis der Cache gefüllt ist.

Diese Art des Vorheizens ist etwas komplizierter. Einige schreiben eine einzelne Anwendung, um sie auszuführen, während andere einen einzigen Framework-Mechanismus schreiben, um damit umzugehen (intelligenter).

Der Zweck besteht darin, bevor Sie online gehen: Alle Caches sind vorgeladen.

2: Mehrstufiger Cache

2.1 Einführung

Wir wissen, dass zwischen der CPU und dem Speicher im Allgemeinen Cache der ersten Ebene und Cache der zweiten Ebene vorhanden sind, um den Austausch zu erhöhen Geschwindigkeit.

Auf diese Weise kann die CPU beim Aufrufen einer großen Datenmenge den Speicher umgehen und ihn direkt aus dem CPU-Cache aufrufen, um die Lesegeschwindigkeit zu beschleunigen.

Die Eigenschaften des mehrstufigen Caches werden basierend auf dem CPU-Cache ermittelt:

1: Jede Cache-Ebene speichert einen Teil des Caches der nächsten Ebene.

2: Die Lesegeschwindigkeit nimmt mit der Stufe ab, auch die Kosten sinken und die Kapazität steigt.

3: Wenn die aktuelle Ebene fehlt, wird zur Suche zur nächsten Ebene gewechselt.

Bei der Entwicklung auf Unternehmensanwendungsebene hat die Verwendung von mehrstufigem Cache denselben Zweck und dasselbe Design, die Granularität ist jedoch gröber und flexibler.

Cache-Typdiagramm von lv1-lv6, geordnet nach Geschwindigkeit:

Beispiel für ein Level-3-Cache-Treffer-Flussdiagramm:

2.2 Thread-Caching

Webanwendungen sind von Natur aus Multithreading. Bei einigen öffentlichen Ressourcen müssen wir die Thread-Sicherheit berücksichtigen. Bisher müssen wir Sperren verwenden, um die Integrität und Richtigkeit der Daten sicherzustellen.

In Wirklichkeit muss ein Webserver mindestens Hunderte oder Tausende von Anfragen verarbeiten. Denken Sie darüber nach: In komplexen Geschäftsprozessen müssen wir jedes Mal sperren, wenn eine Funktion aufgerufen wird.

Es ist auch eine große Verschwendung des Servers. Durch Thread-Caching kann der Thread, der gerade Benutzeranfragen verarbeitet, nur das bekommen, was er benötigt.

public static ThreadLocal<UserScore> localUserInfo = new ThreadLocal<UserScore>();

Mit den von Net bereitgestellten lokalen Thread-Variablen können wir die Daten des aktuellen Benutzers am Anforderungseintrag abrufen.

Während des gesamten Lebenszyklus des Threads kann unsere Geschäftslogik diese Daten bedenkenlos nutzen und muss keine Thread-Sicherheit berücksichtigen.

Und wir müssen keine neuen Daten beschaffen, also müssen wir uns keine Sorgen über Datenverlust machen.

Da die Daten im aktuellen Thread-Zyklus vollständig und korrekt sind, werden neue Daten erst abgerufen, wenn der Benutzer zum zweiten Mal eine Anfrage initiiert.

Dies kann unseren Serverdurchsatz erheblich verbessern. Achten Sie darauf, die Daten beim Thread-Ausgang zu zerstören.

2.3 Speichercache

Ob es sich um einen Remote-Datenbank-Lesevorgang oder einen Cache-Server-Lesevorgang handelt. Es ist unvermeidlich, über Prozesse, Netzwerke und manchmal auch Computerräume hinweg zu kommunizieren.

Das häufige Lesen und Schreiben von Anwendungen verbraucht viel Geld auf den Web- und DB-Servern und die Geschwindigkeit ist viel langsamer als die des Speichers.

Es ist keine gute Idee, dem Code Sperren, Asynchronität oder sogar einen Server hinzuzufügen. Denn die Ladegeschwindigkeit ist für das Benutzererlebnis sehr wichtig.

Daher ist es sehr wichtig, lokalen Speicher als Second-Level-Cache in Projekten zu verwenden, die dies erfordern. Der Zweck ist 1: Anti-Parallelität, 2: Beschleunigung des Lesens.

Es gibt eine berühmte Cache-Fünf-Minuten-Regel, die besagt, dass ein Datenelement, auf das häufig zugegriffen wird, im Speicher abgelegt werden sollte.

Zum Beispiel: Wenn 100 gleichzeitige Anfragen vorliegen, führt das Sperren dazu, dass 99 Front-End-Threads warten. Diese 99 wartenden Threads verbrauchen tatsächlich Webserver-Ressourcen. Es nicht hinzuzufügen ist eine Cache-Lawine.

Wenn wir jede Minute einen Cache abrufen und ihn im Speicher zwischenspeichern, wird die Wartezeit von 99 Threads erheblich verkürzt.

2.4 Datei-Cache

Im Vergleich zum Speicher hat die Festplatte eine große Kapazität und ist schneller als das Netzwerk.

So können wir einige Daten, die sich nicht häufig ändern und Speicherplatz verschwenden, auf der lokalen Festplatte zwischenspeichern.

Wenn wir beispielsweise SQLite für einige Dateidatenbanken verwenden, können wir dies problemlos tun.

2.5 Verteilter Cache

Redis, Memcached usw. basierend auf dem Speichercache.

Casssandra, Mongodb usw. basierend auf der Datei nosql.

Redis und Memcached sind gängige Caches für verteilten Speicher und die größte Cache-Schicht zwischen Anwendungen und DB.

Nosql wird tatsächlich nicht nur zum Caching verwendet, sondern auch in der DB-Schicht einiger nicht zum Kerngeschäft gehörender Unternehmen.

2.6 DB-Cache

Diese DB-Schicht speichert hauptsächlich die aus den Originaldaten berechneten Ergebnisse im Cache. Und vermeiden Sie direkte Berechnungen per Webprogramm über SQL oder im Einsatz.

Natürlich können wir die berechneten Daten auch zum Caching in Redis speichern.

3: Mehrschichtiger Cache

Das Konzept des mehrschichtigen Caches wurde an vielen Stellen verwendet:

1: Was Wie wir oben sagten, handelt es sich beim Multi-Level-Cache um eine Art Cache, der Inhalte je nach Lesehäufigkeit auf verschiedenen Ebenen speichert. Je höher die Häufigkeit, desto näher ist sie.

2: Ein weiterer mehrschichtiger Ansatz besteht darin, Indizes zwischenzuspeichern, ähnlich der B-Tree-Suche, was die Abrufeffizienz verbessern kann.

3: Architektonisch gesehen sind Client-Caching, CDN-Caching, Reverse-Proxy-Caching und Server-Caching ebenfalls mehrschichtiges Caching.

Viertens: Zusammenfassung

In Bezug auf die Verwendung kann jeder verschiedene Kombinationen basierend auf tatsächlichen Szenarien erstellen. Dieser Artikel ist eher theoretisch und viele Details werden nicht näher erläutert.

Zum Beispiel die Verwendung von verteiltem Cache, Cache-Ersetzungsstrategie und -Algorithmus, Cache-Ablaufmechanismus usw. Werde später noch weitere hinzufügen.