So stellen Sie die Double-Write-Konsistenz von MySQL und Redis sicher

1. Szenario:

Doppelte Schreibkonsistenz bedeutet, dass nach der Aktualisierung 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. Wenn der Cache erfolgreich aktualisiert wird, die Datenbankaktualisierung jedoch fehlschlägt, werden die Daten beschädigt.

2. Aktualisieren Sie zuerst die Datenbank und dann den Cache. Wenn die Parallelität hoch ist, kann die folgende Situation auftreten Thread A aktualisiert die Datenbank. Wenn Thread A aus Netzwerk- oder anderen Gründen nicht vorhanden ist, aktualisiert ein Prozess B die Datenbank 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 die Cache-Verlustsituation vermieden 2, aber egal wie hoch die Parallelität ist, es kommt zu Inkonsistenzen. Beispielsweise führt Thread A zuerst den Cache aus und bereitet die Aktualisierung der Datenbank vor Der Cache wird nicht aufgerufen. Anschließend wird der alte Wert gelesen und im Cache gespeichert. Nach Abschluss der Datenbankaktualisierung sind die Datenbank und der Cache wieder inkonsistent. Wir müssen nur A erneut einfädeln. Nach Abschluss der Datenbankaktualisierung wird der Cache mit einer leichten Verzögerung erneut gelöscht, 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.

Auch in Situationen mit hoher Parallelität kommt es zu Inkonsistenzen. Thread A bereitet sich beispielsweise darauf vor, in den Cache zu schreiben Auf die Datenbank wird zugegriffen und dann der Cache gelöscht. Zu diesem Zeitpunkt schreibt Thread A den alten Wert in den Cache. Die Wahrscheinlichkeit, dass dies geschieht, ist jedoch relativ gering, da der Schreibvorgang länger dauert als ein Lesevorgang. Alternativ können die ursprünglichen Wörter vereinfacht und umstrukturiert werden: Um Löschfehler zu beheben, wird empfohlen, eine Lösung mit verzögerter doppelter Löschung zu verwenden. Auch wenn beim verzögerten Doppellöschen weiterhin Probleme auftreten, kann der Löschvorgang wiederholt werden, bis der Cache vollständig geleert ist. Wenn der Löschvorgang fehlschlägt, können wir die zu löschenden Schlüssel in die Warteschlange stellen und versuchen, sie immer wieder zu löschen, bis der Löschvorgang erfolgreich ist.

Das obige ist der detaillierte Inhalt vonSo stellen Sie die Double-Write-Konsistenz von MySQL und Redis sicher. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!