MySQL (5)-Caching-Strategie

Artikel der MySQL-Reihe

MySQL (1) Grundstruktur, SQL-Anweisungsbetrieb,
MySQL ausprobieren (2) Indexprinzip und Optimierung
MySQL (3) SQL-Optimierung, Pufferpool, Puffer ändern
MySQL (4) Transaktionsprinzip und Analyse
MySQL (5) Caching-Strategie
MySQL (6) Drei Paradigmen der Master-Slave-Replikationsdatenbank

---

Warum braucht MySQL Caching?

Mit der Expansion des Unternehmens nimmt die Datenmenge allmählich zu, was den Lese- und Schreibdruck von MySQL erhöht.
Im Allgemeinen wird Redis in der Mitte als Cache von MySQL hinzugefügt.
MySQL-Cache-Lösung: Benutzerdefinierte Hot-Daten werden zwischengespeichert, und Benutzer können Hot-Daten direkt aus dem Cache abrufen, um den Datenlesedruck zu verringern.

Was sind die Nutzungsszenarien des MySQL-Cache?

Die Speicherzugriffsgeschwindigkeit ist 100.000-mal (Größenordnung) schneller als die Festplattengeschwindigkeit.
Der Lesebedarf ist viel größer als der Schreibbedarf. Die
eigene Pufferschicht von MySQL hat nichts mit dem Geschäft zu tun (z. B. Pufferpool).
MySQL ist es Wird als Hauptdatenbank des Projekts verwendet und eignet sich für statistische Analysen
. Heiße Daten

Warum wird eine Pufferschicht benötigt?

Mehr lesen und weniger schreiben, ein einzelner Masterknoten kann die Menge der Projektdaten unterstützen; die Hauptbasis für Daten ist MySQL;

Auswahl der Pufferschicht

Die Cache-Datenbank kann zwischen Redis und Memcached ausgewählt werden. Alle Daten werden im Speicher gespeichert. Natürlich können die Daten im Speicher auch auf der Festplatte gespeichert werden.

Zusammenfassen

• Da die Pufferschicht von MySQL nicht vom Benutzer gesteuert wird, kann der Benutzer das Zwischenspeichern bestimmter Daten nicht steuern.
• Die Zugriffsgeschwindigkeit auf die Festplatte ist relativ langsam. Versuchen Sie, die Daten aus dem Speicher abzurufen. Daher ist es erforderlich, sie zwischenzuspeichern und aus dem Speicher zu lesen.
• Es löst hauptsächlich die Leseleistung. Da das Schreiben nicht optimiert werden muss, müssen die Daten korrekt auf der Festplatte platziert werden. Wenn ein Problem mit der Schreibleistung auftritt, können Sie es mithilfe der horizontalen Erweiterungsclustermethode lösen.
• Die im Projekt zu speichernden Daten sollten viel größer sein als die Speicherkapazität, und gleichzeitig ist eine statistische Analyse der Daten erforderlich, sodass die Grundlage für die Datenspeicherung und -erfassung eine relationale Datenbank sein sollte.
• Die Cache-Datenbank kann benutzerdefinierte Hot-Daten speichern. Die folgende Diskussion basiert auf der Synchronisierung von Hot-Daten.
  

Probleme mit der Pufferschicht

Bevor es keine Pufferschicht gibt, basiert unser Lesen und Schreiben von Daten auf MySQL. Es gibt also kein Synchronisationsproblem.
Nach der Einführung der Pufferschicht müssen wir die Cache-Datenbank und MySQL für die Datenerfassung separat betreiben. Wie viele Zustände gibt es dann? kann zu diesem Zeitpunkt in den Daten vorhanden sein?

1. MySQL ja, kein Cache
2. MySQL nein, Cache hat
3. Ja, aber die Daten sind inkonsistent
4. Ja, die Daten sind konsistent
5. Keiner
   der Zustände 1, 4 und 5 sind akzeptable Zustände. Es ist notwendig, eine Lese- und Schreibstrategie zu formulieren, um das Auftreten der Situationen 2 und 3 zu vermeiden.

Lese- und Schreibstrategie

Lesestrategie : Redis zuerst lesen: Wenn keine Trefferdaten vorhanden sind, dann MySQL lesen; wenn Redis Daten hat, wird es direkt zurückgegeben.
MySQL lesen: Wenn die Daten nicht getroffen werden, wird „Nein“ zurückgegeben. Wenn die Daten getroffen werden, werden die von MySQL gelesenen Daten mit Redis synchronisiert.
Schreibstrategie : Es gibt zwei Arten von Sicherheitspriorität und Effizienzpriorität (Einfügen, Aktualisieren, Löschen).
Sicherheitspriorität: Cache löschen, dann in MySQL schreiben, und dann synchronisiert MySQL die Daten mit Redis.
Effizienzpriorität: Zuerst in Redis schreiben, Wenn es sich um einen Einfüge- und Aktualisierungsvorgang handelt, stellen Sie den Schlüssel auf eine Ablaufzeit (z. B. 200 ms) ein, schreiben Sie dann in MySQL und schließlich wird MySQL mit Redis synchronisiert. (Sicherheitsfrage betrifft nur 200 ms).

Das Problem der Pufferschicht kann durch Lese- und Schreibstrategien gelöst werden, es gibt jedoch einige Synchronisationsschemata, wenn MySQL-Daten mit Redis synchronisiert werden.

Synchronisationsschema

1. Trigger + UDF-Funktion
2. gefälschte Datenbank

Trigger + UDF-Funktion

Schritt:

