Konsistenz der Cache-Daten
Solange der Cache verwendet wird, unabhängig davon, ob es sich um lokales Speicher-Caching oder Redis-Caching handelt, treten Probleme bei der Datensynchronisierung auf.
Lesen Sie zuerst die zwischengespeicherten Daten. Wenn zwischengespeicherte Daten vorhanden sind, wird das Ergebnis sofort zurückgegeben. Wenn keine Daten vorhanden sind, werden die Daten aus der Datenbank gelesen und die gelesenen Daten werden mit dem Cache synchronisiert, um die von zurückgegebenen Daten bereitzustellen die nächste Leseanforderung.
Dadurch kann der Druck auf die Datenbank effektiv verringert werden. Wenn die Daten jedoch geändert und gelöscht werden, kann der Cache die Änderung der Daten in der Datenbank nicht erkennen. Dies führt zu Inkonsistenzen zwischen den Daten in der Datenbank und den Daten im Cache.
Cache-Klasse aktualisieren
1.
Diese Option, zuerst den Cache und dann die Datenbank zu aktualisieren, ziehen wir im Allgemeinen nicht in Betracht. Der Grund dafür ist, dass die Cache-Aktualisierung erfolgreich war, beim Aktualisieren der Datenbank jedoch eine Ausnahme auftritt, 导致缓存数据与数据库数据完全不一致die schwer zu erkennen ist, da die Daten im Cache immer vorhanden sind.
2. Aktualisieren Sie zuerst die Datenbank und dann den Cache.
Wir ziehen diese Lösung im Allgemeinen nicht in Betracht. Der Grund ist der gleiche wie beim ersten. Die Datenbankaktualisierung ist erfolgreich, aber die Cache-Aktualisierung schlägt fehl. Das Gleiche 会出现数据不一致问题.
Cache-Klasse löschen
3. Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank. Diese Lösung liest fehlerhafte Daten und birgt das Risiko eines Ausfalls.
4. Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache.
Lesen Sie beim Lesen zuerst den Cache. Wenn kein Cache vorhanden ist, lesen Sie die Datenbank, nehmen Sie dann die Daten heraus und legen Sie sie ab es in den Cache und gibt gleichzeitig die Antwort zurück. Aktualisieren Sie beim Aktualisieren zuerst die Datenbank und löschen Sie dann den Cache. Gibt es in dieser Situation kein Parallelitätsproblem? (Problem mit schmutzigen Daten)
Nehmen wir an, dass es zwei Anfragen gibt, eine, die A auffordert, eine Abfrageoperation durchzuführen, und eine, die B auffordert, eine
Aktualisierungsoperation durchzuführen, dann werden die folgenden Situationen eintreten
(1) der Cache läuft gerade ab
(2) fordert A auf, die Datenbank abzufragen und Einen alten Wert abrufen
(3) Anforderung B schreibt den neuen Wert in die Datenbank
(4) Anforderung B, den Cache zu löschen
(5) Anforderung A, den gefundenen alten Wert in den Cache zu schreiben
Wenn die obige Situation auftritt, treten tatsächlich fehlerhafte Daten auf . Allerdings ist die Wahrscheinlichkeit, dass dies geschieht, gering (Schreibvorgänge werden schneller ausgeführt als Lesevorgänge)
. Aber was sollen wir tun, wenn wir dieses Parallelitätsproblem lösen müssen?
Zunächst einmal ist es eine Lösung, eine gültige Zeit für den Cache festzulegen.
Zweitens wird eine asynchrone Strategie zum verzögerten Löschen übernommen.
Was soll ich jedoch tun, wenn die Datenbank erfolgreich aktualisiert wurde, während der Cache-Löschphase jedoch ein Fehler auftritt und der Löschvorgang nicht erfolgreich ist? Dieses Problem besteht im Schema zum Löschen der Cache-Klasse, sodass beim Lesen des Caches zu diesem Zeitpunkt jedes Mal falsche Daten vorliegen.
Derzeit gibt es zwei Lösungen: Eine besteht darin, die Nachrichtenwarteschlange zu verwenden, um das Löschen zu kompensieren. Die spezifische Geschäftslogik wird in der Sprache wie folgt beschrieben:
(Nachdem die Aktualisierung erfolgreich war, schlägt der Löschvorgang fehl, eine Nachricht wird an die MQ-Warteschlange gesendet und der Verbraucher löscht den Redis-Schlüssel.)
1. Fordern Sie zuerst A auf, die Datenbank zu aktualisieren.
2. Nach dem Löschen von Redis Wenn ein Fehler gemeldet wird, schlägt der Löschvorgang fehl.
3. Zu diesem Zeitpunkt wird der Redis-Schlüssel als Nachrichtentext an die Nachrichtenwarteschlange gesendet.
4. Nachdem das System die von der Nachrichtenwarteschlange gesendete Nachricht empfangen hat,
5. Löschen Noch einmal Redis.
Diese Lösung hat jedoch einen Nachteil: Sie führt zu starken Eingriffen in den Geschäftscode und ist tief miteinander verbunden, sodass es zu diesem Zeitpunkt eine bessere Optimierungslösung gibt. Nach der Aktualisierung der MySQL-Datenbank können wir die finden Entsprechende Vorgänge im Binlog-Protokoll, dann können wir MySQL abonnieren. Das Binlog der Datenbank arbeitet im Cache.
Letztendlich besteht es darin, den Schlüssel asynchron über das Binlog der Datenbank zu entfernen, ein Tool (Kanal) zu verwenden, um das Binlog-Protokoll zu sammeln und an MQ zu senden, und dann das Löschen des Caches über den ACK-Mechanismus zu bestätigen.
Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache. Diese Methode wird als Cache Aside Pattern bezeichnet und ist eines der Entwurfsmuster für Cache-Updates.
Wenn Sie eine starke Konsistenz bei der Cache-Konsistenz anstreben, müssen Sie diese entweder serialisieren 要么使用分布式读写锁, die Konsistenz über 2PC oder das Paxos-Protokoll sicherstellen oder die Wahrscheinlichkeit schmutziger Daten während der Parallelität drastisch reduzieren.