Wie MySQL Milliarden von Datenverkehr unterstützt

1 Master-Slave-Lese-/Schreibtrennung

Bei den meisten Internetunternehmen wird mehr gelesen als geschrieben. Daher muss vorrangig darüber nachgedacht werden, wie die Datenbank eine höhere Anzahl von Abfragen unterstützen kann. Zunächst muss zwischen Lese- und Schreibverkehr unterschieden werden, damit der Leseverkehr bequem separat erweitert werden kann, d. h. Master-Slave-Lese- und Schreibtrennung.

Wenn ein plötzlicher Anstieg des Front-End-Verkehrs zu einer Überlastung der Slave-Datenbank führt, wird der DBA der Kapazitätserweiterung der Slave-Datenbank Priorität einräumen. Auf diese Weise wird der Leseverkehr zur Datenbank auf mehrere Slave-Datenbanken verteilt, wodurch die Belastung jeder einzelnen Slave-Datenbank verringert wird. Der Entwickler wird dann sein Bestes tun, um den Verkehr auf der DB-Ebene zu blockieren.

Cache VS MySQL - Lese-/Schreibtrennung Aufgrund der Schwierigkeiten bei Entwicklung und Wartung führt die Einführung eines Caches zu Komplexität. Probleme wie Cache-Datenkonsistenz, Penetration und Lawinenschutz müssen berücksichtigt werden, und ein weiterer Komponententyp muss gewartet werden. Daher wird empfohlen, zunächst die Lese-/Schreibtrennung zu verwenden und dann den Cache zu nutzen, wenn dies nicht möglich ist.

1,1 Kerne

Bei der Master-Slave-Lese-/Schreibtrennung werden die Daten einer DB grundsätzlich in eine oder mehrere Kopien kopiert und auf andere DB-Server geschrieben:

• Die Original-DB ist die Hauptdatenbank, die für das Schreiben der Daten verantwortlich ist
• Die Ziel-DB ist die Slave-Datenbank, die für die Datenabfrage zuständig ist

Der Schlüssel zur Trennung von Lesen und Schreiben zwischen Master und Slave ist daher:

• Kopie der Daten
  

Master-Slave-Replikation

• Schützen Sie die durch die Master-Slave-Trennung verursachten Änderungen im Zugriff auf die Datenbank
  

Geben Sie Entwicklern das Gefühl, immer noch eine einzige Datenbank zu verwenden

2 Master-Slave-Replikation

Die MySQL Master-Slave-Replikation basiert auf Binlog, das alle Änderungen an MySQL aufzeichnet und sie in binärer Form in binären Protokolldateien auf der Festplatte speichert.

Bei der Master-Slave-Replikation werden die Daten im Binärprotokoll normalerweise asynchron von der Masterdatenbank in die Slavedatenbank übertragen: Der Vorgang in der Masterdatenbank wartet nicht, bis die Binärprotokollsynchronisierung abgeschlossen ist.

2.1 Master-Slave-Replikationsprozess

• Wenn der Slave eine Verbindung zum Master herstellt, erstellt er einen E/A-Thread, um das aktualisierte Binärprotokoll des Masters anzufordern, und schreibt das empfangene Binärprotokoll in die Relay-Protokolldatei. Der Master erstellt außerdem einen Protokoll-Dump-Thread, um das Binärprotokoll an den Slave zu senden.
• Die Slave-Datenbank erstellt außerdem einen SQL-Thread, liest das Relay-Protokoll und spielt es in der Slave-Datenbank erneut ab, um Master-Slave-Konsistenz zu erreichen.

Die Verwendung eines unabhängigen Protokoll-Dump-Threads erfolgt asynchron, um den Hauptaktualisierungsprozess der Master-Datenbank nicht zu beeinträchtigen. Nach dem Empfang der Informationen schreibt die Slave-Datenbank diese nicht in den Slave-Datenbankspeicher, sondern in ein Relay-Protokoll. Dadurch soll das Schreiben in den tatsächlichen Speicher der Slave-Datenbank vermieden werden, was zeitaufwändiger ist und letztendlich zu einer längeren Verzögerung zwischen der Slave-Datenbank und der Master-Datenbank führt.

• Der Prozess der asynchronen Master-Slave-Replikation

