Die Entwicklung der MySQL-Anwendungsarchitektur in großen Websites

Dieser Artikel beschreibt hauptsächlich die Entwicklung der MySQL-Architektur unter verschiedenen gleichzeitigen Zugriffsebenen der Website

Skalierbarkeit

Die Skalierbarkeit der Architektur hängt oft eng mit der Parallelität zusammen, und es gibt keine Parallelität Wachstum, es besteht keine Notwendigkeit, eine hochskalierbare Architektur aufzubauen. Es gibt zwei häufig verwendete Erweiterungsmethoden: Vertikale Erweiterung durch Ersetzen durch bessere Maschinen und Ressourcen um eine Skalierung zu erreichen und die Servicefähigkeiten zu verbessern

Scale-out: Horizontale Erweiterung durch Hinzufügen von Knoten (Maschinen), um eine Skalierung zu erreichen und die Servicefähigkeiten zu verbessern

Für Anwendungen mit hoher Parallelität im Internet gibt es keine Ich bezweifle, dass der vertikale Kauf von High-End-Maschinen für uns schon immer ein Tabuthema war und keine langfristige Lösung darstellt. Was ist nach der Scale-out-Theorie der ideale Stand der Skalierbarkeit?

Der ideale Zustand der Skalierbarkeit

Wenn ein Dienst einer höheren Parallelität ausgesetzt ist, kann er die vom Dienst unterstützte Parallelität durch einfaches Hinzufügen von Maschinen verbessern und die Anzahl der Verbindungen im Maschinenprozess erhöhen hat keine Auswirkungen auf den Dienst (keine Ausfallzeit). Dies ist der ideale Zustand der Skalierbarkeit!

Entwicklung der Architektur

V1.0 Einfache Website-Architektur

Die Architektur hinter einer einfachen kleinen Website oder Anwendung kann sehr einfach sein und für Daten ist nur eine MySQL-Instanz erforderlich Speicherung Um die Anforderungen zum Lesen und Schreiben von Daten zu erfüllen (Datensicherungsinstanzen werden hier ignoriert), speichern Websites in diesem Zeitraum im Allgemeinen alle Informationen in einer Datenbankinstanz.

Lassen Sie uns in einer solchen Architektur einen Blick auf die Engpässe bei der Datenspeicherung werfen.

1. Die Gesamtgröße der Daten passt nicht in eine Maschine

2. Der Index der Daten (B+ Baum) passt nicht in den Speicher einer Maschine

3. Die Anzahl der Besuche (gemischtes Lesen und Schreiben) kann von einer Instanz nicht toleriert werden.

Erst wenn eines oder mehrere der oben genannten drei Dinge erfüllt sind, müssen wir über die Weiterentwicklung zur nächsten Instanz nachdenken Ebene. Daraus können wir erkennen, dass diese Architektur für viele kleine Unternehmen und kleine Anwendungen tatsächlich ausreicht. Eine genaue Bewertung des anfänglichen Datenvolumens ist schließlich ein wichtiger Schritt, um ein Überdesign zu verhindern Sorgen Sie sich um die unmöglichen Dinge und verschwenden Sie Ihre Erfahrung.

Hier ist ein einfaches Beispiel von mir: 16G-Speicher kann einen Index von etwa 2000 W Datenzeilen enthalten. Ein einfacher gemischter Lese- und Schreibzugriff beträgt etwa 3000/s Ist Ihr Anwendungsszenario

V2.0 vertikale Aufteilung

Wenn bei V1.0 ein Engpass auftritt, ist die erste und einfachste Aufteilungsmethode die vertikale Aufteilung. Was ist vertikal? Aus geschäftlicher Sicht werden Daten, die nicht stark miteinander verknüpft sind, in verschiedene Instanzen aufgeteilt, um das Ziel zu erreichen, Engpässe zu beseitigen. Im Beispiel in der Abbildung werden Benutzerinformationsdaten und Geschäftsdaten in drei verschiedene Instanzen aufgeteilt. Für Szenarien mit vielen wiederholten Lesetypen können wir auch eine Cache-Ebene hinzufügen, um den Druck auf die Datenbank zu verringern.

Lassen Sie uns in einer solchen Architektur einen Blick auf die Engpässe bei der Datenspeicherung werfen.

1. Einzelinstanz-Einzelunternehmen haben immer noch den in Version 1.0 erwähnten Engpass

Wenn Sie auf einen Engpass stoßen, können Sie ein Upgrade auf eine höhere V-Version dieses Artikels in Betracht ziehen, wenn Leseanforderungen dazu führen Wenn ein Leistungsengpass auftritt, können Sie ein Upgrade auf V3.0 und bei anderen Engpässen ein Upgrade auf V4.0 in Betracht ziehen

V3.0-Master-Slave-Architektur

Diese Art von Architektur löst hauptsächlich das Leseproblem unter der V2.0-Architektur. Sie migriert den Lesedruck durch Anhängen einer Echtzeit-Datensicherung an die Instanz Szenario Durch die Master-Slave-Struktur widersteht die Master-Bibliothek dem Schreibdruck und die Slave-Bibliothek teilt den Lesedruck. Für Anwendungen mit weniger Schreiben und mehr Lesen ist die V3.0-Master-Slave-Architektur voll leistungsfähig

Welche Engpässe bei der Datenspeicherung gibt es in einer solchen Architektur?

1. Die Hauptbibliothek kann den Schreibaufwand nicht ertragen

V4.0 horizontale Aufteilung

Wenn die V2.0 V3.0-Lösung auf einen Engpass stößt, kann dies der Fall sein Horizontale Aufteilung Es gibt einen großen Unterschied zwischen horizontaler Aufteilung und vertikaler Aufteilung. Das Ergebnis der vertikalen Aufteilung ist, dass eine Instanz über die gesamte Datenmenge verfügt, nach der horizontalen Aufteilung jedoch nur 1/n der gesamten Datenmenge Nehmen Sie die Aufteilung der Benutzerinformationen in der folgenden Abbildung als Beispiel. Jeder Cluster enthält 1/3 der gesamten Daten. (Hinweis: Dies ist nicht der Fall.) Nennen Sie es eine einzelne Instanz statt eines Clusters (der einen kleinen MySQL-Cluster einschließlich Master und Slave darstellt)

Wie leitet man Daten weiter?

1. Bereichsaufteilung

Sharding-Schlüssel werden in kontinuierlichen Intervallen weitergeleitet und im Allgemeinen in Szenarien mit strengen Anforderungen an die automatische Inkrementierung von IDs verwendet, z. B. Userid, ein kleines Beispiel für Userid-Bereich: Benutzer-ID verwenden 3000W-Aufteilung für Bereich Nr. 1 Cluster-Benutzer-ID 1-3000W Nr. 2 Cluster-Benutzer-ID 3001W-6000W

2. Listenaufteilung

Die Listenaufteilung hat die gleiche Idee wie die Bereichsaufteilung, beide werden von durchgeführt Für die Weiterleitung an verschiedene Cluster werden verschiedene Sharding-Schlüssel verwendet, die spezifischen Methoden sind jedoch etwas unterschiedlich. Die Liste wird hauptsächlich für Situationen verwendet, in denen der Sharding-Schlüssel kein kontinuierliches Intervall ist und die Sequenz in einen Cluster fällt