1. Legen Sie in MySQL den Trigger-Trigger für die zu verarbeitenden Daten fest und überwachen Sie den Vorgang
2. Wenn der Client (NodeServer) Daten in MySQL schreibt, wird der Trigger ausgelöst und nach dem Trigger wird die UDF-Funktion von MySQL aufgerufen
3. Die UDF-Funktion kann Daten in Redis schreiben, um den Effekt der Synchronisierung zu erzielen.
   Ergebnisanalyse:
   Diese Lösung eignet sich für Szenarien, in denen es mehr Lesevorgänge als Schreibvorgänge gibt und es keine gleichzeitigen Schreibvorgänge gibt.
   Da der MySQL-Trigger selbst einen verursacht Verringerung der Effizienz, wenn ein Tisch häufig bedient wird und dieses Schema nicht für die Anzeige geeignet ist

gefälschte Datenbank

Die Tarnung als Datenbank gibt vor, Binlog-Daten von MySQL aus der Datenbank zu lesen. Nachdem die Datenbank die Daten gelesen hat, analysiert sie das Bin-Protokoll, schreibt und schreibt die Daten dann zur Synchronisierung nach Redis, und dann liest der Client die Daten von Redis.
Alibaba hat Canal als getarnte Datenbank offengelegt, um das Synchronisationsproblem zu lösen.
Funktionsprinzip :
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-Anfrage und
beginnt, das Binärprotokoll an den Slave (d. h. den Kanal) zu übertragen.
Canal analysiert das Binäres Protokollobjekt (ursprünglich Bytefluss)

Cache-Ausnahme

Cache-Penetration

Angenommen, eine Daten-Redis existiert nicht, MySQL existiert nicht, und was soll ich tun, wenn ich ständig versuche, sie zu lesen? Beim Durchdringen des Caches sammelt sich der endgültige Datendruck immer noch in MySQL an, was zu einer Überlastung und einem Absturz von MySQL führen kann. In Redis gibt es keinen Schutz.
Lösung :
Stellen Sie fest, dass MySQL nicht vorhanden ist, setzen Sie Redis auf <Schlüssel, Null> und legen Sie die Ablaufzeit fest. Wenn Sie das nächste Mal auf den Schlüssel zugreifen, greifen Sie nicht mehr auf MySQL zu, was leicht dazu führt, dass Redis viele ungültige Daten zwischenspeichert ; Bloom-Filter (kann bestätigen, dass der
Schlüssel nicht existiert), schreibt die vorhandenen Schlüssel in MySQL in den Bloom-Filter und übergibt die nicht vorhandenen direkt; (um das Problem der Verwendung verschiedener illegaler Schlüssel zum Angriff auf die Datenbank zu lösen)

Cache-Aufschlüsselung

Einige Daten verfügt Redis nicht, MySQL jedoch. Zu diesem Zeitpunkt führt eine große Anzahl gleichzeitiger Verbindungsanforderungen für solche Daten auch dazu, dass MySQL zu groß ist.
Lösung :

Verteilte Sperre
Erhält die Sperre beim Anfordern von Daten. Wenn die Erfassung erfolgreich ist, wird die Sperre nach dem Vorgang aufgehoben. Wenn die Erfassung fehlschlägt, wird sie für einen Zeitraum (200 ms) in den Ruhezustand versetzt und dann erfasst. Wenn die Erfassung erfolgreich ist, wird die Sperre aktiviert Die Sperre wird nach der Operation aufgehoben.
Vorteile: kein zusätzlicher Speicherverbrauch, garantierte Konsistenz, einfache Implementierung.
Nachteile: Threads müssen warten, die Leistung wird beeinträchtigt

Stellen Sie den Hotkey so ein, dass er nicht abläuft;

Cache-Lawine

Zeigt an, dass der Cache innerhalb einer bestimmten Zeitspanne zentral ausfällt (Redis nicht, MySQL schon), was dazu führt, dass alle Anfragen an MySQL gehen, was die Datenbank zerstören und den gesamten Dienst ungültig machen kann; die Grundlage der Hauptdaten
von MySQL; der Status von Redis ist optional;

Lösung :
Die Cache-Datenbank ist im gesamten System nicht erforderlich, dh die Cache-Ausfallzeit hat keinen Einfluss auf den vom gesamten System bereitgestellten Dienst.

1. Wenn die Cache-Datenbank ausgefallen ist und alle Daten an MySQL fließen, verwenden Sie eine hochverfügbare Cluster-Lösung, z. B. den Sentinel-Modus oder den Cluster-Modus.
2. Wenn der Cache aufgrund der Festlegung derselben Ablaufzeit ungültig wird, legen Sie einen zufälligen Ablaufzeitwert oder andere Mechanismen fest, um die Ablaufzeit zu staffeln.
3. Wenn die zwischengespeicherten Daten aufgrund eines Systemneustarts verschwinden;
   die Neustartzeit ist kurz, Redis aktiviert die Persistenz (abgelaufene Informationen werden ebenfalls beibehalten); wenn die Neustartzeit lang ist, importieren Sie Hot-Daten im Voraus in Redis;

Nachteile des Cachings

Transaktionen, die nicht mehrere Anweisungen verarbeiten können.
Redis unterstützt kein Rollback,
was zu Inkonsistenzen zwischen Redis und MySQL führt

Verbindungspoolproblem

Verbindungspool: Hotspot-Schlüssel befinden sich immer in derselben Verbindung; derselbe Schlüssel muss dieselbe MySQL-Verbindung oder dieselbe Redis-Verbindung (implementiert durch Hash) verwenden. Der Zweck besteht darin, sicherzustellen, dass es keine Probleme mit der Parallelität gibt.