Aus Leistungsgründen wartet der Schreibvorgang in der Masterdatenbank nicht, bis die Master-Slave-Synchronisierung abgeschlossen ist, bevor er das Ergebnis zurückgibt. In Extremfällen ist beispielsweise die Festplatte beschädigt oder die Maschine verliert die Stromversorgung, bevor das Binärprotokoll der Masterdatenbank auf die Festplatte geschrieben wird, was zu einem Verlust des Binärprotokolls und inkonsistenten Master-Slave-Daten führt. Die Wahrscheinlichkeit ist jedoch sehr gering und tolerierbar.

Nach dem Ausfall der Masterdatenbank kann die durch den Verlust des Binärprotokolls verursachte Inkonsistenz der Master-Slave-Daten nur manuell wiederhergestellt werden.

Nach der Master-Slave-Replikation können Sie:

• Beim Schreiben nur in die Hauptbibliothek schreiben
• Beim Lesen von Daten nur aus der Datenbank lesen

Selbst wenn die Schreibanforderung die Tabelle oder den Datensatz sperrt, hat dies auf diese Weise keine Auswirkungen auf die Ausführung der Leseanforderung. Bei hoher Parallelität können mehrere Slaves eingesetzt werden, um den Leseverkehr zu teilen, d. h. ein Master und mehrere Slaves unterstützen das Lesen mit hoher Parallelität.

Die Slave-Datenbank kann auch als Backup-Datenbank verwendet werden, um Datenverluste aufgrund eines Ausfalls der Master-Datenbank zu vermeiden.

Kann eine unbegrenzte Erhöhung der Anzahl an Slaves eine höhere Parallelität ermöglichen?
NEIN! Je mehr Slaves vorhanden sind, desto mehr I/O-Threads werden mit ihnen verbunden. Die Master-Datenbank muss außerdem dieselbe Anzahl von Log-Dump-Threads erstellen, um Replikationsanforderungen zu verarbeiten, was viele Ressourcen der Master-Datenbank verbraucht. Gleichzeitig ist die Master-Datenbank durch ihre Netzwerkbandbreite begrenzt. Daher kann eine Master-Datenbank normalerweise nur eine Verbindung zu 3 bis 5 Slaves herstellen.

2.2 Nebenwirkungen der Master-Slave-Replikation

Beispielsweise enthält der Vorgang des Postens in Moments Daten:

• Synchronbetrieb
  

Wenn die Datenbank aktualisiert wird

• Asynchrone Vorgänge
  

Beispielsweise die Synchronisierung des Moments-Inhalts mit dem Überprüfungssystem

Daher wird nach dem Aktualisieren der Hauptdatenbank die Freundeskreis-ID in MQ geschrieben, und der Verbraucher ruft basierend auf der ID die Freundeskreisinformationen aus der Datenbank ab und sendet sie dann an das Überprüfungssystem.
Wenn zu diesem Zeitpunkt eine Verzögerung zwischen der Master- und der Slave-Datenbank auftritt, können die Freundeskreisinformationen nicht aus der Slave-Datenbank abgerufen werden, was zu einer Ausnahme führt!

Schematische Darstellung der Auswirkungen der Master-Slave-Verzögerung auf das Geschäft

2.3 Vermeidung von Verzögerungen bei der Master-Slave-Replikation

Was sollte ich tun? Tatsächlich gibt es viele Lösungen und die Kernidee besteht darin, zu versuchen, die Daten nicht aus der Datenbank abzufragen. Daher gibt es für den obigen Fall folgende Lösungen:

2.3.1 Datenredundanz

Beim Senden von MQ können Sie nicht nur die Freundeskreis-ID senden, sondern alle vom Verbraucher benötigten Freundeskreisinformationen und vermeiden so eine erneute Datenabfrage aus der Datenbank.

Diese Lösung wird empfohlen, da sie relativ einfach ist. Sie kann jedoch dazu führen, dass eine einzelne Nachricht größer wird, was wiederum die Bandbreite und die Zeit zum Senden der Nachricht erhöht.

2.3.2 Cache verwenden

Beim synchronen Schreiben in die Datenbank werden die Momentdaten in den Cache geschrieben. Auf diese Weise fragt der Verbraucher, wenn er Momentinformationen erhält, zuerst den Cache ab, wodurch auch die Datenkonsistenz sichergestellt werden kann.

Diese Lösung eignet sich für Szenarien, in denen neue Daten hinzugefügt werden. Wenn Sie Daten aktualisieren, kann das vorherige Aktualisieren des Cache zu Dateninkonsistenzen führen. Beispielsweise aktualisieren zwei Threads gleichzeitig Daten:

