So synchronisieren Sie MySQL-Daten mit dem Redis-Cache

1 MySQL prüft die Daten und schreibt sie dann synchron auf Redis.

Nachteil 1: Es kommt zu einer Verzögerung der Schnittstelle, da das synchrone Schreiben auf Redis selbst eine Verzögerung aufweist und erneut versucht werden muss, wenn das Redis-Schreiben fehlschlägt Versuchen Sie es noch einmal, es wird länger dauern.

Nachteil 2: Wenn Redis abstürzt, wird der Thread direkt blockiert.

Nachteil 3: Wenn jemand die Datenbank ist, kann sie nicht synchronisiert werden, es sei denn, das entsprechende Redis wird manuell gelöscht, der Prozess zum Löschen von Redis ist jedoch ebenfalls vorhanden Zeitunterschied

2 MySQL überprüft die Daten und synchronisiert Redis im Consumer-Thread durch Senden von MQ

Nachteil 1: Es gibt mehr Schichten von MQ, was bedeutet, dass eine hohe Wahrscheinlichkeit besteht, dass es zu Synchronisationsverzögerungsproblemen kommt.

Nachteil 2: Es erfordert Verhindern Sie die Verfügbarkeit von MQ

Nachteil 3: Wenn ein Mensch die Datenbank ist, kann sie nicht synchronisiert werden

Vorteil 1: Das Problem der verzögerten Rückkehr der Schnittstelle kann erheblich reduziert werden

Vorteil 2: MQ selbst verfügt über einen Wiederholungsmechanismus Es ist keine manuelle Arbeit erforderlich. Schreiben Sie den Wiederholungscode.

Vorteil 3: Entkopplung, vollständige Trennung von MySQL-Abfrage und Redis-Synchronisierung, ohne sich gegenseitig zu stören.

3 Abonnieren Sie die MySQL-Binlog-Datei (kann mit Hilfe von Canal durchgeführt werden).

CanalServer tarnt sich als MysqlServer-Slave-Bibliothek.

Canal konfiguriert die entsprechende Nachrichten-MQ (RabbitMQ, RocketMQ, Kafka), wenn es Änderungen im Binlog erkennt In der Datei wird die geänderte SQL-Anweisung in das JSON-Format konvertiert und als Nachricht verwendet. Der Inhalt wird an MQ gesendet. Solange Sie im Projekt den entsprechenden MQ überwachen, können Sie den Inhalt von Binlog-Änderungen abrufen Daten haben einen klaren Operationstyp (CURD) und die entsprechenden Daten. Synchronisieren Sie einfach die entsprechenden Daten mit redis

Nachteil 1: Der gesamte Betriebsprozess des Kanalabonnements bei Binlog ist Single-Threaded, sodass die Leistung angesichts der extrem hohen Parallelität möglicherweise nicht hervorragend ist. Sie können mehrere Kanäle und mehrere Verbraucher bereitstellen, müssen jedoch darauf achten, wiederholte Verbrauchsprobleme zu vermeiden und eine idempotente Überprüfung durchzuführen

Vorteil 1: Selbst wenn die Datenbank manuell geändert wird, wird sie überwacht und synchronisiert

Vorteil 2: Asynchrone Synchronisierung , es wird keine zusätzliche Verzögerung bei der Schnittstellenrückgabe geben

4 Verzögertes doppeltes Löschen

Bevor Sie die geänderte SQL ausführen, löschen Sie zuerst die Redis-Daten.

Führen Sie die Update-SQL aus.

Verzögern Sie eine Zeit lang.

Löschen Sie die Redis-Daten erneut

// 延迟双删伪代码
deleteRedisCache(key);   // 删除redis缓存
updateMysqlSql(obj);        // 更新mysql
Thread.sleep(100);           // 延迟一段时间
deleteRedisCache(key);   // 再次删除该key的缓存

Nachteile: Diese Verzögerungszeit ist schwer zu kontrollieren. Wie lang die Verzögerung ist, ist schwer einzuschätzen.

Wenn Sie die verzögerte doppelte Löschung nicht verwenden, löschen Sie einfach den Cache und ändern dann die MySQL-Daten. Welche Probleme entstehen, wenn es nur diese beiden Schritte gibt?

5. Einzelne Anfrage, einzelner Thread ist kein Problem, aber bei hoher Parallelität und Multithreading treten Probleme auf

6 Wenn Thread1-Thread Daten aktualisieren möchte, bereinigt Thread1-Thread zu diesem Zeitpunkt

7 Diesmal kommt Thread2, aber Thread1 hat die Aktualisierung von MySQL noch nicht abgeschlossen.

8 Die Abfrage von Thread2 auf Redis muss zu diesem Zeitpunkt null sein Ich hatte keine Zeit, die MySQL-Daten zu ändern. Die von Thread2 zu diesem Zeitpunkt gefundenen Daten sind also [alte Daten], und Thread2 schreibt die alten Daten erneut nach Redis.

10 Zu diesem Zeitpunkt kommt der Thread3 und wenn er abfragt Redis stellt fest, dass Daten vorhanden sind. Zu diesem Zeitpunkt wurden die zwischengespeicherten Daten direkt abgerufen und mit den alten Daten zurückgegeben. Dies ist die zweite Löschfunktion des verzögerten doppelten Löschens soll verhindern, dass Thread2 die alten Daten erneut schreibt. Wenn Thread3 Redis abfragt, ist es immer noch null und es werden die neuesten Daten von mysql

12 abgerufen Die Zeit von der Überprüfung des Caches durch Thread2 bis zum Abrufen der MySQL-Daten und dem anschließenden Speichern in Redis ist die Verzögerungszeit von Thread1. Die Prozesszeit von Thread2 wird jedoch von vielen Faktoren beeinflusst, sodass es schwierig ist, zu bestimmen, wie lange sie dauern wird 5 Verzögertes doppeltes Schreiben und MySQL-Daten

T1-Thread beendet die Ausführung von updateMysqlSql und gibt die Zeilensperre frei. Zu diesem Zeitpunkt führt der T2-Thread updateMysqlSql und addRedis aus, und schließlich führt T1 addRedis aus. Diese Situation führt dazu, dass die Datenbank auf die Daten von T2 geändert wird Thread, aber Redis sind die Daten des T1-Threads und stellt so die Datenkonsistenz sicher. Es wird empfohlen, eine verteilte Sperre zu verwenden

Nachteil beim doppelten Schreiben: MySQL und Redis sind Single-Threaded. Die Leistung ist nicht gut, daher wird die Verwendung nicht empfohlen

Das obige ist der detaillierte Inhalt vonSo synchronisieren Sie MySQL-Daten mit dem Redis-Cache. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!