Eine kurze Diskussion über die Synchronisierungslösung zwischen MySQL und Redis Cache

Dieser Artikel stellt zwei Lösungen zur Synchronisierung von MySQL und Redis Cache vor

• Lösung 1: Redis automatisch aktualisieren durch MySQL-Synchronisierung, MySQL-Trigger + UDF-Funktionsimplementierung
• Lösung 2: Analysieren Sie die Binlog-Implementierung von MySQL und synchronisieren Sie die Daten in der Datenbank mit Redis

1. Lösung 1 (UDF)

Szenarioanalyse: Wenn wir Datenoperationen in der MySQL-Datenbank durchführen, werden die entsprechenden Daten gleichzeitig mit Redis synchronisiert. Nach der Synchronisierung mit Redis wird die Abfrageoperation von Redis aus gesucht.

Der Ablauf ist in etwa wie folgt:

Setzen Sie einen Trigger für die in MySQL zu verarbeitenden Daten und überwachen Sie den Vorgang

Wenn der Client (NodeServer) Daten in MySQL schreibt, wird der Trigger ausgelöst und die MySQL UDF-Funktion wird nach dem Trigger aufgerufen

Die UDF-Funktion kann Daten in Redis schreiben, um einen Synchronisierungseffekt zu erzielen

Lösungsanalyse:

• Diese Lösung eignet sich für Szenarien, in denen mehr Lese- als Schreibvorgänge stattfinden und keine gleichzeitigen Schreibvorgänge stattfinden.
• Da MySQL-Trigger selbst zu einer Effizienzminderung führen, ist diese Lösung bei häufigem Bedienen einer Tabelle nicht geeignet.

Demo-Fall

Unten ist die MySQL-Tabelle

Unten ist der Analysecode von UDF

Definieren Sie den entsprechenden Trigger

2. Lösung 2 (Binlog analysieren)

Bevor wir Lösung 2 vorstellen, stellen wir zunächst das Prinzip der MySQL-Replikation vor, wie in der folgenden Abbildung dargestellt:

• Der Hauptserver verarbeitet die Daten und schreibt sie in das Bin-Protokoll.
• Der Slave-Server ruft den I/O-Thread auf, um das Bin-Protokoll des Master-Servers zu lesen und es in sein eigenes Relay-Protokoll zu schreiben. Anschließend ruft er den SQL-Thread auf, um die Daten aus dem Relay-Protokoll zu analysieren und mit seiner eigenen Datenbank zu synchronisieren.

Lösung 2 ist:

• Der gesamte Replikationsprozess von MySQL oben kann in einem Satz zusammengefasst werden: Lesen Sie die Daten im Bin-Protokoll des Masterservers vom Slave-Server und synchronisieren Sie sie mit seiner eigenen Datenbank
• Dasselbe gilt für unsere Lösung 2. Konzeptionell ändern wir den Master-Server in MySQL und den Slave-Server in Redis (wie in der folgenden Abbildung dargestellt). Wenn Daten in MySQL geschrieben werden, analysieren wir das MySQL-Bin-Protokoll und schreiben die analysierten Daten dann in Redis, um eine Synchronisierung zu erreichen.

Das Folgende ist beispielsweise eine Analyse einer Cloud-Datenbankinstanz:

Die Cloud-Datenbank und die lokale Datenbank stehen in einer Master-Slave-Beziehung. Die Cloud-Datenbank ist die primäre Datenbank, die hauptsächlich Schreibdienste bereitstellt, und die lokale Datenbank ist die sekundäre Datenbank, die Daten aus der primären Datenbank liest.

Nachdem die lokale Datenbank die Daten gelesen hat, analysiert sie das Bin-Protokoll und schreibt die Daten dann zur Synchronisierung in Redis. Der Client liest dann die Daten aus Redis.

Die Schwierigkeit dieser technischen Lösung liegt darin, das MySQL-Bin-Protokoll zu analysieren. Dies erfordert jedoch ein sehr tiefes Verständnis von Binlog-Dateien und MySQL. Gleichzeitig ist der Arbeitsaufwand für die Analyse von Binlog zur Erreichung der Synchronisierung sehr groß, da Binlog in mehreren Formen wie Anweisungs-/Zeilen-/Mischebene vorliegt.

Canal Open Source-Technologie

Canal ist ein Open-Source-Projekt von Alibaba, das in reinem Java entwickelt wurde. Basierend auf der inkrementellen Protokollanalyse der Datenbank bietet es inkrementelles Datenabonnement und -verbrauch. Derzeit unterstützt es hauptsächlich MySQL (unterstützt auch MariaDB).

Die Open-Source-Referenzadresse lautet: https://github.com/liukelin/canal_mysql_nosql_sync

Funktionsweise (Imitation der MySQL-Replikation):

• Canal simuliert das interaktive Protokoll des MySQL-Slaves, gibt sich als MySQL-Slave aus und sendet das Dump-Protokoll an den MySQL-Master
• Der MySQL-Master empfängt die Dump-Anforderung und beginnt mit dem Weiterleiten des Binärprotokolls an den Slave (Kanal).
• Canal analysiert binäre Log-Objekte (ursprünglich Byte-Streams)

Architektur:

Server stellt eine Kanallaufinstanz dar, die einer JVM entspricht

Eine Instanz entspricht einer Datenwarteschlange (ein Server entspricht 1..n Instanzen)

Instanzmodul:

• eventParser (Datenquellenzugriff, Simulation des Slave-Protokolls und der Master-Interaktion, Protokollanalyse)
• eventSink (Parser- und Store-Connector, führt Datenfilterung, -verarbeitung und -verteilung durch)
• eventStore (Datenspeicher)
• metaManager (inkrementeller Abonnement- und Verbrauchsinformationsmanager)

Der allgemeine Analysevorgang läuft wie folgt ab:

• Parse analysiert das MySQL Bin-Protokoll und legt die Daten dann in den Sink
• Sink filtert, verarbeitet und verteilt Daten
• Der Store liest die analysierten Daten aus dem Sink und speichert sie
• Verwenden Sie dann den Designcode, um die Daten im Store mit Redis zu synchronisieren.
• Darunter wird Parsen/Sinken vom Framework gekapselt, und was wir tun, ist der Schritt des Lesens der Daten aus dem Store.

Weitere Informationen zu Cancel finden Sie unter Baidu.

Nachfolgend sehen Sie das Betriebstopologiediagramm

Bei der Synchronisierung von MySQL-Tabellen wird das Verantwortungskettenmodell verwendet, und jede Tabelle entspricht einem Filter . Beispielsweise sieht das in zvsync verwendete Klassendesign wie folgt aus:

Im Folgenden sind die im konkreten zvsync verwendeten Klassen aufgeführt . Immer wenn eine Tabelle hinzugefügt oder gelöscht wird, kann sie direkt hinzugefügt oder gelöscht werden.

3. Weitere

Die obige Einführung in diesem Artikel befasst sich mit der Synchronisierung von MySQL zum Cache. In der tatsächlichen Entwicklung verwenden manche Benutzer jedoch möglicherweise die folgende Lösung:

• Wenn der Client Daten empfängt, werden diese zuerst in Redis gespeichert und dann mit MySQL synchronisiert.
• Diese Lösung ist von Natur aus unsicher/unzuverlässig, sodass bei einer kurzen Ausfallzeit oder einem Fehler von Redis Daten verloren gehen.

Damit ist dieser Artikel über die Synchronisierungslösung für MySQL und Redis-Cache abgeschlossen. Weitere Informationen zur Synchronisierung von MySQL und Redis-Cache finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!