• Thread A aktualisiert die Cache-Daten auf 1
• Ein anderer Thread B aktualisiert die Cache-Daten auf 2
• Dann aktualisiert Thread B die DB-Daten auf 2
• Thread A aktualisiert die DB-Daten auf 1

Der finale DB-Wert (1) und der Cache-Wert (2) sind inkonsistent!

2.3.3 Abfrage der Hauptdatenbank

Anstatt die Slave-Datenbank im Consumer abzufragen, können Sie die Master-Datenbank abfragen.

Seien Sie bei der Verwendung vorsichtig. Stellen Sie sicher, dass das Abfragevolumen nicht zu groß ist und innerhalb der Toleranz der Hauptdatenbank liegt. Andernfalls wird die Hauptdatenbank stark belastet.

Verwenden Sie diese Lösung nur, wenn es unbedingt nötig ist. Da eine Schnittstelle zum Abfragen der Hauptdatenbank bereitgestellt wird, kann nur schwer sichergestellt werden, dass andere diese Methode nicht missbrauchen.

Auch die Verzögerung der Master-Slave-Synchronisierung kann bei der Fehlersuche leicht übersehen werden.
Manchmal stoßen Sie auf seltsame Probleme, bei denen Sie keine Informationen aus der Datenbank abrufen können. Sie fragen sich vielleicht, ob es im Code eine Logik gibt, die den zuvor geschriebenen Inhalt löscht, aber Sie stellen möglicherweise fest, dass Sie die Daten erneut lesen können, wenn Sie sie nach einer Weile erneut abfragen. Dies ist im Grunde ein Master-Slave-Verzögerungsproblem.
Daher wird die Zeit, um die die Slave-Datenbank zurückbleibt, im Allgemeinen als wichtiger DB-Indikator für Überwachung und Alarm verwendet. Die normale Zeit liegt auf der ms-Ebene, und ein Alarm wird ausgelöst, wenn sie die s-Ebene erreicht.

Wie wird die Master-Slave-Verzögerungszeitwarnung anhand welches Indikators in welcher Datenbank beurteilt? In der Slave-Bibliothek wird der Monitor „show slave“ angezeigt.
Der Wert des Parameters „Seconds_Behind_Master“ in der Befehlsausgabe „status\G“ bestimmt, ob eine Master-Slave-Verzögerung auftritt.
Dieser Parameterwert wird kopiert, indem der Zeitstempel des von sql_thread und io_thread ausgeführten Ereignisses verglichen wird.
Die Differenz ergibt sich durch den Vergleich der Zeitstempel (abgekürzt ts) des Ereignisses.
Wenn jedoch die io_thread-Thread-Last des bin_log-Protokolls der Replikationssynchronisierungsmasterbibliothek zu hoch ist, ist Seconds_Behind_Master immer 0, d. h. es kann keine Frühwarnung gegeben werden und die Verzögerung lässt sich nicht genau genug anhand des Werts von Seconds_Behind_Master beurteilen. Tatsächlich können Sie auch die Binlog-Positionen von Master und Slave vergleichen.

3 So greifen Sie auf die Datenbank zu

Durch die Verwendung der Master-Slave-Replikation zum Kopieren von Daten auf mehrere Knoten wird auch die Lese- und Schreibtrennung der Datenbank realisiert. Zu diesem Zeitpunkt ändert sich auch die Verwendung der Datenbank:

• Bisher wurde nur eine DB-Adresse benötigt
• Jetzt müssen wir eine Master-Datenbankadresse und mehrere Slave-Datenbankadressen verwenden und zwischen Schreibvorgängen und Abfragevorgängen unterscheiden. In Kombination mit „Sharding von Datenbanken und Tabellen“ wird die Komplexität erheblich erhöht.

Um die Komplexität der Implementierung zu verringern, sind in der Branche viele DB-Middlewares entstanden, um DB-Zugriffsprobleme zu lösen, die grob in folgende Kategorien unterteilt werden können:

3.1 Innerhalb der Anwendung

Beispielsweise wird TDDL (Taobao Distributed Data Layer) in Form von Code in die Anwendung eingebettet ausgeführt. Es kann als Datenquellenagent betrachtet werden. Seine Konfiguration verwaltet mehrere Datenquellen. Jede Datenquelle entspricht einer Datenbank, die eine Master- oder eine Slave-Datenbank sein kann.
Bei einer DB-Anfrage sendet die Middleware das SQL-Statement an eine angegebene Datenquelle und gibt anschließend das Verarbeitungsergebnis zurück.

