Nachdem wir über die externe Netzwerkumgebung des Websystems gesprochen haben, konzentrieren wir uns nun auf die Leistungsprobleme unseres Websystems selbst.
Da die Anzahl der Besuche auf unserer Website zunimmt, werden wir auf viele Herausforderungen stoßen. Die Lösung dieser Probleme ist nicht nur so einfach wie die Erweiterung der Maschine, sondern die Einrichtung und Verwendung eines geeigneten Caching-Mechanismus ist von grundlegender Bedeutung.
Am Anfang sieht die Architektur unseres Websystems möglicherweise so aus. Jeder Link verfügt möglicherweise nur über eine Maschine.
1. Verwendung des internen Caches der MySQL-Datenbank
Der Caching-Mechanismus von MySQL beginnt in MySQL. Der folgende Inhalt wird sein basierend auf der gängigsten InnoDB-Speicher-Engine.
1. Erstellen Sie geeignete Indizes
Am einfachsten ist es, einen Index zu erstellen. Wenn die Tabellendaten relativ groß sind, kann der Index schnell Daten abrufen, die Kosten sind jedoch höher sind auch welche. Erstens nimmt der kombinierte Index eine gewisse Menge an Speicherplatz ein. Er muss mit Vorsicht verwendet werden. Der von ihm generierte Index kann sogar größer sein als die Quelldaten. Zweitens nehmen Vorgänge wie das Einfügen/Aktualisieren/Löschen von Daten nach der Indexerstellung mehr Zeit in Anspruch, da der ursprüngliche Index aktualisiert werden muss. Tatsächlich wird unser System als Ganzes natürlich von ausgewählten Abfragevorgängen dominiert. Daher kann die Verwendung von Indizes die Systemleistung erheblich verbessern.
2. Datenbankverbindungs-Thread-Pool-Cache
Wenn bei jeder Datenbankoperationsanforderung eine Verbindung erstellt und zerstört werden muss, ist dies zweifellos ein enormer Mehraufwand für die Datenbank. Um diesen Overhead zu reduzieren, kann thread_cache_size in MySQL konfiguriert werden, um anzugeben, wie viele Threads für die Wiederverwendung reserviert sind. Wenn nicht genügend Threads vorhanden sind, werden sie erneut erstellt. Wenn zu viele Threads im Leerlauf vorhanden sind, werden sie zerstört.
Tatsächlich gibt es einen radikaleren Ansatz, bei dem pconnect (Datenbank-Langverbindung) verwendet wird. Sobald der Thread erstellt ist, wird er für lange Zeit beibehalten. Wenn jedoch die Zugriffsmenge relativ groß ist und viele Maschinen vorhanden sind, führt diese Verwendung wahrscheinlich dazu, dass „die Anzahl der Datenbankverbindungen erschöpft ist“, da die Verbindungen hergestellt und nicht recycelt werden und schließlich die max_connections (maximale Anzahl) erreicht werden Verbindungen) der Datenbank. Daher erfordert die Verwendung langer Verbindungen normalerweise die Implementierung eines „Verbindungspool“-Dienstes zwischen CGI und MySQL, um die Anzahl der von der CGI-Maschine „blind“ erstellten Verbindungen zu steuern.
3. Innodb-Cache-Einstellungen (innodb_buffer_pool_size)
innodb_buffer_pool_size Dies ist ein Speicher-Cache-Bereich, der zum Speichern von Indizes und Daten verwendet wird. Wenn die Maschine exklusiv für MySQL ist, wird im Allgemeinen empfohlen, 80 davon zu verwenden der physische Speicher der Maschine. Im Szenario des Abrufens von Tabellendaten kann die Festplatten-E/A reduziert werden. Generell gilt: Je größer dieser Wert eingestellt ist, desto höher ist die Cache-Trefferquote.
4. Unterbibliothek/Tisch/Partition.
MySQL-Datenbanktabellen halten im Allgemeinen einem Datenvolumen in Millionenhöhe stand. Wenn es weiter zunimmt, wird die Leistung erheblich sinken. Daher wird empfohlen, Operationen wie Sub durchzuführen -Datenbank/Tabelle/Partition. Der beste Ansatz besteht darin, den Dienst von Anfang an in einem Subdatenbank- und Subtabellenspeichermodell zu gestalten, um Risiken in der mittleren und späteren Phase grundsätzlich zu eliminieren. Allerdings werden einige Annehmlichkeiten, wie beispielsweise listenbasierte Abfragen, geopfert, und gleichzeitig wird der Wartungsaufwand erhöht. Wenn das Datenvolumen jedoch mehrere zehn Millionen oder mehr erreicht, werden wir feststellen, dass sich alle lohnen.
2. Einrichten mehrerer MySQL-Datenbankdienste
Eine MySQL-Maschine ist tatsächlich ein einzelner Punkt mit hohem Risiko, denn wenn sie aufhängt, ist unser Webdienst Nr länger verfügbar. Als außerdem die Zahl der Zugriffe auf das Websystem weiter zunahm, stellten wir schließlich eines Tages fest, dass ein MySQL-Server es nicht unterstützen konnte, und wir begannen, mehr MySQL-Maschinen zu verwenden. Wenn mehrere MySQL-Maschinen eingeführt werden, werden viele neue Probleme auftreten.
1. MySQL-Master-Slave einrichten, mit der Slave-Datenbank als Backup
Dieser Ansatz dient lediglich dazu, das Problem des „Single Point of Failure“ zu lösen in die Slave-Datenbank übertragen. Allerdings stellt dieser Ansatz tatsächlich eine gewisse Ressourcenverschwendung dar, da die Slave-Bibliothek tatsächlich im Leerlauf ist.
2. MySQL trennt Lesen und Schreiben, Schreiben in die Hauptdatenbank und Lesen aus der Slave-Datenbank.
Die beiden Datenbanken trennen Lesen und Schreiben. Die Hauptbibliothek ist für das Schreiben von Klassen verantwortlich, und die Slave-Bibliothek ist für Lesevorgänge verantwortlich. Darüber hinaus wird der Lesevorgang nicht beeinträchtigt, wenn die Hauptdatenbank ausfällt. Gleichzeitig können alle Lese- und Schreibvorgänge vorübergehend auf die Slave-Datenbank umgestellt werden (Sie müssen auf den Datenverkehr achten, da der Datenverkehr möglicherweise zu groß ist). und die Slave-Datenbank wird heruntergefahren).
3 Der Meister und der Meister sorgen füreinander.
Die beiden MySQL-Server sind gleichzeitig die Slave-Datenbank des anderen und die Master-Datenbank. Diese Lösung leitet nicht nur den Verkehrsdruck um, sondern löst auch das „Single Point of Failure“-Problem. Wenn eine Einheit ausfällt, stehen andere Dienste zur Verfügung.
Diese Lösung kann jedoch nur in einem Szenario mit zwei Maschinen verwendet werden. Wenn das Unternehmen immer noch schnell wächst, können Sie das Unternehmen trennen und mehrere Master-Master- und gegenseitige Backup-Dienste einrichten.
3. Richten Sie einen Cache zwischen dem Webserver und der Datenbank ein
Tatsächlich können wir das Problem großer Besuche nicht einfach lösen Konzentrieren Sie sich auf die Datenbankebene. Gemäß der „80/20-Regel“ konzentrieren sich 80 % der Anfragen nur auf 20 % der heißen Daten. Daher sollten wir einen Caching-Mechanismus zwischen dem Webserver und der Datenbank einrichten. Dieser Mechanismus kann die Festplatte als Cache oder Speichercache verwenden. Durch sie werden die meisten wichtigen Datenabfragen vor der Datenbank blockiert.
1. Statische Seite
Wenn ein Benutzer eine bestimmte Seite der Website besucht, ändert sich der Inhalt der Seite möglicherweise längere Zeit nicht. Beispielsweise wird ein Nachrichtenbericht nach seiner Veröffentlichung fast nie mehr geändert. In diesem Fall wird die von CGI generierte statische HTML-Seite lokal auf der Festplatte des Webservers zwischengespeichert. Mit Ausnahme des ersten Mals, das über eine dynamische CGI-Abfragedatenbank abgerufen wird, wird danach die lokale Festplattendatei direkt an den Benutzer zurückgegeben.
Als der Umfang des Websystems noch relativ klein war, schien dieser Ansatz perfekt zu sein. Sobald jedoch der Umfang des Websystems größer wird, beispielsweise wenn ich 100 Webserver habe. Auf diese Weise werden 100 Kopien dieser Festplattendateien erstellt, was eine Verschwendung von Ressourcen darstellt und schwierig zu warten ist. Zu diesem Zeitpunkt denken einige Leute vielleicht, dass sie einen Server zum Speichern zentralisieren können. Haha, schauen Sie sich doch die folgende Caching-Methode an, wie sie funktioniert.
2. Einzelspeicher-Cache
Anhand des Beispiels der Seitenstatik können wir erkennen, dass es schwierig ist, den „Cache“ auf dem Web-Computer selbst zu verwalten, und dass dies mehr Probleme mit sich bringt ( Tatsächlich kann der native Speicher des Webservers über die APC-Erweiterung von PHP über Schlüssel/Wert manipuliert werden. Daher muss der Speicher-Cache-Dienst, den wir erstellen möchten, auch ein unabhängiger Dienst sein.
Die Hauptauswahlmöglichkeiten für den Speichercache sind Redis/Memcache. In Bezug auf die Leistung gibt es keinen großen Unterschied zwischen den beiden. In Bezug auf den Funktionsumfang ist Redis überlegen.
3. Speicher-Cache-Cluster
Wenn wir einen einzelnen Speicher-Cache erstellen, stehen wir vor dem Problem eines Single Point of Failure, also müssen wir ihn in einen Cluster umwandeln. Der einfache Weg besteht darin, einen Slave als Backup-Maschine hinzuzufügen. Was aber, wenn es wirklich viele Anfragen gibt und wir feststellen, dass die Cache-Trefferquote nicht hoch ist und mehr Maschinenspeicher benötigt wird? Daher empfehlen wir die Konfiguration als Cluster. Ähnlich wie beim Redis-Cluster.
Redis im Redis-Cluster-Cluster besteht aus mehreren Sätzen von Mastern und Slaves. Gleichzeitig kann jeder Knoten Anforderungen annehmen, was beim Erweitern des Clusters praktischer ist. Der Client kann eine Anfrage an jeden Knoten senden. Wenn es sich um den Inhalt handelt, für den er „verantwortlich“ ist, wird der Inhalt direkt zurückgegeben. Andernfalls suchen Sie den tatsächlich verantwortlichen Redis-Knoten, informieren Sie dann den Client über die Adresse und der Client fordert erneut an.
Dies alles ist für Kunden, die den Caching-Dienst nutzen, transparent.
Beim Wechsel des Speicher-Cache-Dienstes bestehen bestimmte Risiken. Beim Wechsel von Cluster A zu Cluster B muss sichergestellt werden, dass Cluster B im Voraus „aufgewärmt“ wird (die heißen Daten im Speicher von Cluster B sollten so weit wie möglich mit denen von Cluster A übereinstimmen). Andernfalls wird zum Zeitpunkt des Wechsels eine große Anzahl von Inhaltsanforderungen angefordert. Diese können nicht im Speichercache von Cluster B gefunden werden. Der Datenverkehr wirkt sich direkt auf den Back-End-Datenbankdienst aus, was wahrscheinlich zu Datenbankausfällen führt.
4. Datenbank-„Schreibvorgänge“ reduzieren
Die oben genannten Mechanismen reduzieren alle Datenbank-„Lesevorgänge“, aber auch der Schreibvorgang stellt einen großen Druck dar. Obwohl der Schreibvorgang nicht reduziert werden kann, kann der Druck durch das Zusammenführen von Anforderungen verringert werden. Zu diesem Zeitpunkt müssen wir einen Änderungssynchronisierungsmechanismus zwischen dem Speicher-Cache-Cluster und dem Datenbank-Cluster einrichten.
Setzen Sie die Änderungsanforderung zunächst im Cache in Kraft, damit externe Abfragen normal angezeigt werden können, und stellen Sie diese SQL-Änderungen dann in eine Warteschlange und speichern Sie sie, wenn die Warteschlange voll ist oder von Zeit zu Zeit. Sie werden in einer Anfrage zusammengeführt und an die Datenbank gesendet.
Zusätzlich zur Verbesserung der Schreibleistung durch die oben erwähnte Änderung der Systemarchitektur kann MySQL selbst auch die Schreibstrategie auf die Festplatte anpassen, indem es den Parameter innodb_flush_log_at_trx_commit konfiguriert. Wenn es die Maschinenkosten zulassen, können Sie zur Lösung des Problems auf Hardwareebene das ältere RAID (Redundant Arrays of Independent Disks, Disk-Array) oder das neuere SSD (Solid State Drives, Solid-State-Laufwerk) wählen.
5. NoSQL-Speicher
Unabhängig vom Lesen oder Schreiben der Datenbank wird schließlich das Szenario „wenn die Arbeitskräfte begrenzt sind“ erreicht, wenn der Datenverkehr weiter zunimmt. Die Kosten für das Hinzufügen weiterer Maschinen sind relativ hoch und lösen das Problem möglicherweise nicht wirklich. Zu diesem Zeitpunkt können Sie die Verwendung einer NoSQL-Datenbank für einige Kerndaten in Betracht ziehen. Die meisten NoSQL-Speicher verwenden die Schlüsselwertmethode. Es wird empfohlen, Redis selbst zu verwenden. Redis selbst ist ein Speichercache und kann auch als Speicher verwendet werden, sodass Daten direkt auf der Festplatte gespeichert werden können.
In diesem Fall trennen wir einige häufig gelesene und geschriebene Daten in der Datenbank und legen sie in unserem neu erstellten Redis-Speichercluster ab, wodurch der Druck auf die ursprüngliche MySQL-Datenbank weiter verringert wird Da es sich um einen Cache auf Speicherebene handelt, wird die Leistung beim Lesen und Schreiben erheblich verbessert.
Inländische First-Tier-Internetunternehmen verwenden hinsichtlich der Architektur viele Lösungen, die den oben genannten Lösungen ähneln. Der verwendete Cache-Dienst ist jedoch nicht unbedingt auf Redis ausgerichtet Entwickeln Sie einen eigenen NoSQL-Dienst basierend auf Ihren eigenen Geschäftsmerkmalen.
6. Problem mit der Abfrage leerer Knoten
Wenn wir alle oben genannten Dienste erstellt haben und denken, dass das Websystem bereits sehr stark ist. Wir sagen immer noch das Gleiche, es werden immer noch neue Probleme kommen. Leere Knotenabfragen beziehen sich auf Datenanforderungen, die überhaupt nicht in der Datenbank vorhanden sind. Wenn ich beispielsweise anfordere, die Informationen einer Person abzufragen, die nicht vorhanden sind, durchsucht das System Schritt für Schritt den Cache auf allen Ebenen, findet schließlich die Datenbank selbst und kommt dann zu dem Schluss, dass sie nicht gefunden werden kann, und kehrt zurück es an das vordere Ende. Da Caches auf allen Ebenen dafür ungültig sind, verbraucht diese Anfrage viele Systemressourcen, und wenn eine große Anzahl leerer Knotenabfragen durchgeführt wird, kann dies Auswirkungen auf die Systemdienste haben.
Das obige ist der detaillierte Inhalt vonEinrichtung und Optimierung des Caching-Mechanismus für das Website-System. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
