Wie Redis den Cache aktualisiert

Es gibt vier Designmuster für den Redis-Update-Cache: Cache beiseite, Durchlesen, Durchschreiben, Hinter-Caching schreiben Schauen wir uns diese vier Muster nacheinander an.

Cache-Aside-Muster

Dies ist das am häufigsten verwendete Muster. Die spezifische Logik lautet wie folgt: (Empfohlenes Lernen: Redis-Video-Tutorial)

Fehler: Die Anwendung ruft die Daten zuerst aus dem Cache ab ruft die Daten aus der Datenbank ab und legt sie nach Erfolg in den Cache.

Treffer: Die Anwendung ruft Daten aus dem Cache ab und kehrt nach dem Abrufen zurück.

Update: Speichern Sie zuerst die Daten in der Datenbank und machen Sie dann nach Erfolg den Cache ungültig.

Beachten Sie, dass unser Update darin besteht, zuerst die Datenbank zu aktualisieren und dann nach Erfolg den Cache ungültig zu machen. Kann diese Methode also das weiter oben in diesem Artikel erwähnte Problem vermeiden? Wir können es herausfinden.

Einer ist der Abfragevorgang und der andere ist die Parallelität des Aktualisierungsvorgangs. Zunächst gibt es keinen Vorgang zum Löschen der Cache-Daten, sondern die Daten in der Datenbank werden zu diesem Zeitpunkt aktualisiert , der Cache ist noch gültig, also die Parallelität Der Abfragevorgang übernimmt Daten, die nicht aktualisiert wurden.

Der Aktualisierungsvorgang macht den Cache jedoch sofort ungültig und nachfolgende Abfragevorgänge ziehen die Daten aus der Datenbank. Im Gegensatz zum Logikproblem am Anfang des Artikels werden bei nachfolgenden Abfragevorgängen immer alte Daten abgerufen.

Read Through

Die Read Through-Routine dient dazu, den Cache während des Abfragevorgangs zu aktualisieren, d. h. wann Der Cache läuft ab (Ablauf oder LRU-Auslagerung). Cache Aside liegt in der Verantwortung des Aufrufers, die Daten in den Cache zu laden, während Read Through den Cache-Dienst verwendet, um die Daten selbst zu laden, sodass sie für die Anwendung transparent sind.

Write Through

Die Write Through-Routine ähnelt der Read Through-Routine, tritt jedoch auf, wenn Daten aktualisiert werden. Wenn bei einer Datenaktualisierung der Cache nicht erreicht wird, wird die Datenbank direkt aktualisiert und dann zurückgegeben. Wenn der Cache getroffen wird, wird der Cache aktualisiert und dann aktualisiert der Cache selbst die Datenbank (dies ist ein synchroner Vorgang)

Das Bild unten stammt aus dem Cache-Eintrag von Wikipedia. In unserem Beispiel können Sie den Speicher als Datenbank verstehen.

Write Behind Caching Pattern

Write Behind wird auch Write Back genannt. Einige Schüler, die den Kernel des Linux-Betriebssystems kennen, sollten mit dem Zurückschreiben sehr vertraut sein. Ist dies nicht der Seiten-Cache-Algorithmus des Linux-Dateisystems? Ja, Sie sehen, die Grundlagen sind alle gleich. Deshalb ist die Grundlage sehr wichtig. Ich habe das noch nie zuvor gesagt.

Write-Back-Routine, kurz gesagt, beim Aktualisieren von Daten wird nur der Cache aktualisiert, nicht die Datenbank, und unser Cache aktualisiert die Datenbank stapelweise asynchron.

Der Vorteil dieses Designs besteht darin, dass Daten-E/A-Vorgänge extrem schnell erfolgen (da es direkt im Speicher ausgeführt wird). Da es asynchron ist, kann das Zurückschreiben auch mehrere Vorgänge für dieselben Daten zusammenführen Die Leistungssteigerung ist ziemlich beeindruckend.

Das Problem besteht jedoch darin, dass die Daten nicht stark konsistent sind und verloren gehen können (wir wissen, dass ein abnormales Herunterfahren von Unix/Linux aus diesem Grund zu Datenverlust führt).

Im Software-Design ist es für uns grundsätzlich unmöglich, ein Design ohne Fehler zu erstellen, genauso wie beim Algorithmus-Design Zeit gegen Raum und Raum gegen Zeit ausgetauscht wird. Manchmal sind starke Konsistenz und hohe Leistung hoch Verfügbarkeit und hohe Leistung stehen im Widerspruch. Beim Softwaredesign ging es schon immer um Kompromisse.

Darüber hinaus ist die Implementierungslogik von Write Back relativ komplex, da sie nachverfolgen muss, welche Daten aktualisiert wurden und in die Persistenzschicht geleert werden müssen. Das Zurückschreiben des Betriebssystems wird nur dann wirklich beibehalten, wenn der Cache ungültig gemacht werden muss, beispielsweise wenn der Speicher nicht ausreicht oder der Prozess beendet wird usw. Dies wird auch als verzögertes Schreiben bezeichnet.

Es gibt ein Rückschreibe-Flussdiagramm auf Wikipedia. Die Grundlogik lautet wie folgt:

Weitere technische Artikel zu Redis finden Sie unter Erste Schritte mit Redis Erfahren Sie in der Tutorial-Spalte !

Das obige ist der detaillierte Inhalt vonWie Redis den Cache aktualisiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!