Wie kann die Doppelschreibkonsistenz zwischen Redis und MySQL sichergestellt werden? (Meituan Ermian)

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.

• Github-Adresse, vielen Dank für jeden Stern

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.

1. 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
1. Cache-Provider
. Dadurch wird der Programmcode prägnanter und die Belastung der Datenquelle verringert. Im
2. 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:

1. Thread A initiiert zunächst einen Schreibvorgang, der erste Schritt besteht darin, die Datenbank zu aktualisieren
2. Thread B initiiert dann einen Schreibvorgang und der zweite Schritt aktualisiert die Datenbank
3. Aufgrund von Aus Netzwerk- und anderen Gründen hat Thread B zuerst den Cache aktualisiert
4. 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做查询读取操作。

1. 线程A发起一个写操作，第一步del cache
2. 此时线程B发起一个读操作，cache miss
3. 线程B继续读DB，读出来一个老数据
4. 然后线程B把老数据设置入cache
5. 线程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
1. Einige Freunde sagen vielleicht, dass Sie nicht zuerst die Datenbank bedienen müssen, sondern einfach die Strategie
2. 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 ~

1. 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
5. 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!