Vorteil

Es ist einfach zu verwenden und hat geringe Bereitstellungskosten. Da es in die Anwendung eingebettet ist und mit dem Programm ausgeführt wird, eignet es sich für kleine Teams mit schwachen Betriebs- und Wartungsfähigkeiten.

Mangel

Fehlende Mehrsprachenunterstützung, alles in Java entwickelt, keine Unterstützung für andere Sprachen. Auch Versions-Upgrades sind auf Aktualisierungen durch den Benutzer angewiesen.

3.2 Unabhängig bereitgestellte Proxy-Layer-Lösung

Wie Mycat, Atlas und DBProxy.

Diese Art von Middleware wird auf einem unabhängigen Server eingesetzt. Der Geschäftscode ist wie die Verwendung einer einzelnen Datenbank. Tatsächlich verwaltet sie intern viele Datenquellen. Wenn eine Datenbankanforderung vorliegt, nimmt sie die erforderlichen Änderungen an der SQL-Anweisung vor und sendet sie dann an die angegebene Datenquelle.

Vorteil

• Verwendet im Allgemeinen das Standard-MySQL-Kommunikationsprotokoll und kann daher mehrere Sprachen unterstützen
• Unabhängige Bereitstellung, daher einfach zu warten und zu aktualisieren, geeignet für große und mittelgroße Teams mit Betriebs- und Wartungsfunktionen

Mangel

• Alle SQL-Anweisungen müssen das Netzwerk zweimal durchlaufen: von der Anwendung zur Proxy-Schicht und von der Proxy-Schicht zur Datenquelle. Dadurch kommt es zu Leistungseinbußen.

4 Fazit

Die Master-Slave-Replikation kann auf eine Technologie erweitert werden, die Speicherdaten zwischen Speicherknoten repliziert, wodurch Datenredundanz zur Sicherung erreicht und die horizontalen Erweiterungsmöglichkeiten verbessert werden können.

Beachten Sie bei der Verwendung der Master-Slave-Replikation Folgendes:

• Der Kompromiss zwischen Master-Slave-Konsistenz und Schreibleistung
  

Wenn das erfolgreiche Schreiben auf alle Slave-Knoten garantiert ist, wird die Schreibleistung definitiv beeinträchtigt. Wenn nur das Schreiben auf den Master-Knoten erfolgreich ist, kann auf dem Slave-Knoten ein Datensynchronisierungsfehler auftreten, der zu Inkonsistenzen zwischen Master und Slave führt. Internetprojekte priorisieren im Allgemeinen die Leistung gegenüber starker Datenkonsistenz

• Master-Slave-Verzögerung
  

Dies führt zu vielen merkwürdigen Problemen, bei denen Daten nicht gelesen werden können.

Viele reale Fälle:

• Redis erreicht Lese-/Schreibtrennung durch Master-Slave-Replikation
• In Elasticsearch gespeicherte Indexfragmente können auch auf mehrere Knoten repliziert werden
• Beim Schreiben in HDFS wird die Datei auch auf mehrere DataNodes kopiert

Verschiedene Komponenten haben unterschiedliche Anforderungen an Replikationskonsistenz und Latenz und übernehmen unterschiedliche Lösungen, aber die Designideen sind dieselben.

Häufig gestellte Fragen

Wenn eine große Anzahl von Bestellungen vorliegt, ist das Hashen dieser Bestellungen in verschiedene Datenbanken über die Benutzer-ID für Bestellabfragen von Front-End-Benutzern von Vorteil. Auf der Back-End-Systemseite müssen jedoch alle Bestellungen angezeigt und sortiert werden, sodass die SQL-Ausführung sehr langsam ist. Was soll ich dagegen tun?

Da das Backend-System die Daten in den Unterdatenbanken und Untertabellen nicht direkt abfragen kann, können Sie eine Synchronisierung der Daten mit einer separaten Backend-Datenbank oder mit ES in Erwägung ziehen.

Damit ist dieser Artikel darüber, wie MySQL Milliarden von Datenverkehr unterstützt, abgeschlossen. Weitere Informationen zu MySQL Milliarden von Datenverkehr 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!