So laden Sie den Nginx-Lastausgleich

1. Nginx-Reverse-Proxy

Bevor wir den Lastausgleich von Nginx vorstellen, stellen wir zunächst den Reverse-Proxy von Nginx vor. Da Reverse-Proxys häufig verwendet werden, werden wir den Forward-Proxy hier nicht vorstellen.

Der Proxy-Prozess von Nginx besteht darin, die Anfrage an Nginx zu senden und die Anfrage dann an den Back-End-Server weiterzuleiten Der Back-End-Server schließt die Verarbeitung ab. Anschließend werden die Ergebnisse an Nginx gesendet, und Nginx sendet die Ergebnisse dann an den Client. Der Backend-Server kann remote oder lokal sein oder ein anderer virtueller Host sein, der im Nginx-Server definiert ist. Diese Server, die Nginx-Weiterleitung empfangen, werden Upstream genannt

Einer der Zwecke der Verwendung von Nginx als Proxy besteht darin, den Umfang der Infrastruktur zu erweitern. Nginx kann eine große Anzahl gleichzeitiger Verbindungen verarbeiten. Nachdem eine Anfrage eingegangen ist, kann Nginx diese zur Verarbeitung an eine beliebige Anzahl von Hintergrundservern weiterleiten, was einer Verteilung des Lastausgleichs auf den gesamten Cluster entspricht.

Syntax: Proxy_Pass-URL

Erläuterung: Die URL kann die Form haben: http://location:8000/uri/, usw., die unter „Standort konfigurieren“ zu finden sind.

Beispiel: Schreiben wir einen einfachen Reverse-Proxy:

Es gibt keine test_proxy-Datei in dem Verzeichnis, in dem ich Port 80 abhöre, sondern In In meinem 8080-Port-Listening-Verzeichnis habe ich den folgenden Inhalt zum Server auf Port 80 hinzugefügt:

