Vorwort
Im April ging ein Freund zu einem Interview nach Meituan. Er sagte, er sei gefragt worden, wie man die Konsistenz von Dual-Write zwischen Redis und MySQL sicherstellen könne. Bei dieser Frage geht es tatsächlich darum, wie die Konsistenz von Cache und Datenbank in einem Double-Write-Szenario sichergestellt werden kann. In diesem Artikel erfahren Sie, wie Sie diese Frage beantworten können.
Sprechen Sie über Konsistenz
Konsistenz ist die Konsistenz von Daten. In einem verteilten System kann sie als die Konsistenz von Daten in mehreren verstanden werden Knoten Die Werte sind konsistent.
-
Starke Konsistenz: Diese Konsistenzstufe entspricht am ehesten der Intuition des Benutzers, was das System zum Auslesen benötigt. Die Benutzererfahrung ist gut, aber ihre Implementierung hat oft einen großen Einfluss auf die Leistung das System
-
Schwache Konsistenz: Diese Konsistenzstufe beschränkt das System darauf, nicht zu versprechen, dass der geschriebene Wert unmittelbar nach erfolgreichem Schreiben gelesen werden kann, und es verspricht auch nicht, wie lange es dauern wird, bis die Daten konsistent sind, aber es wird sein Bestes geben, um sicherzustellen, dass die Daten nach einer Zeitebene (z. B. der zweiten Ebene) konsistent sind.
-
Endgültige Konsistenz : Die endgültige Konsistenz ist ein Sonderfall schwacher Konsistenz stellt sicher, dass innerhalb eines bestimmten Zeitraums ein datenkonsistenter Zustand erreicht werden kann. Der Grund, warum die ultimative Konsistenz hier separat erwähnt wird, liegt darin, dass es sich um ein sehr angesehenes Konsistenzmodell in schwacher Konsistenz handelt und es auch ein in der Branche hoch angesehenes Modell für die Datenkonsistenz in großen verteilten Systemen ist. Drei Klassiker: Der Caching-Modus
Caching kann die Leistung verbessern und die Datenbank entlasten, aber die Verwendung von Cache kann auch zu
Dateninkonsistenz
führen. Wie verwenden wir den Cache im Allgemeinen? Es gibt drei klassische Caching-Muster:
Cache-Aside-Muster
Read-Through/Write-through- Write behind
-
- Cache-Aside-Muster
Cache-Aside-Muster, das heißt
Bypass Cache Mode
Es wird vorgeschlagen, das Problem der Dateninkonsistenz zwischen Cache und Datenbank so weit wie möglich zu lösen.
Cache-Aside-Lesevorgang
Cache-Aside-Muster
Der Leseanforderungsprozess ist wie folgt:
Lesen Sie beim Lesen zuerst den Cache, werden die Daten direkt zurückgegeben
Wenn der Cache nicht erreicht wird, lesen Sie einfach die Datenbank, rufen Sie die Daten aus der Datenbank ab, legen Sie sie in den Cache und geben Sie gleichzeitig die Antwort zurück.
- Cache-Aside-Schreibprozess
-
Cache-Aside-Muster
Der Schreibanforderungsprozess ist wie folgt:
Beim Aktualisieren
aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache
.
Read-Through/Write-Through (Lese-/Schreibdurchdringung)
Read-/Write-Through
-Modus verwendet der Server den Cache als Hauptdatenspeicher. Die Interaktion zwischen der Anwendung und dem Datenbankcache wird über die
abstrakte Cacheschicht
vervollständigt. Durchlesen
Durchlesen
Der kurze Vorgang ist wie folgt: Daten aus dem Cache lesen, lesen und direkt zurückgeben
Wenn sie nicht gelesen werden können, laden Sie sie aus der Datenbank und schreiben Sie Legen Sie es dann in den Cache zurück.
Ist dieser kurze Prozess ähnlich wie
Cache-Aside
? Tatsächlich ist
Read-Through
lediglich eine zusätzliche Schicht von - Cache-Provider
. Dadurch wird der Programmcode prägnanter und die Belastung der Datenquelle verringert. Im - Write-Through
Write-Through-Modus schließt die Cache-Abstraktionsschicht auch die Aktualisierung der Datenquelle und der zwischengespeicherten Daten ab:
Schreiben hinter ( asynchrones Cache-Schreiben)
Write behind
ähnelt Read-Through/Write-Through, da
für das Lesen und Schreiben von Cache und Datenbank verantwortlich ist. Es gibt einen großen Unterschied zwischen ihnen:
Read/Write Through
aktualisiert den Cache und die Daten synchron, während
Write Behind nur den Cache aktualisiert, die Datenbank nicht direkt aktualisiert und die Datenbank über Batch asynchron aktualisiert. 
Auf diese Weise ist die Konsistenz zwischen Cache und Datenbank nicht stark
Systeme mit hohen Konsistenzanforderungen sollten mit Vorsicht verwendet werden. Es eignet sich jedoch für häufige Schreibszenarien. Der „InnoDB Buffer Pool“-Mechanismus von MySQL verwendet diesen Modus. Sollten Sie beim Betrieb des Caches den Cache löschen oder aktualisieren? Cache ProviderIn allgemeinen Geschäftsszenarien verwenden wir den Cache-Aside-Modus.
Einige Freunde fragen sich vielleicht: Cache-AsideWarum beim Schreiben einer Anfrage den Cache löschen, anstatt ihn zu aktualisieren?
Sollten wir den Cache löschen oder aktualisieren, wenn wir den Cache betreiben? Schauen wir uns zunächst ein Beispiel an:
- Thread A initiiert zunächst einen Schreibvorgang, der erste Schritt besteht darin, die Datenbank zu aktualisieren
- Thread B initiiert dann einen Schreibvorgang und der zweite Schritt aktualisiert die Datenbank
- Aufgrund von Aus Netzwerk- und anderen Gründen hat Thread B zuerst den Cache aktualisiert
- Thread A hat den Cache aktualisiert.
Zu diesem Zeitpunkt speichert der Cache die Daten von A (alte Daten) und die Datenbank speichert die Daten von B (neue Daten). Die Daten sind inkonsistent und es werden fehlerhafte Daten angezeigt. Wenn Sie den Cache löschen, anstatt ihn zu aktualisieren, tritt dieses Problem mit schmutzigen Daten nicht auf. Das Aktualisieren des Caches hat im Vergleich zum Löschen des Caches zwei Nachteile:
Wenn der von Ihnen geschriebene Cache-Wert nach komplexen Berechnungen ermittelt wird. Wenn der Cache häufig aktualisiert wird, wird Leistung verschwendet. Wenn es viele Datenbankschreibszenarien und wenige Datenleseszenarien gibt, werden die Daten häufig vor dem Lesen aktualisiert, was auch zu Leistungseinbußen führt (eigentlich ist Caching in Szenarien mit viel Schreibvorgang nicht die beste Lösung). Sehr kostengünstig)
- Sollte bei doppeltem Schreiben zuerst die Datenbank oder der Cache betrieben werden?
- Im
Cache-Aside-Cache-Modus haben einige Freunde immer noch Fragen: Warum die Datenbank zuerst betreiben
? Warum
nicht zuerst den Cache bedienen
?
Cache-Aside缓存模式中，有些小伙伴还是有疑问，在写入请求的时候，为什么是先操作数据库呢？为什么不先操作缓存呢？
假设有A、B两个请求，请求A做更新操作，请求B做查询读取操作。
- 线程A发起一个写操作，第一步del cache
- 此时线程B发起一个读操作，cache miss
- 线程B继续读DB，读出来一个老数据
- 然后线程B把老数据设置入cache
- 线程A写入DB最新的数据
酱紫就有问题啦，缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-AsideAngenommen, es gibt zwei Anfragen, A und B, die A auffordern, den Aktualisierungsvorgang durchzuführen, und B auffordern, den Abfrage- und Lesevorgang durchzuführen.
Thread A Initiieren Sie einen Schreibvorgang. Der erste Schritt besteht darin, den Cache zu löschen. Zu diesem Zeitpunkt initiiert Thread B einen Lesevorgang, einen Cache-Fehler. Thread B liest weiterhin die Datenbank und liest alte Daten aus Daten in den Cache
Thread A schreibt die neuesten Daten in die Datenbank
Es liegt ein Problem mit Jiang Zi vor. Die Daten im Cache und in der Datenbank sind inkonsistent. Der Cache speichert alte Daten und die Datenbank speichert neue Daten
. Daher wählt der Caching-Modus Cache-Aside zuerst die Datenbank und nicht zuerst den Cache.
Cache-verzögertes doppeltes Löschen- Einige Freunde sagen vielleicht, dass Sie nicht zuerst die Datenbank bedienen müssen, sondern einfach die Strategie
- Cache-verzögertes doppeltes Löschen
verwenden müssen? Was ist eine verzögerte doppelte Löschung? -
Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank.
Schlafen Sie eine Weile (z. B. 1 Sekunde) und löschen Sie den Cache erneut.
Wie lange dauert es normalerweise, eine Weile einzuschlafen? Sind sie alle 1 Sekunde lang? Diese Ruhezeit = die Zeit, die zum Lesen von Geschäftslogikdaten benötigt wird + ein paar hundert Millisekunden. Um sicherzustellen, dass die Leseanforderung endet, kann die Schreibanforderung zwischengespeicherte fehlerhafte Daten löschen, die möglicherweise durch die Leseanforderung mitgebracht wurden.
Cache-Wiederholungsmechanismus löschenOb es sich um
verzögertes doppeltes Löschen
oder
Cache-Aside handelt, das zuerst die Datenbank betreibt und dann den Cache löscht
, wenn der zweite Schritt des Löschens des Caches fehlschlägt, führt dies zu einem Löschfehler schmutzige Daten ~
- Wenn das Löschen fehlschlägt, löschen Sie sie einige Male, um sicherzustellen, dass das Löschen des Caches erfolgreich ist ~ Daher können Sie den
Cache-Wiederholungsmechanismus zum Löschen von Caches einführen-
-
-
- Schreibanforderung, um die Datenbank zu aktualisieren
Cache-Löschung ist aus bestimmten Gründen fehlgeschlagen
Legen Sie den Schlüssel, der nicht gelöscht werden konnte, in die Nachrichtenwarteschlange.Lesen Sie Nachrichten aus der Nachrichtenwarteschlange, um den zu löschenden Schlüssel zu erhalten asynchrones Löschen des Caches
Löschung erneut versuchen Der Cache-Mechanismus ist in Ordnung, d. h. Es führt zu vielen Eingriffen in den Geschäftscode. Tatsächlich können Sie den Schlüssel auch asynchron über das Binlog der Datenbank entfernen. 
Am Beispiel von MySQL können Sie den Alibaba-Kanal verwenden, um Binlog-Protokolle zu sammeln und an die MQ-Warteschlange zu senden, und dann die Aktualisierungsnachricht über den ACK-Mechanismus zu bestätigen und zu verarbeiten, den Cache zu löschen und die Daten-Cache-Konsistenz sicherzustellen Empfohlenes Lernen: „
Redis-Video-Tutorial
Das obige ist der detaillierte Inhalt vonWie kann die Doppelschreibkonsistenz zwischen Redis und MySQL sichergestellt werden? (Meituan Ermian). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
