Stellen Sie die Doppelschreibkonsistenz von MySQL und Redis sicher

1. Szenario:

Doppelte Schreibkonsistenz bedeutet, dass beim Aktualisieren der Daten in der Datenbank auch die Daten in Redis synchron aktualisiert werden müssen. Der Prozess des Lesens von Daten mithilfe von Redis. Wenn der Benutzer auf die Daten zugreift, werden die Daten im Cache direkt an den Benutzer zurückgegeben Im Cache wird zuerst die Datenbank abgefragt. Speichern Sie die abgefragten Daten im Cache und geben Sie sie dann an den Benutzer zurück.

2. Strategie zur Gewährleistung der Doppelschreibkonsistenz

1. Aktualisieren Sie zuerst den Cache, dann aktualisieren Sie die Datenbank

3. Löschen Sie dann den Cache Aktualisieren Sie die Datenbank

4, Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache

Drei, die Vor- und Nachteile der vier Strategien

1. Aktualisieren Sie zuerst den Cache und aktualisieren Sie dann die Datenbank

Das Problem ist Offensichtlich wird der Cache erfolgreich aktualisiert, die Datenbankaktualisierung schlägt jedoch fehl.

2. Aktualisieren Sie zuerst die Datenbank und dann den Cache.

Wenn die Parallelität hoch ist, kann die folgende Situation auftreten vorhanden. Wenn Thread A die Datenbank aus Netzwerk- oder anderen Gründen nicht aktualisiert hat, ist noch Zeit, den Cache zu aktualisieren Prozess A aktualisiert den Cache. Zu diesem Zeitpunkt geht die Aktualisierung des Caches durch Thread B verloren.

3 Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank. Diese Strategie hat möglicherweise den Cache-Verlust vermieden In Strategie 2 kommt es jedoch zu Inkonsistenzen. Beispielsweise führt Thread A zunächst den Cache aus und bereitet die Aktualisierung der Datenbank vor und greift nicht auf den Cache zu. Anschließend wird der alte Wert gelesen und der abgefragte alte Wert im Cache gespeichert. Nach Abschluss der Datenbankaktualisierung sind Datenbank und Cache wieder inkonsistent. Lösung: Wir müssen nur A erneut einfädeln. Nach Abschluss der Datenbankaktualisierung löschen Sie den Cache erneut mit einer leichten Verzögerung, was auch als verzögertes doppeltes Löschen bezeichnet wird. Die Verzögerungszeit muss dabei größer sein als die Zeit eines Lesevorgangs des Unternehmens.

4. Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache.

Egal wie hoch die Parallelität ist, es kommt zu Inkonsistenzen. Thread A liest beispielsweise Daten und bereitet sich darauf vor, in den Cache zu schreiben. Thread B aktualisiert die Datenbank und löscht dann den Cache. Zu diesem Zeitpunkt schreibt Thread A den alten Wert in den Cache, obwohl die Wahrscheinlichkeit, dass dies geschieht, relativ gering ist, da der Schreibvorgang länger dauert als ein Lesevorgang. Lösung: Verzögertes doppeltes Löschen ist immer noch ein Problem. Was soll ich tun, wenn das Löschen des Caches fehlschlägt? Natürlich erneut löschen und in einer Schleife fortfahren. Nachdem der Löschvorgang fehlgeschlagen ist, können wir den zu löschenden Schlüssel in die Warteschlange stellen und dann versuchen, ihn wiederholt zu löschen, bis der Löschvorgang erfolgreich ist.

Das obige ist der detaillierte Inhalt vonStellen Sie die Doppelschreibkonsistenz von MySQL und Redis sicher. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!