Standort ~ /test_proxy.html$ {proxy_pass http://127.0.0.1:8080;}

Dann geben Sie ein http://IP-Adresse/test_proxy.html im Browser und die angeforderten Informationen werden angezeigt. Tatsächlich wird Port 80 an Port 8080 weitergeleitet und die Daten werden zurück angefordert.

2. Pufferung

nginx bietet außerdem einen Puffermechanismus zur Verbesserung der Leistung. Ohne Pufferung werden die Daten direkt vom Backend-Server an den Client gesendet. Die Funktion der Pufferung besteht darin, die Verarbeitungsergebnisse vom Back-End-Server vorübergehend auf Nginx zu speichern, sodass die Verbindung von Nginx zum Back-End frühzeitig geschlossen werden kann und E/A-Verluste reduziert werden. Im Allgemeinen werden Inhalte im Speicher gespeichert. Wenn jedoch zu viel Inhalt und nicht genügend Speicher vorhanden sind, werden die Inhalte in einem temporären Dateiverzeichnis gespeichert. Im Folgenden sind einige häufig verwendete Pufferkonfigurationselemente aufgeführt, die unter den Inhaltsblöcken http, server und location zu finden sind.

proxy_buffering: Steuern Sie, ob die Pufferung unter diesem Inhaltsblock aktiviert ist. Die Standardeinstellung ist „Ein“.

proxy_buffers: Es gibt zwei Parameter: Der erste steuert die Anzahl der Pufferanforderungen und der zweite die Puffergröße. Der Standardwert ist 8, eine Seite (normalerweise 4 KB oder 8 KB). Je größer der Wert, desto mehr Inhalte werden gepuffert.

proxy_buffer_size: Das erste Segment des Backend-Antwortergebnisses (der Teil einschließlich des Headers) wird separat gepuffert. Mit dieser Konfiguration wird die Größe dieses Teils konfiguriert der Puffer. Dieser Wert ist standardmäßig auf den gleichen Wert wie „proxy_buffer“ eingestellt. Wir können ihn kleiner einstellen, da der Header-Inhalt im Allgemeinen geringer ist.

proxy_busy_buffers_size: Legt die Größe der Puffer fest, die als „clientbereit“ markiert sind. Der Client kann jeweils nur Daten aus einem Puffer lesen und der Puffer wird stapelweise in Warteschlangenreihenfolge an den Client gesendet. Diese Syntax konfiguriert die Größe dieser Warteschlange.

proxy_temp_path: Definieren Sie den temporären Dateipfad für den Nginx-Speicher.

proxy_max_temp_file_size: Die Größe des Verzeichnisses, das pro Anfrage temporäre Dateien speichern kann. Wenn die vom Upstream gesendeten Ergebnisse zu groß sind, um in einen Puffer zu passen, erstellt Nginx temporäre Dateien für sie.

3. Lastausgleich

Konfigurationssyntax: Upstream-Name {......🎜 >

Erklärung: Name ist ein benutzerdefinierter Name und {} ist der Inhalt, der definiert werden muss. Er kann nur im http-Block definiert werden, nicht im Serverblock. Nachdem Sie es definiert haben, können Sie den folgenden Code unter den aufzurufenden Standortblock schreiben: http://name.

Beispiel: Aufgrund der Beschränkung der Serveranzahl nutzen wir hier unterschiedliche Ports eines Servers, um den Lastausgleich zu simulieren. Natürlich sind die Konfigurationen mehrerer Server ähnlich.

Fügen Sie den folgenden Code im Serverblock hinzu:

Upstream-Test {#ip_hash Server-IP:8001; Server-IP:8002; Server-IP:8003; }

Dann fügen wir den folgenden Inhalt an der Stelle innerhalb des http-Blocks hinzu:

Standort / {#Legen Sie den Host-Header und die echte Adresse des Clients fest, damit der Server die echte IP des Clients erhalten kann proxy_set_header Host $http_host; Proxy_set_header 60; Proxy_read_timeout 60; Proxy_buffer_size 32k; #Puffergröße festlegenproxy_buffering on; #Puffer öffnenproxy_buffers 4 128k; #Anzahl und Größe der Puffer festlegenproxy_busy_buffers_size 256k; Proxy_max_temp_file_size 256k; Proxy_pass http://test; #Rufen Sie den oben genannten Lastausgleichssatz auf }Natürlich müssen wir Sie daran erinnern, dass die von uns festgelegte IP-Adresse des Ports vorab in der Konfigurationsdatei konfiguriert wird. Zum Beispiel die folgende Konfiguration.

Dann greifen wir auf unsere Hostadresse zu, aktualisieren sie dann kontinuierlich und finden die Seiteninformationen, die von jedem Port kommen. Der standardmäßige Lastausgleich verwendet Polling.

Wenn Sie unterschiedliche Server für den Lastausgleich nutzen, müssen Sie nur geringfügige Änderungen vornehmen, wie zum Beispiel die folgende Konfiguration:

Upstream mydomain.com{Server 47.95.242.167:80;Server 47.95.242.168:80; }

Nach der Konfiguration ähnelt der verbleibende Code in http dem oben genannten, und dann auf den anderen drei Servern Nehmen Sie dort die folgende Konfiguration vor. Natürlich müssen wir auf diesen drei Servern noch die Firewalls einrichten.

server{

listen 80; server_name www.mydomain.com; index index.htm index.php index.html;Stammverzeichnispfad;}

①Der Status des Backend-Servers bei der Lastausgleichsplanung

dowm: aktuell Der Der Server nimmt vorerst nicht am Lastausgleich teil.

Backup: Reservierter Backup-Server.

max_fails: Die Anzahl der zulässigen Anforderungsfehler.

fail_timeout: Die Zeit, die der Server pausiert, nachdem max_fails fehlschlägt.

max_conns: Begrenzen Sie die maximale Anzahl an Empfangsverbindungen.

Hinweis: Die obige Konfiguration ist im Upstream konfiguriert. Die in {} hinzugefügte Server-IP: 8001 bedeutet beispielsweise, dass dieser Dienst nicht teilnimmt im Lastausgleich und wird für die Sicherung verwendet. Die oben genannten Konfigurationen werden hinter den Dienst geschrieben.

②Planungsalgorithmus

Abfrage: nacheinander in chronologischer Reihenfolge verschiedenen Backend-Servern zugewiesen.

Gewichtete Abfrage: Sie können nach dem konfigurierten Server eine Gewichtung=Zahl hinzufügen. Je höher der Zahlenwert, desto größer die Wahrscheinlichkeit der Zuordnung.

ip_hash: Jede Anfrage wird entsprechend dem Hash der Zugriffs-IP zugewiesen, sodass der Zugriff von derselben IP auf einen Backend-Server festgelegt ist.

least_hash: Die minimale Anzahl von Links. Die Maschine mit der geringsten Anzahl an Verbindungen wird an die Maschine verteilt.

url_hash: Verteilen Sie Anforderungen entsprechend dem Hash-Ergebnis der aufgerufenen URL und leiten Sie jede URL an denselben Backend-Server weiter.

Hash-Schlüsselwert: benutzerdefinierter Hash-Schlüssel.

Hinweis: Der Planungsalgorithmus wird in den Upstream-Einstellungen konfiguriert. Wenn Sie beispielsweise ip_hash in die geschweiften Klammern schreiben, bedeutet dies, dass ip_hash zum Zuweisen von

Mehr verwendet wird Weitere technische Artikel zu Nginx finden Sie in der Spalte Nginx-Tutorial.

Das obige ist der detaillierte Inhalt vonSo laden Sie den Nginx-Lastausgleich. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!